Patch a potential memory leak in describeOneTableDetails()

From: wliang(at)stu(dot)xidian(dot)edu(dot)cn
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Patch a potential memory leak in describeOneTableDetails()
Date: 2022-02-18 08:12:34
Message-ID: 38da8aa3.14ec.17f0be3d3ad.Coremail.wliang@stu.xidian.edu.cn
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
describe.c.patch text/x-patch 390 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2022-02-18 08:21:49 Re: logical replication empty transactions
Previous Message Michael Paquier 2022-02-18 07:49:48 Re: improve --with-lz4 install documentation