|
42 | 42 | <listitem>
|
43 | 43 | <!--
|
44 | 44 | Author: Tom Lane <tgl@sss.pgh.pa.us>
|
| 45 | +Branch: master [f02b9085a] 2021-05-10 10:44:38 -0400 |
| 46 | +Branch: REL_13_STABLE [467395bfd] 2021-05-10 10:44:38 -0400 |
| 47 | +Branch: REL_12_STABLE [3b0f6a7ae] 2021-05-10 10:44:38 -0400 |
| 48 | +Branch: REL_11_STABLE [06bfbe854] 2021-05-10 10:44:38 -0400 |
| 49 | +Branch: REL_10_STABLE [2fb809d3e] 2021-05-10 10:44:38 -0400 |
| 50 | +Branch: REL9_6_STABLE [0c1caa48d] 2021-05-10 10:44:38 -0400 |
| 51 | +--> |
| 52 | + <para> |
| 53 | + Prevent integer overflows in array subscripting calculations |
| 54 | + (Tom Lane) |
| 55 | + </para> |
| 56 | + |
| 57 | + <para> |
| 58 | + The array code previously did not complain about cases where an |
| 59 | + array's lower bound plus length overflows an integer. This resulted |
| 60 | + in later entries in the array becoming inaccessible (since their |
| 61 | + subscripts could not be written as integers), but more importantly |
| 62 | + it confused subsequent assignment operations. This could lead to |
| 63 | + memory overwrites, with ensuing crashes or unwanted data |
| 64 | + modifications. |
| 65 | + (CVE-2021-32027) |
| 66 | + </para> |
| 67 | + </listitem> |
| 68 | + |
| 69 | + <listitem> |
| 70 | +<!-- |
| 71 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
| 72 | +Branch: master [049e1e2ed] 2021-05-10 11:02:29 -0400 |
| 73 | +Branch: REL_13_STABLE [4a8656a7e] 2021-05-10 11:02:29 -0400 |
| 74 | +Branch: REL_12_STABLE [a5fa3e067] 2021-05-10 11:02:29 -0400 |
| 75 | +Branch: REL_11_STABLE [b7d1f32ff] 2021-05-10 11:02:29 -0400 |
| 76 | +Branch: REL_10_STABLE [52a441362] 2021-05-10 11:02:30 -0400 |
| 77 | +Branch: REL9_6_STABLE [0fcb8e2e0] 2021-05-10 11:02:30 -0400 |
| 78 | +--> |
| 79 | + <para> |
| 80 | + Fix mishandling of <quote>junk</quote> columns in <literal>INSERT |
| 81 | + ... ON CONFLICT ... UPDATE</literal> target lists (Tom Lane) |
| 82 | + </para> |
| 83 | + |
| 84 | + <para> |
| 85 | + If the <literal>UPDATE</literal> list contains any multi-column |
| 86 | + sub-selects (which give rise to junk columns in addition to the |
| 87 | + results proper), the <literal>UPDATE</literal> path would end up |
| 88 | + storing tuples that include the values of the extra junk columns. |
| 89 | + That's fairly harmless in the short run, but if new columns are |
| 90 | + added to the table then the values would become accessible, possibly |
| 91 | + leading to malfunctions if they don't match the datatypes of the |
| 92 | + added columns. |
| 93 | + </para> |
| 94 | + |
| 95 | + <para> |
| 96 | + In addition, in versions supporting cross-partition updates, |
| 97 | + a cross-partition update triggered by such a case had the reverse |
| 98 | + problem: the junk columns were removed from the target list, |
| 99 | + typically causing an immediate crash due to malfunction of the |
| 100 | + multi-column sub-select mechanism. |
| 101 | + (CVE-2021-32028) |
| 102 | + </para> |
| 103 | + </listitem> |
| 104 | + |
| 105 | + <listitem> |
| 106 | +<!-- |
| 107 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
45 | 108 | Branch: master [69d5ca484] 2021-04-13 15:10:18 -0400
|
46 | 109 | Branch: REL_13_STABLE [c39aa1e87] 2021-04-13 15:10:18 -0400
|
47 | 110 | Branch: REL_12_STABLE [a7fcb6285] 2021-04-13 15:10:18 -0400
|
|
0 commit comments