aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-05-10 10:44:38 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2021-05-10 10:44:38 -0400
commit2fb809d3e1927c0885ad80e18dd3a3aacd612b8b (patch)
treec8ffa8a7a68ad448515c6d1dd85f4bdf9b85e581 /src/backend/executor/nodeModifyTable.c
parentd215576e2ac3f9c020f7b13110d234dd87caffba (diff)
downloadpostgresql-2fb809d3e1927c0885ad80e18dd3a3aacd612b8b.tar.gz
postgresql-2fb809d3e1927c0885ad80e18dd3a3aacd612b8b.zip
Prevent integer overflows in array subscripting calculations.
While we were (mostly) careful about ensuring that the dimensions of arrays aren't large enough to cause integer overflow, the lower bound values were generally not checked. This allows situations where lower_bound + dimension overflows an integer. It seems that that's harmless so far as array reading is concerned, except that array elements with subscripts notionally exceeding INT_MAX are inaccessible. However, it confuses various array-assignment logic, resulting in a potential for memory stomps. Fix by adding checks that array lower bounds aren't large enough to cause lower_bound + dimension to overflow. (Note: this results in disallowing cases where the last subscript position would be exactly INT_MAX. In principle we could probably allow that, but there's a lot of code that computes lower_bound + dimension and would need adjustment. It seems doubtful that it's worth the trouble/risk to allow it.) Somewhat independently of that, array_set_element() was careless about possible overflow when checking the subscript of a fixed-length array, creating a different route to memory stomps. Fix that too. Security: CVE-2021-32027
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions