| From: | Iliia Khaprov <i(dot)khaprov(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | inet/cidr: IPv4 prefix length overflows int and passes the range check |
| Date: | 2026-10-28 21:31:53 |
| Message-ID: | CAFO+O_rLO3Mz1U=CU5gAZBX4w5zr7nfcFPWsv-AoVc+k6kCumg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
SELECT '192.168.0.0/4294967320'::inet; -- 2^32 + 24, accepted as
192.168.0.0/24
SELECT '10.0.0.0/4294967304'::cidr; -- 2^32 + 8, accepted as 10.0.0.0/8
Both should fail. These do:
SELECT '192.168.0.0/33'::inet; -- ERROR, 33 > 32
SELECT '192.168.0.0/2494967320'::inet; -- ERROR, wraps negative
SELECT '::1/4294967320'::inet; -- ERROR, IPv6 checks
inside the loop
There is a check, but it runs after the digit loop and tests the wrapped
value, i.e. the prefix length mod 2^32. Any input whose residue lands in
0..32 is accepted:
SELECT '192.168.0.0/4294967296'::inet; -- 2^32 + 0, accepted as
192.168.0.0/0
SELECT '192.168.0.0/4294967314'::inet; -- 2^32 + 18, accepted as
192.168.0.0/18
The attached patch moves the check into the digit loop.
Regards,
Iliia
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Reject-IPv4-prefix-lengths-that-overflow-int.patch | application/octet-stream | 3.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema-Nio | 2026-10-28 21:33:16 | Re: Python/pytest test framework take two |
| Previous Message | Sami Imseih | 2026-10-28 21:21:49 | Re: Report buffer access strategies in EXPLAIN |