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

On 09/07 11:15, Michael Paquier wrote:
> On Fri, Sep 07, 2018 at 10:55:18AM -0700, Jeremy Evans wrote:
> > Here's the backtrace:
> >
> > #5 0x000017c20a6b8b00 in pg_fe_scram_free (opaq=0x17c223712000) at fe-auth-scram.c:127
> > #6 0x000017c20a6b9d20 in pqDropConnection (conn=0x17c1dac61800, flushInput=1 '\001') at fe-connect.c:479
> > #7 0x000017c20a6bf95e in closePGconn (conn=0x17c1dac61800) at fe-connect.c:3710
> >
> > Hopefully this helps. If you need more information, please let me know.
>
> Thanks. This fails when freeing the password field in fe_scram_state.
> I have a question: does your password use non-ASCII characters which
> could make SASLprep to be run on the password string? The result string
> from pg_saslprep allocates a new string for any results returned by
> reading the code, I am wondering if we could be missing something..

No, the user mapping password is comprised of hex-ascii characters: [0-9a-f]{16}

In case it helps, here's the content of opaq from gdb (with the specific
strings cleared).

print *((fe_scram_state *) opaq)
{
state = FE_SCRAM_FINISHED,
username = 0x17c267526380 "...",
password = 0x17c1ee153398 <Address 0x17c1ee153398 out of bounds>,
SaltedPassword = 0x17c223712018 "...",
client_nonce = 0x17c267529f60 "...",
client_first_message_bare = 0x17c223711da0 "...",
client_final_message_without_proof = 0x17c271ca19c0 "...",
server_first_message = 0x17c1ea48a400 "...",
salt = 0x17c2675261c0 "...",
saltlen = 16,
iterations = 4096,
nonce = 0x17c2179e9880 "...",
server_final_message = 0x17c271ca1a40 "...",
ServerSignature = 0x17c223712078 "..."
}

Thanks,
Jeremy