From: Tom Lane <tgl@sss.pgh.pa.us>
To: Varik Matevosyan <varikmatevosyan@gmail.com>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] contrib/xml2: guard against signed integer overflow in
 parse_params
In-reply-to: 
 <CA+bBooj48K08uKpAKyciPRdbOJ_5qCqz9nr2m2wzr8E5s102Hw@mail.gmail.com>
References: 
 <CA+bBooj48K08uKpAKyciPRdbOJ_5qCqz9nr2m2wzr8E5s102Hw@mail.gmail.com>
Comments: In-reply-to Varik Matevosyan <varikmatevosyan@gmail.com>
	message dated "Mon, 04 May 2026 15:26:50 +0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <186449.1777900860.1@sss.pgh.pa.us>
Date: Mon, 04 May 2026 09:21:00 -0400
Message-ID: <186450.1777900860@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/186450.1777900860%40sss.pgh.pa.us>
Precedence: bulk

Varik Matevosyan <varikmatevosyan@gmail.com> writes:
> Small robustness fix for contrib/xml2/parse_params. The doubling
> of max_params relies on signed-integer overflow wrapping to a value
> that AllocSizeIsValid then rejects, which is both UB and incidental
> safety.

There are many many places in our tree that handle that the same way.
The argument that it's UB is nonsense, because AllocSizeIsValid
rejects values >= 1G, so that it will fail on the iteration before
the integer counter can overflow.  (This is indeed exactly why that
limit is 1G and not 2G; see the comment for MaxAllocSize.)

I think this proposal makes parse_params less like other code,
not more so, so I don't think we need extra code here.

			regards, tom lane