Post-release followup: pg_add_size_overflow() - Mailing list pgsql-hackers

From Jacob Champion
Subject Post-release followup: pg_add_size_overflow()
Date
Msg-id CAOYmi+=+pqUd2MUitvgW1pAJuXgG_TKCVc3_Ek7pe8z9nkf+Ag@mail.gmail.com
Whole thread Raw
Responses Re: Post-release followup: pg_add_size_overflow()
Re: Post-release followup: pg_add_size_overflow()
List pgsql-hackers
Hi all,

The fix for CVE-2025-12818 introduced a few identical copies of size_t
addition, and now that we've released, I'd like to pull those back
into shape.

0001 replaces the bespoke code with a new size_t implementation of the
operators in common/int.h. 0002 additionally makes use of these in
shmem.c, because I couldn't think of a good reason not to.

Couple things to note:

1) The backend's add_size(), which I patterned the CVE fix on
originally, checks if the result is less than either operand. The
common/int.h implementations check only the *first* operand, which
also looks correct to me -- if (result < a), it must also be true that
(result < b), because otherwise (result - b) is nonnegative and we
couldn't have overflowed the addition in the first place. But my brain
is a little fried from looking at these problems, and I could use a +1
from someone with fresh eyes.

2) I have not implemented pg_neg_size_overflow(), because to me it
seems likely to be permanently dead code, and it would require
additional reasoning about the portability of SSIZE_MAX.
(pg_sub_size_overflow(), by contrast, is easy to do and feels like it
might be useful to someone eventually.)

I don't currently plan to backport this, because I don't think the
delta is likely to cause anyone additional pain in the future, but let
me know if you disagree.

Thanks!
--Jacob

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Allow complex data for GUC extra.
Next
From: Mircea Cadariu
Date:
Subject: Re: pg_recvlogical: Prevent flushed data from being re-sent after restarting replication