Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

input.c

Blame
    • Tom Lane's avatar
      ddec1269
      Guard against empty buffer in gets_fromFile()'s check for a newline. · ddec1269
      Tom Lane authored
      Per the fgets() specification, it cannot return without reading some data
      unless it reports EOF or error.  So the code here assumed that the data
      buffer would necessarily be nonempty when we go to check for a newline
      having been read.  However, Agostino Sarubbo noticed that this could fail
      to be true if the first byte of the data is a NUL (\0).  The fgets() API
      doesn't really work for embedded NULs, which is something I don't feel
      any great need for us to worry about since we generally don't allow NULs
      in SQL strings anyway.  But we should not access off the end of our own
      buffer if the case occurs.  Normally this would just be a harmless read,
      but if you were unlucky the byte before the buffer would contain '\n'
      and we'd overwrite it with '\0', and if you were really unlucky that
      might be valuable data and psql would crash.
      
      Agostino reported this to pgsql-security, but after discussion we concluded
      that it isn't worth treating as a security bug; if you can control the
      input to psql you can do far more interesting things than just maybe-crash
      it.  Nonetheless, it is a bug, so back-patch to all supported versions.
      ddec1269
      History
      Guard against empty buffer in gets_fromFile()'s check for a newline.
      Tom Lane authored
      Per the fgets() specification, it cannot return without reading some data
      unless it reports EOF or error.  So the code here assumed that the data
      buffer would necessarily be nonempty when we go to check for a newline
      having been read.  However, Agostino Sarubbo noticed that this could fail
      to be true if the first byte of the data is a NUL (\0).  The fgets() API
      doesn't really work for embedded NULs, which is something I don't feel
      any great need for us to worry about since we generally don't allow NULs
      in SQL strings anyway.  But we should not access off the end of our own
      buffer if the case occurs.  Normally this would just be a harmless read,
      but if you were unlucky the byte before the buffer would contain '\n'
      and we'd overwrite it with '\0', and if you were really unlucky that
      might be valuable data and psql would crash.
      
      Agostino reported this to pgsql-security, but after discussion we concluded
      that it isn't worth treating as a security bug; if you can control the
      input to psql you can do far more interesting things than just maybe-crash
      it.  Nonetheless, it is a bug, so back-patch to all supported versions.
    input.c 12.43 KiB