Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Jeremy Evans <code(at)jeremyevans(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
Date: 2018-09-09 01:39:42
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

I wrote:
> Hm. So I can reproduce the crash on NetBSD as well as OpenBSD, using
> the test method I showed before ... but *not* on FreeBSD 11.0 x86_64,
> even though that's certainly an ELF system. So now I'm confused again.

Further debugging shows conclusively that libpq *is* calling the backend
copy of pg_saslprep, and that what it passes to free() came from palloc()
in the case at hand. Apparently, the default malloc library in this
version of FreeBSD is not as good at noticing bad free() arguments as
the other platforms I tested. Probably, the process's malloc freelist
is now corrupt and that would eventually lead to a crash, but I did not
try to prove it.

Adding the proposed patch to the FreeBSD stanza of Makefile.shlib
does cause libpq to start calling the desired version of pg_saslprep.

On the other front of developing a test case to detect this problem,
I did not have much luck with mechanizing this specific test: it
requires some functionality we have in the TAP tests, like setting
up an installation with SCRAM password authentication enabled, as
well as other functionality we have in the isolation tester, like
doing things in two different sessions concurrently. But we don't
really need to test this *exact* scenario; we just need something
that will behave differently if libpq links to backend versions of
any of the problematic functions. I'm a bit tempted to add
something like this to saslprep.c:

return true;
return false;

and then have libpq test to make sure this function returns true.

regards, tom lane

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2018-09-09 03:47:54 Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
Previous Message PG Bug reporting form 2018-09-09 01:18:44 BUG #15374: Error al ejecutar el paso de post instalacion