Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
P
postgres-lambda-diff
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Jakob Huber
postgres-lambda-diff
Commits
6bb96c0a
Commit
6bb96c0a
authored
8 years ago
by
Tom Lane
Browse files
Options
Downloads
Patches
Plain Diff
Last-minute updates for release notes.
Security: CVE-2016-5423, CVE-2016-5424
parent
d555d264
No related branches found
No related tags found
No related merge requests found
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/src/sgml/release-9.1.sgml
+80
-0
80 additions, 0 deletions
doc/src/sgml/release-9.1.sgml
with
80 additions
and
0 deletions
doc/src/sgml/release-9.1.sgml
+
80
−
0
View file @
6bb96c0a
...
@@ -40,6 +40,72 @@
...
@@ -40,6 +40,72 @@
<itemizedlist>
<itemizedlist>
<listitem>
<para>
Fix possible mis-evaluation of
nested <literal>CASE</>-<literal>WHEN</> expressions (Heikki
Linnakangas, Michael Paquier, Tom Lane)
</para>
<para>
A <literal>CASE</> expression appearing within the test value
subexpression of another <literal>CASE</> could become confused about
whether its own test value was null or not. Also, inlining of a SQL
function implementing the equality operator used by
a <literal>CASE</> expression could result in passing the wrong test
value to functions called within a <literal>CASE</> expression in the
SQL function's body. If the test values were of different data
types, a crash might result; moreover such situations could be abused
to allow disclosure of portions of server memory. (CVE-2016-5423)
</para>
</listitem>
<listitem>
<para>
Fix client programs' handling of special characters in database and
role names (Noah Misch, Nathan Bossart, Michael Paquier)
</para>
<para>
Numerous places in <application>vacuumdb</> and other client programs
could become confused by database and role names containing double
quotes or backslashes. Tighten up quoting rules to make that safe.
Also, ensure that when a conninfo string is used as a database name
parameter to these programs, it is correctly treated as such throughout.
</para>
<para>
Fix handling of paired double quotes
in <application>psql</>'s <command>\connect</>
and <command>\password</> commands to match the documentation.
</para>
<para>
Introduce a new <option>-reuse-previous</> option
in <application>psql</>'s <command>\connect</> command to allow
explicit control of whether to re-use connection parameters from a
previous connection. (Without this, the choice is based on whether
the database name looks like a conninfo string, as before.) This
allows secure handling of database names containing special
characters in <application>pg_dumpall</> scripts.
</para>
<para>
<application>pg_dumpall</> now refuses to deal with database and role
names containing carriage returns or newlines, as it seems impractical
to quote those characters safely on Windows. In future we may reject
such names on the server side, but that step has not been taken yet.
</para>
<para>
These are considered security fixes because crafted object names
containing special characters could have been used to execute
commands with superuser privileges the next time a superuser
executes <application>pg_dumpall</> or other routine maintenance
operations. (CVE-2016-5424)
</para>
</listitem>
<listitem>
<listitem>
<para>
<para>
Fix corner-case misbehaviors for <literal>IS NULL</>/<literal>IS NOT
Fix corner-case misbehaviors for <literal>IS NULL</>/<literal>IS NOT
...
@@ -77,6 +143,20 @@
...
@@ -77,6 +143,20 @@
</para>
</para>
</listitem>
</listitem>
<listitem>
<para>
Fix several one-byte buffer over-reads in <function>to_number()</>
(Peter Eisentraut)
</para>
<para>
In several cases the <function>to_number()</> function would read one
more character than it should from the input string. There is a
small chance of a crash, if the input happens to be adjacent to the
end of memory.
</para>
</listitem>
<listitem>
<listitem>
<para>
<para>
Avoid unsafe intermediate state during expensive paths
Avoid unsafe intermediate state during expensive paths
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment