Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit ed0b228

Browse files
committed
Guard against empty buffer in gets_fromFile()'s check for a newline.
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.
1 parent 8d19d0e commit ed0b228

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

src/bin/psql/input.c

+1-1
Original file line numberDiff line numberDiff line change
@@ -229,7 +229,7 @@ gets_fromFile(FILE *source)
229229
}
230230

231231
/* EOL? */
232-
if (buffer->data[buffer->len - 1] == '\n')
232+
if (buffer->len > 0 && buffer->data[buffer->len - 1] == '\n')
233233
{
234234
buffer->data[buffer->len - 1] = '\0';
235235
return pg_strdup(buffer->data);

0 commit comments

Comments
 (0)