Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hfVJ8-0003mF-6k for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Jun 2019 20:11:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hfVJ4-0002QV-BM for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Jun 2019 20:11:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hfVJ3-0002PV-Vv for pgsql-hackers@lists.postgresql.org; Mon, 24 Jun 2019 20:11:14 +0000 Received: from mail-lj1-x243.google.com ([2a00:1450:4864:20::243]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hfVJ1-0006E0-Kh for pgsql-hackers@postgresql.org; Mon, 24 Jun 2019 20:11:13 +0000 Received: by mail-lj1-x243.google.com with SMTP id t28so13851097lje.9 for ; Mon, 24 Jun 2019 13:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=8x04xjMVojpLsLQA/Y5j4ufz77adX371L8pRFE6JjBc=; b=NSFlpHzrN3Jr5aza/iBa4bye3+It/CryjV2qfuoIgWUnFsveJ5dUmF/qTlR0iOBXLZ GAat1e/fBK9pTrhVQjVCahYvCsp2p6WL2L6kT681eSBCHYo8MgWAMqk9juYW4TUCusu8 fJxy25U1GVziGNeeSDIYWFYp9z5AxNJwViTuK6bhqql0YVeWio5NBHCBvCXs6kAM/bR/ v5nbUQVNDwIjQ3Cz+hVjjSvL1+RB8sZwFXw271bnKCryDyaq63CCzZKlFloJOt9SpJa/ 9a8nDPPcgQn8zdHet78xEPVvcZlUMQSW0CXQ85VJ0bShwHhRR/vdl1Bpv8OnU65Fd+tv zaPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=8x04xjMVojpLsLQA/Y5j4ufz77adX371L8pRFE6JjBc=; b=FVVP2S+bM6G5gkU6vV07hI9bpW/Ff7yKjTIHj67k8qM9MLpeBYzQWR/ii4VCnTOzxS kQwIPbSapIYiJoeKt378EU/rJVa3jGbwmzrqHy7I6YnHMO+pOka+BpD8Th1YVguqoU3O J/weYB52YAFzidnLOoqxeeXDIKxW1P47wD+YLePIQQqoJjl0mEEIbW1SOGkcPGC/JP3a EDKMD+LXRyBfTmkoIcVzXIvSGz5yHq8FUQvHchFkj83UmlDgxvqE5HQrZurG9L4LxKbo ehD+VrInr58dP0Khkgoy3HIgcv+RA6+IGJGGwhuOusn6MLQo41UE9vhu6wH43JCoC7Gn SisA== X-Gm-Message-State: APjAAAX9WYsUl7nZVzI5FOS+cHv3psXEGLAEbC9W4p+Ge25e0EDd2rXa PK/+0/Y4/T2Wowl0vT2cST7bwMTTaOw= X-Google-Smtp-Source: APXvYqzohRo69FSBbM0h4CGK5Q4fxDVgdIugFI2n3XLyvRSYffTEAQy72xPeDYEPVqj+29QmlMtbWQ== X-Received: by 2002:a2e:9ec9:: with SMTP id h9mr43521842ljk.90.1561407070582; Mon, 24 Jun 2019 13:11:10 -0700 (PDT) Received: from [1.0.0.7] ([178.155.4.104]) by smtp.gmail.com with ESMTPSA id c12sm1645871lfj.58.2019.06.24.13.11.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jun 2019 13:11:09 -0700 (PDT) To: pgsql-hackers From: Alexander Lakhin Subject: Prevent invalid memory access in LookupFuncName Message-ID: <3d068be5-f617-a5ee-99f6-458a407bfd65@gmail.com> Date: Mon, 24 Jun 2019 23:10:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------6CBF33094F52BFA510C5A9A3" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------6CBF33094F52BFA510C5A9A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello hackers, When running on REL_11_STABLE the following query: CREATE PROCEDURE test_ambiguous_procname(int) as $$ begin end; $$ language plpgsql; CREATE PROCEDURE test_ambiguous_procname(text) as $$ begin end; $$ language plpgsql; DROP PROCEDURE test_ambiguous_procname; under valgrind I get the memory access errors: 2019-06-24 22:21:39.925 MSK|law|regression|5d1122c2.2921|LOG:  statement: DROP PROCEDURE test_ambiguous_procname; ==00:00:00:07.756 10529== Conditional jump or move depends on uninitialised value(s) ==00:00:00:07.756 10529==    at 0x4C35E60: __memcmp_sse4_1 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==00:00:00:07.756 10529==    by 0x2E9A7B: LookupFuncName (parse_func.c:2078) ==00:00:00:07.756 10529==    by 0x2E9D96: LookupFuncWithArgs (parse_func.c:2141) ==00:00:00:07.756 10529==    by 0x2A2F7E: get_object_address (objectaddress.c:893) ==00:00:00:07.756 10529==    by 0x31C9C0: RemoveObjects (dropcmds.c:71) ==00:00:00:07.756 10529==    by 0x50D4FF: ExecDropStmt (utility.c:1738) ==00:00:00:07.756 10529==    by 0x5100BC: ProcessUtilitySlow (utility.c:1580) ==00:00:00:07.756 10529==    by 0x50EDFE: standard_ProcessUtility (utility.c:835) ==00:00:00:07.756 10529==    by 0x50F07D: ProcessUtility (utility.c:360) ==00:00:00:07.756 10529==    by 0x50B4D2: PortalRunUtility (pquery.c:1178) ==00:00:00:07.756 10529==    by 0x50C169: PortalRunMulti (pquery.c:1324) ==00:00:00:07.756 10529==    by 0x50CEFF: PortalRun (pquery.c:799) ==00:00:00:07.756 10529==  Uninitialised value was created by a stack allocation ==00:00:00:07.756 10529==    at 0x2E9C31: LookupFuncWithArgs (parse_func.c:2106) ==00:00:00:07.756 10529== ... ==00:00:00:07.756 10529== Conditional jump or move depends on uninitialised value(s) ==00:00:00:07.756 10529==    at 0x2E9A7E: LookupFuncName (parse_func.c:2078) ==00:00:00:07.756 10529==    by 0x2E9D96: LookupFuncWithArgs (parse_func.c:2141) ==00:00:00:07.757 10529==    by 0x2A2F7E: get_object_address (objectaddress.c:893) ==00:00:00:07.757 10529==    by 0x31C9C0: RemoveObjects (dropcmds.c:71) ==00:00:00:07.757 10529==    by 0x50D4FF: ExecDropStmt (utility.c:1738) ==00:00:00:07.757 10529==    by 0x5100BC: ProcessUtilitySlow (utility.c:1580) ==00:00:00:07.757 10529==    by 0x50EDFE: standard_ProcessUtility (utility.c:835) ==00:00:00:07.757 10529==    by 0x50F07D: ProcessUtility (utility.c:360) ==00:00:00:07.757 10529==    by 0x50B4D2: PortalRunUtility (pquery.c:1178) ==00:00:00:07.757 10529==    by 0x50C169: PortalRunMulti (pquery.c:1324) ==00:00:00:07.757 10529==    by 0x50CEFF: PortalRun (pquery.c:799) ==00:00:00:07.757 10529==    by 0x5090FF: exec_simple_query (postgres.c:1145) ==00:00:00:07.757 10529==  Uninitialised value was created by a stack allocation ==00:00:00:07.757 10529==    at 0x2E9C31: LookupFuncWithArgs (parse_func.c:2106) As I see, the code in LookupFuncName can fall through the "if (nargs == -1)" condition and execute memcmp with nargs==-1. The proposed patch is attached. Best regards, Alexander --------------6CBF33094F52BFA510C5A9A3 Content-Type: text/x-patch; name="fix-LookupFuncName.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fix-LookupFuncName.patch" diff --git a/src/backend/parser/parse_func.c b/src/backend/parser/parse_func.c index 44257154b81..ee9f73ef977 100644 --- a/src/backend/parser/parse_func.c +++ b/src/backend/parser/parse_func.c @@ -2071,6 +2071,7 @@ LookupFuncName(List *funcname, int nargs, const Oid *argtypes, bool noError) errmsg("could not find a function named \"%s\"", NameListToString(funcname)))); } + return InvalidOid; } while (clist) --------------6CBF33094F52BFA510C5A9A3--