public inbox for [email protected]  
help / color / mirror / Atom feed
[PATCH 2/3] Allow composite types in bootstrap
4+ messages / 4 participants
[nested] [flat]

* [PATCH 2/3] Allow composite types in bootstrap
@ 2020-11-17 15:28 Justin Pryzby <[email protected]>
  0 siblings, 0 replies; 4+ messages in thread

From: Justin Pryzby @ 2020-11-17 15:28 UTC (permalink / raw)

---
 src/backend/bootstrap/bootstrap.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c
index 18eb62ca47..e4fc75ab84 100644
--- a/src/backend/bootstrap/bootstrap.c
+++ b/src/backend/bootstrap/bootstrap.c
@@ -916,6 +916,7 @@ gettype(char *type)
 {
 	if (Typ != NIL)
 	{
+		static bool did_reread PG_USED_FOR_ASSERTS_ONLY = false; /* Already reread pg_types */
 		ListCell *lc;
 
 		foreach (lc, Typ)
@@ -927,6 +928,33 @@ gettype(char *type)
 				return app->am_oid;
 			}
 		}
+
+		/*
+		 * The type wasn't known; check again to handle composite
+		 * types, added since first populating the array.
+		 */
+
+		/*
+		 * Once all the types are populated and we handled composite
+		 * types, shouldn't need to do that again.
+		 */
+		Assert(!did_reread);
+		did_reread = true;
+
+		list_free_deep(Typ);
+		Typ = NULL;
+		populate_typ_array();
+
+		/* Need to avoid infinite recursion... */
+		foreach (lc, Typ)
+		{
+			struct typmap *app = lfirst(lc);
+			if (strncmp(NameStr(app->am_typ.typname), type, NAMEDATALEN) == 0)
+			{
+				Ap = app;
+				return app->am_oid;
+			}
+		}
 	}
 	else
 	{
-- 
2.26.2


--------------1F4A19FEB5D90C72707AFA7B
Content-Type: text/x-patch; charset=UTF-8;
 name="0003-Extended-statistics-on-expressions-20210122.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="0003-Extended-statistics-on-expressions-20210122.patch"



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* [PATCH] snowball: fix potential NULL dereference
@ 2025-02-11 08:52 Коротков Максим <[email protected]>
  2025-02-11 16:53 ` Re: [PATCH] snowball: fix potential NULL dereference Tom Lane <[email protected]>
  0 siblings, 1 reply; 4+ messages in thread

From: Коротков Максим @ 2025-02-11 08:52 UTC (permalink / raw)
  To: pgsql-hackers

Hi all,
I found the case of potential NULL pointer dereference.
In snowball/libstemmer/api.c if we transfer control to the SN_create_env() function
by using the error label when there is a memory allocation error of z->p or z->S,
we can then dereference the NULL pointer z->S in the function SN_close_env().
Added the pointer check for avoiding a potential problem.
---
Best regards, Korotkov Maksim
PostgresPro
[email protected]


Attachments:

  [text/x-patch] 0001-snowball-fix-potential-NULL-dereference.patch (1.3K, ../../1d1a46-67ab1000-21-80c451@83151435/2-0001-snowball-fix-potential-NULL-dereference.patch)
  download | inline diff:
From c4596f6e23c4f5e9ae8294d51783afb733eccc9d Mon Sep 17 00:00:00 2001
From: Maksim Korotkov <[email protected]>
Date: Tue, 24 Dec 2024 17:07:12 +0300
Subject: [PATCH] snowball: fix potential NULL dereference

If we transfer control to the SN_create_env() function by using the error
label when there is a memory allocation error of z->p or z->S,
we can then dereference the NULL pointer z->S in the function SN_close_env().
Added the pointer check for avoiding potential problem.

Fixes: 140d4ebcb4 ("Tsearch2 functionality migrates to core.  The bulk of this work is by Oleg Bartunov and Teodor Sigaev, but I did a lot of editorializing, so anything that's broken is probably my fault.")

Found by Postgres Pro with Svace static analyzer
Signed-off-by: Maksim Korotkov <[email protected]>
---
 src/backend/snowball/libstemmer/api.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/backend/snowball/libstemmer/api.c b/src/backend/snowball/libstemmer/api.c
index 375938e6d1..3a7169abd8 100644
--- a/src/backend/snowball/libstemmer/api.c
+++ b/src/backend/snowball/libstemmer/api.c
@@ -34,7 +34,7 @@ error:
 extern void SN_close_env(struct SN_env * z, int S_size)
 {
     if (z == NULL) return;
-    if (S_size)
+    if (S_size && z->S)
     {
         int i;
         for (i = 0; i < S_size; i++)
-- 
2.34.1



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: [PATCH] snowball: fix potential NULL dereference
  2025-02-11 08:52 [PATCH] snowball: fix potential NULL dereference Коротков Максим <[email protected]>
@ 2025-02-11 16:53 ` Tom Lane <[email protected]>
  2025-02-17 12:12   ` Re: [PATCH] snowball: fix potential NULL dereference Maksim Korotkov <[email protected]>
  0 siblings, 1 reply; 4+ messages in thread

From: Tom Lane @ 2025-02-11 16:53 UTC (permalink / raw)
  To: Коротков Максим <[email protected]>; +Cc: pgsql-hackers

=?utf-8?q?=D0=9A=D0=BE=D1=80=D0=BE=D1=82=D0=BA=D0=BE=D0=B2_=D0=9C=D0=B0=D0=BA=D1=81=D0=B8=D0=BC?= <[email protected]> writes:
> I found the case of potential NULL pointer dereference.
> In snowball/libstemmer/api.c if we transfer control to the SN_create_env() function
> by using the error label when there is a memory allocation error of z->p or z->S,
> we can then dereference the NULL pointer z->S in the function SN_close_env().
> Added the pointer check for avoiding a potential problem.

I believe you are right: OOM partway through SN_create_env would fail.
However, backend/snowball is not our code so applying our own local
patch is not the way to fix it.  You should report this upstream;
see src/backend/snowball/README.

(Whenever they apply the patch, we should then re-sync...)

			regards, tom lane






^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: [PATCH] snowball: fix potential NULL dereference
  2025-02-11 08:52 [PATCH] snowball: fix potential NULL dereference Коротков Максим <[email protected]>
  2025-02-11 16:53 ` Re: [PATCH] snowball: fix potential NULL dereference Tom Lane <[email protected]>
@ 2025-02-17 12:12   ` Maksim Korotkov <[email protected]>
  0 siblings, 0 replies; 4+ messages in thread

From: Maksim Korotkov @ 2025-02-17 12:12 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: pgsql-hackers

Hi
On 2025-02-11 19:53, Tom Lane wrote:
> You should report this upstream;
> (Whenever they apply the patch, we should then re-sync...)

FYI, the patch to fix this problem was applied by upstream.
---
Best regards, Korotkov Maksim
PostgresPro
[email protected]






^ permalink  raw  reply  [nested|flat] 4+ messages in thread


end of thread, other threads:[~2025-02-17 12:12 UTC | newest]

Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-11-17 15:28 [PATCH 2/3] Allow composite types in bootstrap Justin Pryzby <[email protected]>
2025-02-11 08:52 [PATCH] snowball: fix potential NULL dereference Коротков Максим <[email protected]>
2025-02-11 16:53 ` Re: [PATCH] snowball: fix potential NULL dereference Tom Lane <[email protected]>
2025-02-17 12:12   ` Re: [PATCH] snowball: fix potential NULL dereference Maksim Korotkov <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox