Skip to content

Commit b3db5fd

Browse files
tglsfdctglsfdc
committed
Last-minute updates for release notes.
Security: CVE-2024-10976, CVE-2024-10977, CVE-2024-10978, CVE-2024-10979
1 parent dc73787 commit b3db5fd

File tree

1 file changed

+179
-1
lines changed

1 file changed

+179
-1
lines changed

‎doc/src/sgml/release-13.sgml

+179-1
Original file line numberDiff line numberDiff line change
@@ -26,7 +26,7 @@
2626
However, if you have ever detached a partition from a partitioned
2727
table that has a foreign-key reference to another partitioned table,
2828
and not dropped the former partition, then you may have catalog and/or
29-
data corruption to repair, as detailed in the first changelog entry
29+
data corruption to repair, as detailed in the fifth changelog entry
3030
below.
3131
</para>
3232

@@ -43,6 +43,184 @@
4343

4444
<listitem>
4545
<!--
46+
Author: Nathan Bossart <nathan@postgresql.org>
47+
Branch: master [cd7ab5753] 2024-11-11 09:00:00 -0600
48+
Branch: REL_17_STABLE [edcda9bb4] 2024-11-11 09:00:00 -0600
49+
Branch: REL_16_STABLE [562289460] 2024-11-11 09:00:00 -0600
50+
Branch: REL_15_STABLE [6db5ea8de] 2024-11-11 09:00:00 -0600
51+
Branch: REL_14_STABLE [4e51030af] 2024-11-11 09:00:00 -0600
52+
Branch: REL_13_STABLE [952ff31e2] 2024-11-11 09:00:00 -0600
53+
Branch: REL_12_STABLE [448525e8a] 2024-11-11 09:00:00 -0600
54+
-->
55+
<para>
56+
Ensure cached plans are marked as dependent on the calling role when
57+
RLS applies to a non-top-level table reference (Nathan Bossart)
58+
<ulink url="&commit_baseurl;952ff31e2">&sect;</ulink>
59+
</para>
60+
61+
<para>
62+
If a CTE, subquery, sublink, security invoker view, or coercion
63+
projection in a query references a table with row-level security
64+
policies, we neglected to mark the resulting plan as potentially
65+
dependent on which role is executing it. This could lead to later
66+
query executions in the same session using the wrong plan, and then
67+
returning or hiding rows that should have been hidden or returned
68+
instead.
69+
</para>
70+
71+
<para>
72+
The <productname>PostgreSQL</productname> Project thanks
73+
Wolfgang Walther for reporting this problem.
74+
(CVE-2024-10976)
75+
</para>
76+
</listitem>
77+
78+
<listitem>
79+
<!--
80+
Author: Michael Paquier <michael@paquier.xyz>
81+
Branch: master [bf8835ea9] 2024-11-11 10:19:52 +0900
82+
Branch: REL_17_STABLE [a5cc4c667] 2024-11-11 10:19:56 +0900
83+
Branch: REL_16_STABLE [67d28bd02] 2024-11-11 10:19:58 +0900
84+
Branch: REL_15_STABLE [d2c3e31c1] 2024-11-11 10:19:59 +0900
85+
Branch: REL_14_STABLE [e6c945476] 2024-11-11 10:20:01 +0900
86+
Branch: REL_13_STABLE [7b49707b7] 2024-11-11 10:20:02 +0900
87+
Branch: REL_12_STABLE [2a951ef0a] 2024-11-11 10:20:03 +0900
88+
-->
89+
<para>
90+
Make <application>libpq</application> discard error messages
91+
received during SSL or GSS protocol negotiation (Jacob Champion)
92+
<ulink url="&commit_baseurl;7b49707b7">&sect;</ulink>
93+
</para>
94+
95+
<para>
96+
An error message received before encryption negotiation is completed
97+
might have been injected by a man-in-the-middle, rather than being
98+
real server output. Reporting it opens the door to various security
99+
hazards; for example, the message might spoof a query result that a
100+
careless user could mistake for correct output. The best answer
101+
seems to be to discard such data and rely only
102+
on <application>libpq</application>'s own report of the connection
103+
failure.
104+
</para>
105+
106+
<para>
107+
The <productname>PostgreSQL</productname> Project thanks
108+
Jacob Champion for reporting this problem.
109+
(CVE-2024-10977)
110+
</para>
111+
</listitem>
112+
113+
<listitem>
114+
<!--
115+
Author: Tom Lane <tgl@sss.pgh.pa.us>
116+
Branch: master [5a2fed911] 2024-11-11 10:29:54 -0500
117+
Branch: REL_17_STABLE [cd82afdda] 2024-11-11 10:29:54 -0500
118+
Branch: REL_16_STABLE [ae340d031] 2024-11-11 10:29:54 -0500
119+
Branch: REL_15_STABLE [a5d2e6205] 2024-11-11 10:29:54 -0500
120+
Branch: REL_14_STABLE [2a68808e2] 2024-11-11 10:29:54 -0500
121+
Branch: REL_13_STABLE [76123ded6] 2024-11-11 10:29:54 -0500
122+
Branch: REL_12_STABLE [4c9d96f74] 2024-11-11 10:29:54 -0500
123+
Branch: master [73c9f91a1] 2024-11-11 17:05:53 -0500
124+
Branch: REL_17_STABLE [f4f5d27d8] 2024-11-11 17:05:53 -0500
125+
Branch: REL_16_STABLE [95f5a5237] 2024-11-11 17:05:53 -0500
126+
Branch: REL_15_STABLE [109a32380] 2024-11-11 17:05:53 -0500
127+
Branch: REL_14_STABLE [00b94e8e2] 2024-11-11 17:05:53 -0500
128+
Branch: REL_13_STABLE [dc7378793] 2024-11-11 17:05:53 -0500
129+
Branch: REL_12_STABLE [0edad8654] 2024-11-11 17:05:53 -0500
130+
-->
131+
<para>
132+
Fix unintended interactions between <command>SET SESSION
133+
AUTHORIZATION</command> and <command>SET ROLE</command> (Tom Lane)
134+
<ulink url="&commit_baseurl;76123ded6">&sect;</ulink>
135+
<ulink url="&commit_baseurl;dc7378793">&sect;</ulink>
136+
</para>
137+
138+
<para>
139+
The SQL standard mandates that <command>SET SESSION
140+
AUTHORIZATION</command> have a side-effect of doing <command>SET
141+
ROLE NONE</command>. Our implementation of that was flawed,
142+
creating more interaction between the two settings than intended.
143+
Notably, rolling back a transaction that had done <command>SET
144+
SESSION AUTHORIZATION</command> would revert <literal>ROLE</literal>
145+
to <literal>NONE</literal> even if that had not been the previous
146+
state, so that the effective user ID might now be different from
147+
what it had been before the transaction. Transiently
148+
setting <varname>session_authorization</varname> in a
149+
function <literal>SET</literal> clause had a similar effect.
150+
A related bug was that if a parallel worker
151+
inspected <literal>current_setting('role')</literal>, it
152+
saw <literal>none</literal> even when it should see something else.
153+
</para>
154+
155+
<para>
156+
The <productname>PostgreSQL</productname> Project thanks
157+
Tom Lane for reporting this problem.
158+
(CVE-2024-10978)
159+
</para>
160+
</listitem>
161+
162+
<listitem>
163+
<!--
164+
Author: Noah Misch <noah@leadboat.com>
165+
Branch: master [b7e3a52a8] 2024-11-11 06:23:43 -0800
166+
Branch: REL_17_STABLE [3ebcfa54d] 2024-11-11 06:23:46 -0800
167+
Branch: REL_16_STABLE [8fe3e697a] 2024-11-11 06:23:47 -0800
168+
Branch: REL_15_STABLE [e530835c6] 2024-11-11 06:23:47 -0800
169+
Branch: REL_14_STABLE [d15ec27c9] 2024-11-11 06:23:47 -0800
170+
Branch: REL_13_STABLE [e428cd058] 2024-11-11 06:23:48 -0800
171+
Branch: REL_12_STABLE [2ab12d860] 2024-11-11 06:23:48 -0800
172+
Author: Tom Lane <tgl@sss.pgh.pa.us>
173+
Branch: REL_14_STABLE [f89bd92c9] 2024-11-11 10:42:32 -0500
174+
Branch: REL_13_STABLE [6bccd7b03] 2024-11-11 10:42:32 -0500
175+
Branch: REL_12_STABLE [b1e58defb] 2024-11-11 10:42:32 -0500
176+
Branch: master [a34c33fd2] 2024-11-11 12:20:08 -0500
177+
Branch: REL_17_STABLE [4cd4f3b97] 2024-11-11 12:20:08 -0500
178+
Branch: REL_16_STABLE [88269df4d] 2024-11-11 12:20:08 -0500
179+
Branch: REL_16_STABLE [168579e23] 2024-11-11 12:27:06 -0500
180+
Author: Noah Misch <noah@leadboat.com>
181+
Branch: REL_16_STABLE [c335264c9] 2024-11-11 10:55:18 -0800
182+
Branch: REL_15_STABLE [16ed4f4d0] 2024-11-11 10:56:05 -0800
183+
Branch: REL_14_STABLE [c1fff7b1b] 2024-11-11 10:56:09 -0800
184+
Branch: REL_13_STABLE [9f97c31c2] 2024-11-11 10:56:12 -0800
185+
Branch: REL_12_STABLE [1e457468f] 2024-11-11 10:56:14 -0800
186+
Author: Tom Lane <tgl@sss.pgh.pa.us>
187+
Branch: master [c4252c9ef] 2024-11-11 13:57:21 -0500
188+
Branch: REL_17_STABLE [8d19f3fea] 2024-11-11 13:57:21 -0500
189+
Branch: REL_16_STABLE [64df88700] 2024-11-11 13:57:40 -0500
190+
Branch: REL_15_STABLE [c834b375a] 2024-11-11 13:57:41 -0500
191+
Branch: REL_14_STABLE [256e34653] 2024-11-11 13:57:41 -0500
192+
Branch: REL_13_STABLE [0bd9560d9] 2024-11-11 13:57:41 -0500
193+
Branch: REL_12_STABLE [9fc1c3a02] 2024-11-11 13:57:41 -0500
194+
-->
195+
<para>
196+
Prevent trusted PL/Perl code from changing environment variables
197+
(Andrew Dunstan, Noah Misch)
198+
<ulink url="&commit_baseurl;e428cd058">&sect;</ulink>
199+
<ulink url="&commit_baseurl;6bccd7b03">&sect;</ulink>
200+
<ulink url="&commit_baseurl;9f97c31c2">&sect;</ulink>
201+
<ulink url="&commit_baseurl;0bd9560d9">&sect;</ulink>
202+
</para>
203+
204+
<para>
205+
The ability to manipulate process environment variables such
206+
as <literal>PATH</literal> gives an attacker opportunities to
207+
execute arbitrary code. Therefore, <quote>trusted</quote> PLs must
208+
not offer the ability to do that. To fix <literal>plperl</literal>,
209+
replace <varname>%ENV</varname> with a tied hash that rejects any
210+
modification attempt with a warning.
211+
Untrusted <literal>plperlu</literal> retains the ability to change
212+
the environment.
213+
</para>
214+
215+
<para>
216+
The <productname>PostgreSQL</productname> Project thanks
217+
Coby Abrams for reporting this problem.
218+
(CVE-2024-10979)
219+
</para>
220+
</listitem>
221+
222+
<listitem>
223+
<!--
46224
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
47225
Branch: master [53af9491a] 2024-10-22 16:01:18 +0200
48226
Branch: REL_17_STABLE [5914a22f6] 2024-10-22 16:01:18 +0200

0 commit comments

Comments
 (0)