← Back to branch summary

~ubuntu-branches/ubuntu/trusty/postgresql-9.3/trusty-security

« back to all changes in this revision

Viewing changes to src/backend/storage/ipc/sinval.c

  • Committer: Package Import Robot
  • Author(s): Martin Pitt, CVE-2014-8161
  • Date: 2015-02-06 12:47:00 UTC
  • mfrom: (1.2.1) (18.1.1 trusty-proposed)
  • Revision ID: package-import@ubuntu.com-20150206124700-2br6bkfzuayfy8j8
Tags: 9.3.6-0ubuntu0.14.04
https://launchpad.net/bugs/1418928
* New upstream security/bug fix release (LP: #1418928)
  - Fix buffer overruns in to_char() [CVE-2015-0241]
  - Fix buffer overruns in contrib/pgcrypto [CVE-2015-0243]
  - Fix possible loss of frontend/backend protocol synchronization after an
    error [CVE-2015-0244]
  - Fix information leak via constraint-violation error messages
    [CVE-2014-8161]
  - See release notes for details about other fixes:
    http://www.postgresql.org/about/news/1569/

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/backend/storage/ipc/sinval.c
29
29
 * Because backends sitting idle will not be reading sinval events, we
30
30
 * need a way to give an idle backend a swift kick in the rear and make
31
31
 * it catch up before the sinval queue overflows and forces it to go
32
 
 * through a cache reset exercise.      This is done by sending
 
32
 * through a cache reset exercise.  This is done by sending
33
33
 * PROCSIG_CATCHUP_INTERRUPT to any backend that gets too far behind.
34
34
 *
35
35
 * State for catchup events consists of two flags: one saying whether
68
68
 * NOTE: it is entirely possible for this routine to be invoked recursively
69
69
 * as a consequence of processing inside the invalFunction or resetFunction.
70
70
 * Furthermore, such a recursive call must guarantee that all outstanding
71
 
 * inval messages have been processed before it exits.  This is the reason
 
71
 * inval messages have been processed before it exits.  This is the reason
72
72
 * for the strange-looking choice to use a statically allocated buffer array
73
73
 * and counters; it's so that a recursive call can process messages already
74
74
 * sucked out of sinvaladt.c.
91
91
        /* Deal with any messages still pending from an outer recursion */
92
92
        while (nextmsg < nummsgs)
93
93
        {
94
 
                SharedInvalidationMessage *msg = &messages[nextmsg++];
 
94
                SharedInvalidationMessage msg = messages[nextmsg++];
95
95
 
96
96
                SharedInvalidMessageCounter++;
97
 
                invalFunction(msg);
 
97
                invalFunction(&msg);
98
98
        }
99
99
 
100
100
        do
121
121
 
122
122
                while (nextmsg < nummsgs)
123
123
                {
124
 
                        SharedInvalidationMessage *msg = &messages[nextmsg++];
 
124
                        SharedInvalidationMessage msg = messages[nextmsg++];
125
125
 
126
126
                        SharedInvalidMessageCounter++;
127
 
                        invalFunction(msg);
 
127
                        invalFunction(&msg);
128
128
                }
129
129
 
130
130
                /*
137
137
         * We are now caught up.  If we received a catchup signal, reset that
138
138
         * flag, and call SICleanupQueue().  This is not so much because we need
139
139
         * to flush dead messages right now, as that we want to pass on the
140
 
         * catchup signal to the next slowest backend.  "Daisy chaining" the
 
140
         * catchup signal to the next slowest backend.  "Daisy chaining" the
141
141
         * catchup signal this way avoids creating spikes in system load for what
142
142
         * should be just a background maintenance activity.
143
143
         */
157
157
 *
158
158
 * If we are idle (catchupInterruptEnabled is set), we can safely
159
159
 * invoke ProcessCatchupEvent directly.  Otherwise, just set a flag
160
 
 * to do it later.      (Note that it's quite possible for normal processing
 
160
 * to do it later.  (Note that it's quite possible for normal processing
161
161
 * of the current transaction to cause ReceiveSharedInvalidMessages()
162
162
 * to be run later on; in that case the flag will get cleared again,
163
163
 * since there's no longer any reason to do anything.)
233
233
 * EnableCatchupInterrupt
234
234
 *
235
235
 * This is called by the PostgresMain main loop just before waiting
236
 
 * for a frontend command.      We process any pending catchup events,
 
236
 * for a frontend command.  We process any pending catchup events,
237
237
 * and enable the signal handler to process future events directly.
238
238
 *
239
239
 * NOTE: the signal handler starts out disabled, and stays so until
278
278
 * DisableCatchupInterrupt
279
279
 *
280
280
 * This is called by the PostgresMain main loop just after receiving
281
 
 * a frontend command.  Signal handler execution of catchup events
 
281
 * a frontend command.  Signal handler execution of catchup events
282
282
 * is disabled until the next EnableCatchupInterrupt call.
283
283
 *
284
284
 * The PROCSIG_NOTIFY_INTERRUPT signal handler also needs to call this,