Guard against empty buffer in gets_fromFile()'s check for a newline.
authorTom Lane <[email protected]>
Thu, 28 Jul 2016 22:57:24 +0000 (18:57 -0400)
committerTom Lane <[email protected]>
Thu, 28 Jul 2016 22:57:48 +0000 (18:57 -0400)
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.

src/bin/psql/input.c

index 1b02f9324ad36e72377afa0592ff8b1ff7a3c22f..e2e61bfc3bee2e8702f9cb7fce71b8bc6842942e 100644 (file)
@@ -218,7 +218,7 @@ gets_fromFile(FILE *source)
                }
 
                /* EOL? */
-               if (buffer->data[buffer->len - 1] == '\n')
+               if (buffer->len > 0 && buffer->data[buffer->len - 1] == '\n')
                {
                        buffer->data[buffer->len - 1] = '\0';
                        return pg_strdup(buffer->data);