pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Guard against enormously long input in pg_saslprep(). 5+ messages / 1 participants [nested] [flat]
* pgsql: Guard against enormously long input in pg_saslprep(). @ 2024-10-28 18:39 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2024-10-28 18:39 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Guard against enormously long input in pg_saslprep(). Coverity complained that pg_saslprep() could suffer integer overflow, leading to under-allocation of the output buffer, if the input string exceeds SIZE_MAX/4. This hazard seems largely hypothetical, but it's easy enough to defend against, so let's do so. This patch creates a third place in src/common/ where we are locally defining MaxAllocSize so that we can test against that in the same way in backend and frontend compiles. That seems like about two places too many, so the next patch will move that into common/fe_memutils.h. I'm hesitant to do that in back branches however. Back-patch to v14. The code looks similar in older branches, but before commit 67a472d71 there was a separate test on the input string length that prevented this hazard. Per Coverity report. Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/bd2843167200f2607972c0defb916daa79ca265f Modified Files -------------- src/common/saslprep.c | 7 +++++++ 1 file changed, 7 insertions(+) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Guard against enormously long input in pg_saslprep(). @ 2024-10-28 18:39 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2024-10-28 18:39 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Guard against enormously long input in pg_saslprep(). Coverity complained that pg_saslprep() could suffer integer overflow, leading to under-allocation of the output buffer, if the input string exceeds SIZE_MAX/4. This hazard seems largely hypothetical, but it's easy enough to defend against, so let's do so. This patch creates a third place in src/common/ where we are locally defining MaxAllocSize so that we can test against that in the same way in backend and frontend compiles. That seems like about two places too many, so the next patch will move that into common/fe_memutils.h. I'm hesitant to do that in back branches however. Back-patch to v14. The code looks similar in older branches, but before commit 67a472d71 there was a separate test on the input string length that prevented this hazard. Per Coverity report. Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e631ed89c2e58464d3969badf2d5d065411b93f0 Modified Files -------------- src/common/saslprep.c | 7 +++++++ 1 file changed, 7 insertions(+) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Guard against enormously long input in pg_saslprep(). @ 2024-10-28 18:39 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2024-10-28 18:39 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Guard against enormously long input in pg_saslprep(). Coverity complained that pg_saslprep() could suffer integer overflow, leading to under-allocation of the output buffer, if the input string exceeds SIZE_MAX/4. This hazard seems largely hypothetical, but it's easy enough to defend against, so let's do so. This patch creates a third place in src/common/ where we are locally defining MaxAllocSize so that we can test against that in the same way in backend and frontend compiles. That seems like about two places too many, so the next patch will move that into common/fe_memutils.h. I'm hesitant to do that in back branches however. Back-patch to v14. The code looks similar in older branches, but before commit 67a472d71 there was a separate test on the input string length that prevented this hazard. Per Coverity report. Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/dfff687f3c25fd114a7ab7d22df645716a98139f Modified Files -------------- src/common/saslprep.c | 7 +++++++ 1 file changed, 7 insertions(+) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Guard against enormously long input in pg_saslprep(). @ 2024-10-28 18:39 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2024-10-28 18:39 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Guard against enormously long input in pg_saslprep(). Coverity complained that pg_saslprep() could suffer integer overflow, leading to under-allocation of the output buffer, if the input string exceeds SIZE_MAX/4. This hazard seems largely hypothetical, but it's easy enough to defend against, so let's do so. This patch creates a third place in src/common/ where we are locally defining MaxAllocSize so that we can test against that in the same way in backend and frontend compiles. That seems like about two places too many, so the next patch will move that into common/fe_memutils.h. I'm hesitant to do that in back branches however. Back-patch to v14. The code looks similar in older branches, but before commit 67a472d71 there was a separate test on the input string length that prevented this hazard. Per Coverity report. Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d130a64ee003bd6f272ad63f2721e204b443a582 Modified Files -------------- src/common/saslprep.c | 7 +++++++ 1 file changed, 7 insertions(+) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Guard against enormously long input in pg_saslprep(). @ 2024-10-28 18:39 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2024-10-28 18:39 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Guard against enormously long input in pg_saslprep(). Coverity complained that pg_saslprep() could suffer integer overflow, leading to under-allocation of the output buffer, if the input string exceeds SIZE_MAX/4. This hazard seems largely hypothetical, but it's easy enough to defend against, so let's do so. This patch creates a third place in src/common/ where we are locally defining MaxAllocSize so that we can test against that in the same way in backend and frontend compiles. That seems like about two places too many, so the next patch will move that into common/fe_memutils.h. I'm hesitant to do that in back branches however. Back-patch to v14. The code looks similar in older branches, but before commit 67a472d71 there was a separate test on the input string length that prevented this hazard. Per Coverity report. Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/16ebf4f9714a2b8f7f17c537743046a9a59c801b Modified Files -------------- src/common/saslprep.c | 7 +++++++ 1 file changed, 7 insertions(+) ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2024-10-28 18:39 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-10-28 18:39 pgsql: Guard against enormously long input in pg_saslprep(). Tom Lane <tgl@sss.pgh.pa.us> 2024-10-28 18:39 pgsql: Guard against enormously long input in pg_saslprep(). Tom Lane <tgl@sss.pgh.pa.us> 2024-10-28 18:39 pgsql: Guard against enormously long input in pg_saslprep(). Tom Lane <tgl@sss.pgh.pa.us> 2024-10-28 18:39 pgsql: Guard against enormously long input in pg_saslprep(). Tom Lane <tgl@sss.pgh.pa.us> 2024-10-28 18:39 pgsql: Guard against enormously long input in pg_saslprep(). 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