pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Compute aggregate argument types correctly in transformAggregate 7+ messages / 1 participants [nested] [flat]
* pgsql: Compute aggregate argument types correctly in transformAggregate @ 2023-11-06 15:38 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2023-11-06 15:38 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compute aggregate argument types correctly in transformAggregateCall(). transformAggregateCall() captures the datatypes of the aggregate's arguments immediately to construct the Aggref.aggargtypes list. This seems reasonable because the arguments have already been transformed --- but there is an edge case where they haven't been. Specifically, if we have an unknown-type literal in an ANY argument position, nothing will have been done with it earlier. But if we also have DISTINCT, then addTargetToGroupList() converts the literal to "text" type, resulting in the aggargtypes list not matching the actual runtime type of the argument. The end result is that the aggregate tries to interpret a "text" value as being of type "unknown", that is a zero-terminated C string. If the text value contains no zero bytes, this could result in disclosure of server memory following the text literal value. To fix, move the collection of the aggargtypes list to the end of transformAggregateCall(), after DISTINCT has been handled. This requires slightly more code, but not a great deal. Our thanks to Jingzhou Fu for reporting this problem. Security: CVE-2023-5868 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/3b0776fde56763c549df35ce9750f3399bc710b2 Modified Files -------------- src/backend/parser/parse_agg.c | 35 +++++++++++++++++++++++------------ src/test/regress/expected/jsonb.out | 7 +++++++ src/test/regress/sql/jsonb.sql | 3 +++ 3 files changed, 33 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Compute aggregate argument types correctly in transformAggregate @ 2023-11-06 15:38 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2023-11-06 15:38 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compute aggregate argument types correctly in transformAggregateCall(). transformAggregateCall() captures the datatypes of the aggregate's arguments immediately to construct the Aggref.aggargtypes list. This seems reasonable because the arguments have already been transformed --- but there is an edge case where they haven't been. Specifically, if we have an unknown-type literal in an ANY argument position, nothing will have been done with it earlier. But if we also have DISTINCT, then addTargetToGroupList() converts the literal to "text" type, resulting in the aggargtypes list not matching the actual runtime type of the argument. The end result is that the aggregate tries to interpret a "text" value as being of type "unknown", that is a zero-terminated C string. If the text value contains no zero bytes, this could result in disclosure of server memory following the text literal value. To fix, move the collection of the aggargtypes list to the end of transformAggregateCall(), after DISTINCT has been handled. This requires slightly more code, but not a great deal. Our thanks to Jingzhou Fu for reporting this problem. Security: CVE-2023-5868 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d3d1e25097db05edd0e6b44321516e1dce144047 Modified Files -------------- src/backend/parser/parse_agg.c | 35 +++++++++++++++++++++++------------ src/test/regress/expected/jsonb.out | 7 +++++++ src/test/regress/sql/jsonb.sql | 3 +++ 3 files changed, 33 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Compute aggregate argument types correctly in transformAggregate @ 2023-11-06 15:38 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2023-11-06 15:38 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compute aggregate argument types correctly in transformAggregateCall(). transformAggregateCall() captures the datatypes of the aggregate's arguments immediately to construct the Aggref.aggargtypes list. This seems reasonable because the arguments have already been transformed --- but there is an edge case where they haven't been. Specifically, if we have an unknown-type literal in an ANY argument position, nothing will have been done with it earlier. But if we also have DISTINCT, then addTargetToGroupList() converts the literal to "text" type, resulting in the aggargtypes list not matching the actual runtime type of the argument. The end result is that the aggregate tries to interpret a "text" value as being of type "unknown", that is a zero-terminated C string. If the text value contains no zero bytes, this could result in disclosure of server memory following the text literal value. To fix, move the collection of the aggargtypes list to the end of transformAggregateCall(), after DISTINCT has been handled. This requires slightly more code, but not a great deal. Our thanks to Jingzhou Fu for reporting this problem. Security: CVE-2023-5868 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4f4a422fbb15e49ff5e9dc410cd8713d63fdda24 Modified Files -------------- src/backend/parser/parse_agg.c | 35 +++++++++++++++++++++++------------ src/test/regress/expected/jsonb.out | 7 +++++++ src/test/regress/sql/jsonb.sql | 3 +++ 3 files changed, 33 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Compute aggregate argument types correctly in transformAggregate @ 2023-11-06 15:38 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2023-11-06 15:38 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compute aggregate argument types correctly in transformAggregateCall(). transformAggregateCall() captures the datatypes of the aggregate's arguments immediately to construct the Aggref.aggargtypes list. This seems reasonable because the arguments have already been transformed --- but there is an edge case where they haven't been. Specifically, if we have an unknown-type literal in an ANY argument position, nothing will have been done with it earlier. But if we also have DISTINCT, then addTargetToGroupList() converts the literal to "text" type, resulting in the aggargtypes list not matching the actual runtime type of the argument. The end result is that the aggregate tries to interpret a "text" value as being of type "unknown", that is a zero-terminated C string. If the text value contains no zero bytes, this could result in disclosure of server memory following the text literal value. To fix, move the collection of the aggargtypes list to the end of transformAggregateCall(), after DISTINCT has been handled. This requires slightly more code, but not a great deal. Our thanks to Jingzhou Fu for reporting this problem. Security: CVE-2023-5868 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9146d0d65073eeb6738db7c21626d8672fda29f9 Modified Files -------------- src/backend/parser/parse_agg.c | 35 +++++++++++++++++++++++------------ src/test/regress/expected/jsonb.out | 7 +++++++ src/test/regress/sql/jsonb.sql | 3 +++ 3 files changed, 33 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Compute aggregate argument types correctly in transformAggregate @ 2023-11-06 15:38 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2023-11-06 15:38 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compute aggregate argument types correctly in transformAggregateCall(). transformAggregateCall() captures the datatypes of the aggregate's arguments immediately to construct the Aggref.aggargtypes list. This seems reasonable because the arguments have already been transformed --- but there is an edge case where they haven't been. Specifically, if we have an unknown-type literal in an ANY argument position, nothing will have been done with it earlier. But if we also have DISTINCT, then addTargetToGroupList() converts the literal to "text" type, resulting in the aggargtypes list not matching the actual runtime type of the argument. The end result is that the aggregate tries to interpret a "text" value as being of type "unknown", that is a zero-terminated C string. If the text value contains no zero bytes, this could result in disclosure of server memory following the text literal value. To fix, move the collection of the aggargtypes list to the end of transformAggregateCall(), after DISTINCT has been handled. This requires slightly more code, but not a great deal. Our thanks to Jingzhou Fu for reporting this problem. Security: CVE-2023-5868 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d3de70fdb76520610583221c38d0c7eaa6573503 Modified Files -------------- src/backend/parser/parse_agg.c | 35 +++++++++++++++++++++++------------ src/test/regress/expected/jsonb.out | 7 +++++++ src/test/regress/sql/jsonb.sql | 3 +++ 3 files changed, 33 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Compute aggregate argument types correctly in transformAggregate @ 2023-11-06 15:38 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2023-11-06 15:38 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compute aggregate argument types correctly in transformAggregateCall(). transformAggregateCall() captures the datatypes of the aggregate's arguments immediately to construct the Aggref.aggargtypes list. This seems reasonable because the arguments have already been transformed --- but there is an edge case where they haven't been. Specifically, if we have an unknown-type literal in an ANY argument position, nothing will have been done with it earlier. But if we also have DISTINCT, then addTargetToGroupList() converts the literal to "text" type, resulting in the aggargtypes list not matching the actual runtime type of the argument. The end result is that the aggregate tries to interpret a "text" value as being of type "unknown", that is a zero-terminated C string. If the text value contains no zero bytes, this could result in disclosure of server memory following the text literal value. To fix, move the collection of the aggargtypes list to the end of transformAggregateCall(), after DISTINCT has been handled. This requires slightly more code, but not a great deal. Our thanks to Jingzhou Fu for reporting this problem. Security: CVE-2023-5868 Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e911afd092c179563bef39839118acb6702066f4 Modified Files -------------- src/backend/parser/parse_agg.c | 35 +++++++++++++++++++++++------------ src/test/regress/expected/jsonb.out | 7 +++++++ src/test/regress/sql/jsonb.sql | 3 +++ 3 files changed, 33 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Compute aggregate argument types correctly in transformAggregate @ 2023-11-06 15:38 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2023-11-06 15:38 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Compute aggregate argument types correctly in transformAggregateCall(). transformAggregateCall() captures the datatypes of the aggregate's arguments immediately to construct the Aggref.aggargtypes list. This seems reasonable because the arguments have already been transformed --- but there is an edge case where they haven't been. Specifically, if we have an unknown-type literal in an ANY argument position, nothing will have been done with it earlier. But if we also have DISTINCT, then addTargetToGroupList() converts the literal to "text" type, resulting in the aggargtypes list not matching the actual runtime type of the argument. The end result is that the aggregate tries to interpret a "text" value as being of type "unknown", that is a zero-terminated C string. If the text value contains no zero bytes, this could result in disclosure of server memory following the text literal value. To fix, move the collection of the aggargtypes list to the end of transformAggregateCall(), after DISTINCT has been handled. This requires slightly more code, but not a great deal. Our thanks to Jingzhou Fu for reporting this problem. Security: CVE-2023-5868 Branch ------ REL_11_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8c6633f4deb6ace445fc3d72d54585c373187d2d Modified Files -------------- src/backend/parser/parse_agg.c | 35 +++++++++++++++++++++++------------ src/test/regress/expected/jsonb.out | 7 +++++++ src/test/regress/sql/jsonb.sql | 3 +++ 3 files changed, 33 insertions(+), 12 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2023-11-06 15:38 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2023-11-06 15:38 pgsql: Compute aggregate argument types correctly in transformAggregate Tom Lane <tgl@sss.pgh.pa.us> 2023-11-06 15:38 pgsql: Compute aggregate argument types correctly in transformAggregate Tom Lane <tgl@sss.pgh.pa.us> 2023-11-06 15:38 pgsql: Compute aggregate argument types correctly in transformAggregate Tom Lane <tgl@sss.pgh.pa.us> 2023-11-06 15:38 pgsql: Compute aggregate argument types correctly in transformAggregate Tom Lane <tgl@sss.pgh.pa.us> 2023-11-06 15:38 pgsql: Compute aggregate argument types correctly in transformAggregate Tom Lane <tgl@sss.pgh.pa.us> 2023-11-06 15:38 pgsql: Compute aggregate argument types correctly in transformAggregate Tom Lane <tgl@sss.pgh.pa.us> 2023-11-06 15:38 pgsql: Compute aggregate argument types correctly in transformAggregate Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox