From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrey Rachitskiy <pl0h0yp1@gmail.com>
cc: 1950233439@qq.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19671: IPv4 CIDR Prefix Integer Overflow Bypasses Validation
 in inet/cidr Casts
In-reply-to: 
 <CAB8bMitHLMbrhLkyFHFogAV-W433Db2wrGz80Gmk50Fbcm8JnQ@mail.gmail.com>
References: <19671-9b75c5d8b03fd33b@postgresql.org>
 <CAB8bMitHLMbrhLkyFHFogAV-W433Db2wrGz80Gmk50Fbcm8JnQ@mail.gmail.com>
Comments: In-reply-to Andrey Rachitskiy <pl0h0yp1@gmail.com>
	message dated "Thu, 10 Sep 2026 17:42:08 +0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <914103.1789059519.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Sep 2026 12:58:39 -0400
Message-ID: <914104.1789059519@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/914104.1789059519%40sss.pgh.pa.us>
Precedence: bulk

Andrey Rachitskiy <pl0h0yp1@gmail.com> writes:
> =D1=87=D1=82, 10 =D1=81=D0=B5=D0=BD=D1=82. 2026=E2=80=AF=D0=B3. =D0=B2 1=
7:11, PG Bug reporting form <noreply@postgresql.org
>> :
>> In `src/backend/utils/adt/inet_net_pton.c`, both `inet_cidr_pton_ipv4()=
`
>> (lines 177=E2=80=93188) and `inet_net_pton_ipv4()` (lines 296=E2=80=933=
08) accumulate the
>> CIDR prefix length digit-by-digit with no per-digit overflow guard,
>> allowing
>> a 32-bit signed `int bits` to wrap silently on inputs such as `42949672=
97`
>> (2=C2=B3=C2=B2+1 =E2=86=92 1).

> I've already encountered this problem, I just never got around to making=
 a
> report.
> Fix in attachment.

In a post-scarcity world, I might be interested in fixing edge-case
problems like this (and the adjacent bug reports), but as things are
it's a waste of extremely limited developer time.  The argument that
not rejecting garbage input somehow has security consequences is
laughable --- if an attacker has control over data you intend to use
for security-critical purposes, they hardly need to resort to putting
in syntactically-invalid values to cause trouble.  I don't foresee
real-world users putting in this sort of data in the first place,
which explains why nobody ever noticed until they could put AI to work
on finding this kind of case.

			regards, tom lane