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