Re: [COMMITTERS] pgsql: Fix failure due to accessing an

Log Message:
-----------
Fix failure due to accessing an already-freed tuple descriptor in a plan
involving HashAggregate over SubqueryScan (this is the known case, there
may well be more). The bug is only latent in releases before 8.2 since they
didn't try to access tupletable slots' descriptors during ExecDropTupleTable.
The least bogus fix seems to be to make subqueries share the parent query's
memory context, so that tupdescs they create will have the same lifespan as
those of the parent query. There are comments in the code envisioning going
even further by not having a separate child EState at all, but that will
require rethinking executor access to range tables, which I don't want to
tackle right now. Per bug report from Jean-Pierre Pelletier.

Tags:
----
REL8_2_STABLE

Modified Files:
--------------
pgsql/src/backend/executor:
execMain.c (r1.280 -> r1.280.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execMain.c.diff?r1=1.280&r2=1.280.2.1)
execUtils.c (r1.140 -> r1.140.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execUtils.c.diff?r1=1.140&r2=1.140.2.1)
nodeSubplan.c (r1.80 -> r1.80.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeSubplan.c.diff?r1=1.80&r2=1.80.2.1)
nodeSubqueryscan.c (r1.32.2.1 -> r1.32.2.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeSubqueryscan.c.diff?r1=1.32.2.1&r2=1.32.2.2)
pgsql/src/include/executor:
executor.h (r1.130 -> r1.130.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/executor/executor.h.diff?r1=1.130&r2=1.130.2.1)
pgsql/src/include/nodes:
execnodes.h (r1.161 -> r1.161.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/execnodes.h.diff?r1=1.161&r2=1.161.2.1)

Tom,

Is this a fix for security hole/vulnerability?
One of our engineer claimed that double free bug itself is a
vulnerability, thus 8.2.1 release should be called as "security
release".
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> Log Message:
> -----------
> Fix failure due to accessing an already-freed tuple descriptor in a plan
> involving HashAggregate over SubqueryScan (this is the known case, there
> may well be more). The bug is only latent in releases before 8.2 since they
> didn't try to access tupletable slots' descriptors during ExecDropTupleTable.
> The least bogus fix seems to be to make subqueries share the parent query's
> memory context, so that tupdescs they create will have the same lifespan as
> those of the parent query. There are comments in the code envisioning going
> even further by not having a separate child EState at all, but that will
> require rethinking executor access to range tables, which I don't want to
> tackle right now. Per bug report from Jean-Pierre Pelletier.
>
> Tags:
> ----
> REL8_2_STABLE
>
> Modified Files:
> --------------
> pgsql/src/backend/executor:
> execMain.c (r1.280 -> r1.280.2.1)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execMain.c.diff?r1=1.280&r2=1.280.2.1)
> execUtils.c (r1.140 -> r1.140.2.1)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execUtils.c.diff?r1=1.140&r2=1.140.2.1)
> nodeSubplan.c (r1.80 -> r1.80.2.1)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeSubplan.c.diff?r1=1.80&r2=1.80.2.1)
> nodeSubqueryscan.c (r1.32.2.1 -> r1.32.2.2)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeSubqueryscan.c.diff?r1=1.32.2.1&r2=1.32.2.2)
> pgsql/src/include/executor:
> executor.h (r1.130 -> r1.130.2.1)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/executor/executor.h.diff?r1=1.130&r2=1.130.2.1)
> pgsql/src/include/nodes:
> execnodes.h (r1.161 -> r1.161.2.1)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/execnodes.h.diff?r1=1.161&r2=1.161.2.1)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

Tom,

Is this a fix for security hole/vulnerability?
One of our engineer claimed that double free bug itself is a
vulnerability, thus 8.2.1 release should be called as "security
release".
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> Log Message:
> -----------
> Fix failure due to accessing an already-freed tuple descriptor in a plan
> involving HashAggregate over SubqueryScan (this is the known case, there
> may well be more). The bug is only latent in releases before 8.2 since they
> didn't try to access tupletable slots' descriptors during ExecDropTupleTable.
> The least bogus fix seems to be to make subqueries share the parent query's
> memory context, so that tupdescs they create will have the same lifespan as
> those of the parent query. There are comments in the code envisioning going
> even further by not having a separate child EState at all, but that will
> require rethinking executor access to range tables, which I don't want to
> tackle right now. Per bug report from Jean-Pierre Pelletier.
>
> Tags:
> ----
> REL8_2_STABLE
>
> Modified Files:
> --------------
> pgsql/src/backend/executor:
> execMain.c (r1.280 -> r1.280.2.1)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execMain.c.diff?r1=1.280&r2=1.280.2.1)
> execUtils.c (r1.140 -> r1.140.2.1)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execUtils.c.diff?r1=1.140&r2=1.140.2.1)
> nodeSubplan.c (r1.80 -> r1.80.2.1)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeSubplan.c.diff?r1=1.80&r2=1.80.2.1)
> nodeSubqueryscan.c (r1.32.2.1 -> r1.32.2.2)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeSubqueryscan.c.diff?r1=1.32.2.1&r2=1.32.2.2)
> pgsql/src/include/executor:
> executor.h (r1.130 -> r1.130.2.1)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/executor/executor.h.diff?r1=1.130&r2=1.130.2.1)
> pgsql/src/include/nodes:
> execnodes.h (r1.161 -> r1.161.2.1)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/execnodes.h.diff?r1=1.161&r2=1.161.2.1)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> writes:
> One of our engineer claimed that double free bug itself is a
> vulnerability, thus 8.2.1 release should be called as "security
> release".

[ shrug... ] AFAICS the crashing bugs we fixed in 8.2.1 can't be
exploited for anything beyond crashing the backend, and only by an
attacker who can issue arbitrary SQL commands. There are plenty of
other ways to cause momentary DOS if you can do that, so it doesn't
strike me as a big security vulnerability. But if you want to call
it one, you can.

regards, tom lane

Ok, understood.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> writes:
> > One of our engineer claimed that double free bug itself is a
> > vulnerability, thus 8.2.1 release should be called as "security
> > release".
>
> [ shrug... ] AFAICS the crashing bugs we fixed in 8.2.1 can't be
> exploited for anything beyond crashing the backend, and only by an
> attacker who can issue arbitrary SQL commands. There are plenty of
> other ways to cause momentary DOS if you can do that, so it doesn't
> strike me as a big security vulnerability. But if you want to call
> it one, you can.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>