Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w9f2E-001cyk-39 for pgadmin-hackers@arkaria.postgresql.org; Mon, 06 Apr 2026 08:10:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w9f2D-007Bek-0D for pgadmin-hackers@arkaria.postgresql.org; Mon, 06 Apr 2026 08:10:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w9f2C-007Bec-2F for pgadmin-hackers@lists.postgresql.org; Mon, 06 Apr 2026 08:10:13 +0000 Received: from mx2.aktivco.ru ([31.172.134.250]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w9f29-00000000rrX-1LQm for pgadmin-hackers@lists.postgresql.org; Mon, 06 Apr 2026 08:10:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rutoken.ru; s=mail; t=1775462996; bh=8zzPoW5UJPJUItNO2Ot13TXEMr4BHsDlMf2pfKAUh9w=; h=From:To:Subject:Date:From; b=E24Y5CF2nVfhwN58uHkHBqstQg9PZ+Yez/PDUv/Umlk84/TtpL7Ky7twMcz/1DJz9 4rCGoGmBxwun2qwQ548eClVKsm+fQg7rEB1AQsZAQmvgFu7OmrD0a1YPFXZM/QhLOr dCExEqo7ECMjIkJTA7sPf7Egh0Jv0+I3LMCBxmBo= From: =?koi8-r?B?58HMy8nOIPPF0sfFyg==?= To: "pgadmin-hackers@lists.postgresql.org" Subject: DEREF_AFTER_NULL: src/common/jsonapi.c:2529 Thread-Topic: DEREF_AFTER_NULL: src/common/jsonapi.c:2529 Thread-Index: AQHcxZoKnwfOa3JmOkii4KxC+5/Kyg== Date: Mon, 6 Apr 2026 08:09:46 +0000 Message-ID: <6c6cc4b06b8e4f3ab91029c5e7f2e479@rutoken.ru> Accept-Language: ru-RU, en-US Content-Language: ru-RU X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.112.234] x-kse-serverinfo: Aktiv-Mail2016.aktiv.guardant.ru, 9 x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean, bases: 06.04.2026 4:53:00 x-kse-attachment-filter-triggered-rules: Clean x-kse-attachment-filter-triggered-filters: Clean x-kse-bulkmessagesfiltering-scan-result: protection disabled Content-Type: multipart/mixed; boundary="_004_6c6cc4b06b8e4f3ab91029c5e7f2e479rutokenru_" MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_004_6c6cc4b06b8e4f3ab91029c5e7f2e479rutokenru_ Content-Type: multipart/alternative; boundary="_000_6c6cc4b06b8e4f3ab91029c5e7f2e479rutokenru_" --_000_6c6cc4b06b8e4f3ab91029c5e7f2e479rutokenru_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hello, a static analyzer pointed out a possible NULL dereference at the end= of json_errdetail() (src/common/jsonapi.c): return lex->errormsg->data; That seemed plausible to me, since there is a comment just above saying tha= t lex->errormsg can be NULL in shlib code. I also checked PQExpBufferBroken= (), and it does handle NULL, but that call is under #ifdef, while the final= access to lex->errormsg->data is unconditional. I may be missing some invariant here, but it seems worth adding an explicit= NULL check. I prepared a corresponding patch and am attaching it below in = case you agree that this is a real issue. diff --git a/src/common/jsonapi.c b/src/common/jsonapi.c index 1145d93945f..192040b5443 100644 --- a/src/common/jsonapi.c +++ b/src/common/jsonapi.c @@ -2525,6 +2525,9 @@ json_errdetail(JsonParseErrorType error, JsonLexConte= xt *lex) if (PQExpBufferBroken(lex->errormsg)) return _("out of memory while constructing error description"); #endif + + if (!lex->errormsg) + return _("out of memory while constructing error description"); return lex->errormsg->data; } Best regards, Galkin Sergey --_000_6c6cc4b06b8e4f3ab91029c5e7f2e479rutokenru_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Hello, a static analyzer pointed out a possible NULL dereference = at the end of json_errdetail() (src/common/jsonapi.c):
return lex->errormsg->data;

That seemed plausible to me, since there is a comment just above saying tha= t lex->errormsg can be NULL in shlib code. I also checked PQExpBufferBro= ken(), and it does handle NULL, but that call is under #ifdef, while the fi= nal access to lex->errormsg->data is unconditional.

I may be missing some invariant here, but it seems worth adding an explicit= NULL check. I prepared a corresponding patch and am attaching i= t below in case you agree that this is a real issue.

diff --git a/src/common/jsonapi.c b/src/common/jsonapi.c
index 1145d93945f..192040b5443 100644
--- a/src/common/jsonapi.c
+++ b/src/common/jsonapi.c
@@ -2525,6 +2525,9 @@ json_errdetail(JsonParseErrorType error, JsonLexC= ontext *lex)
     if (PQExpBufferBroken(lex->errormsg))
         return _("out of memory while constr= ucting error description");
 #endif
+    
+    if (!lex->errormsg)
+        return _("out of memory while constru= cting error description");
 
     return lex->errormsg->data;
 }

Best regards, Galkin Sergey

--_000_6c6cc4b06b8e4f3ab91029c5e7f2e479rutokenru_-- --_004_6c6cc4b06b8e4f3ab91029c5e7f2e479rutokenru_ Content-Type: text/x-patch; name="0001-Added-an-additional-check-when-dereferencing-a-point.patch" Content-Description: 0001-Added-an-additional-check-when-dereferencing-a-point.patch Content-Disposition: attachment; filename="0001-Added-an-additional-check-when-dereferencing-a-point.patch"; size=769; creation-date="Mon, 06 Apr 2026 08:07:04 GMT"; modification-date="Mon, 06 Apr 2026 08:07:04 GMT" Content-Transfer-Encoding: base64 RnJvbSBlZWZlNTFlNzRhODllMDVhMjFhMDcxOGNiZjAwN2E1YWRkNDVkZmM2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTZXJnZXkgPGdhbGtpbkBydXRva2VuLnJ1PgpEYXRlOiBGcmks IDMgQXByIDIwMjYgMTk6NTQ6MTggKzAzMDAKU3ViamVjdDogW1BBVENIXSBBZGRlZCBhbiBhZGRp dGlvbmFsIGNoZWNrIHdoZW4gZGVyZWZlcmVuY2luZyBhIHBvaW50ZXIKCi0tLQogc3JjL2NvbW1v bi9qc29uYXBpLmMgfCAzICsrKwogMSBmaWxlIGNoYW5nZWQsIDMgaW5zZXJ0aW9ucygrKQoKZGlm ZiAtLWdpdCBhL3NyYy9jb21tb24vanNvbmFwaS5jIGIvc3JjL2NvbW1vbi9qc29uYXBpLmMKaW5k ZXggMTE0NWQ5Mzk0NWYuLjE5MjA0MGI1NDQzIDEwMDY0NAotLS0gYS9zcmMvY29tbW9uL2pzb25h cGkuYworKysgYi9zcmMvY29tbW9uL2pzb25hcGkuYwpAQCAtMjUyNSw2ICsyNTI1LDkgQEAganNv bl9lcnJkZXRhaWwoSnNvblBhcnNlRXJyb3JUeXBlIGVycm9yLCBKc29uTGV4Q29udGV4dCAqbGV4 KQogCWlmIChQUUV4cEJ1ZmZlckJyb2tlbihsZXgtPmVycm9ybXNnKSkKIAkJcmV0dXJuIF8oIm91 dCBvZiBtZW1vcnkgd2hpbGUgY29uc3RydWN0aW5nIGVycm9yIGRlc2NyaXB0aW9uIik7CiAjZW5k aWYKKwkKKwlpZiAoIWxleC0+ZXJyb3Jtc2cpCisJCXJldHVybiBfKCJvdXQgb2YgbWVtb3J5IHdo aWxlIGNvbnN0cnVjdGluZyBlcnJvciBkZXNjcmlwdGlvbiIpOwogCiAJcmV0dXJuIGxleC0+ZXJy b3Jtc2ctPmRhdGE7CiB9Ci0tIAoyLjQzLjAKCg== --_004_6c6cc4b06b8e4f3ab91029c5e7f2e479rutokenru_--