| commit | f405bfc4d0e401955f757ab5b6820732132453cf | |
| author | tgl <tgl> | |
| Thu, 29 May 2008 22:02:44 +0000 (29 22:02 +0000) | ||
| committer | tgl <tgl> | |
| Thu, 29 May 2008 22:02:44 +0000 (29 22:02 +0000) | ||
| tree | eae4938b9faf0d95e88b0df568f4bcbf0a4d89ba | treesnapshot (tar.gz zip) |
| parent | 99655f5a48d1ff3354c85fc3b69e19c101c6357a | commitdiff |
Tweak libpq to avoid crashing due to incorrect buffer size calculation when
we are on a 64-bit machine (ie, size_t is wider than int) and someone passes
in a query string that approaches or exceeds INT_MAX bytes. Also, just for
paranoia's sake, guard against similar overflows in sizing the input buffer.
The backend will not in the foreseeable future be prepared to send or receive
strings exceeding 1GB, so I didn't take the more invasive step of switching
all the buffer index variables from int to size_t; though someday we might
want to do that.
I have a suspicion that this is not the only such bug in libpq, but this
fix is enough to take care of the crash reported by Francisco Reyes.
we are on a 64-bit machine (ie, size_t is wider than int) and someone passes
in a query string that approaches or exceeds INT_MAX bytes. Also, just for
paranoia's sake, guard against similar overflows in sizing the input buffer.
The backend will not in the foreseeable future be prepared to send or receive
strings exceeding 1GB, so I didn't take the more invasive step of switching
all the buffer index variables from int to size_t; though someday we might
want to do that.
I have a suspicion that this is not the only such bug in libpq, but this
fix is enough to take care of the crash reported by Francisco Reyes.