From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Ensure 64bit arithmetic when calculating tapeSpace |
Date: | 2013-07-14 20:47:34 |
Message-ID: | E1UyTCg-0007zl-Ub@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Ensure 64bit arithmetic when calculating tapeSpace
In tuplesort.c:inittapes(), we calculate tapeSpace by first figuring
out how many 'tapes' we can use (maxTapes) and then multiplying the
result by the tape buffer overhead for each. Unfortunately, when
we are on a system with an 8-byte long, we allow work_mem to be
larger than 2GB and that allows maxTapes to be large enough that the
32bit arithmetic can overflow when multiplied against the buffer
overhead.
When this overflow happens, we end up adding the overflow to the
amount of space available, causing the amount of memory allocated to
be larger than work_mem.
Note that to reach this point, you have to set work mem to at least
24GB and be sorting a set which is at least that size. Given that a
user who can set work_mem to 24GB could also set it even higher, if
they were looking to run the system out of memory, this isn't
considered a security issue.
This overflow risk was found by the Coverity scanner.
Back-patch to all supported branches, as this issue has existed
since before 8.4.
Branch
------
REL9_1_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/3cb7a393e8e93b1e67bb1e0d361dd1eb7d928ae7
Modified Files
--------------
src/backend/utils/sort/tuplesort.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2013-07-14 20:47:44 | pgsql: Ensure 64bit arithmetic when calculating tapeSpace |
Previous Message | Stephen Frost | 2013-07-14 20:47:21 | pgsql: Ensure 64bit arithmetic when calculating tapeSpace |