public inbox for [email protected]  

help / color / mirror / Atom feed
From: [email protected]
To: [email protected]
Subject: Patch a potential memory leak in describeOneTableDetails()
Date: Fri, 18 Feb 2022 16:12:34 +0800 (GMT+08:00)
Message-ID: <[email protected]> (raw)

Hi all,


I find a potential memory leak in PostgresSQL 14.1, which is in the function describeOneTableDetails (./src/bin/psql/describe.c). The bug has been confirmed by an auditor of <pgsql-bugs>.


Specifically, at line 1603, a memory chunk is allocated with pg_strdup and assigned to tableinfo.reloptions. If the branch takes true at line 1621, the execution path will eventually jump to error_return at line 3394. Unfortunately, the memory is not freed when the function describeOneTableDetail() returns. As a result, the memory is leaked.



Similarly, the two memory chunks (tableinfo.reloftype and tableinfo.relam) allocated at line 1605, 1606 and 1612 may also be leaked for the same reason.







1355 bool
1356 describeTableDetails(const char *pattern, bool verbose, bool showSystem)
1357 {
...
1603     tableinfo.reloptions = pg_strdup(PQgetvalue(res, 0, 9));
1604     tableinfo.tablespace = atooid(PQgetvalue(res, 0, 10));

1605     tableinfo.reloftype = (strcmp(PQgetvalue(res, 0, 11), "") != 0) ?
1606         pg_strdup(PQgetvalue(res, 0, 11)) : NULL;
...
1610     if (pset.sversion >= 120000)
1611         tableinfo.relam = PQgetisnull(res, 0, 14) ?
1612             (char *) NULL : pg_strdup(PQgetvalue(res, 0, 14));
1613     else
1614         tableinfo.relam = NULL;
...

1621     if (tableinfo.relkind == RELKIND_SEQUENCE)
1622     {

...

1737         goto error_return;      /* not an error, just return early */
1738     }

...

3394 error_return:
3395 
3396     /* clean up */
3397     if (printTableInitialized)
3398         printTableCleanup(&cont);
3399     termPQExpBuffer(&buf);
3400     termPQExpBuffer(&title);
3401     termPQExpBuffer(&tmpbuf);
3402 
3403     if (view_def)
3404         free(view_def);
3405 
3406     if (res)
3407         PQclear(res);
3408 
3409     return retval;
3410 }


We believe we can fix the problems by adding corresponding release function before the function returns, such as.




    if (tableinfo.reloptions)
        pg_free (tableinfo.reloptions);
    if (tableinfo.reloftype)
        pg_free (tableinfo.reloftype);
    if (tableinfo.relam)
        pg_free (tableinfo. relam);




I'm looking forward to your reply.


Best,


Wentao

Attachments:

  [text/x-patch] describe.c.patch (390B, ../[email protected]/3-describe.c.patch)
  download | inline diff:
--- describe.c	2022-01-26 16:17:51.353135285 +0800
+++ describe_Patch.c	2022-02-18 15:57:51.099581978 +0800
@@ -3406,6 +3406,13 @@
 	if (res)
 		PQclear(res);
 
+    if (tableinfo.reloptions)
+        pg_free (tableinfo.reloptions);
+    if (tableinfo.reloftype)
+        pg_free (tableinfo.reloftype);
+    if (tableinfo.relam)
+        pg_free (tableinfo. relam);
+
 	return retval;
 }
 


view thread (2+ messages)

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Patch a potential memory leak in describeOneTableDetails()
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

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