BUG #19583: macaddr input accepts octet fields longer than 8 hex digits

The following bug has been logged on the website:

Bug reference: 19583
Logged by: Michael Malis
Email address: malis(at)pgrust(dot)com
PostgreSQL version: 19beta2
Operating system: MacOS
Description:

The macaddr input function accepts colon and dash-separated octet
fields containing more than 8 hexadecimal digits, and stores a value
different from the one entered, with no error.

Steps to reproduce (psql, no ~/.psqlrc, freshly-initialized cluster, default
configuration):

SELECT version();
version
-----------------------------------------------------------------------------------------------------------------------------
PostgreSQL 18.4 (Homebrew) on aarch64-apple-darwin24.6.0, compiled by Apple
clang version 17.0.0 (clang-1700.6.4.2), 64-bit
(1 row)

SELECT '100000001:0:0:0:0:0'::macaddr;
macaddr
-------------------
01:00:00:00:00:00
(1 row)

SELECT '-ffffff01:0:0:0:0:0'::macaddr;
macaddr
-------------------
ff:00:00:00:00:00
(1 row)

Identical results on the Debian-based postgres:18 Docker image.

Expected behavior: both inputs raise an error. The first field of
'100000001:0:0:0:0:0' has the value 0x100000001, which is not a
valid octet (documentation, section 8.9, describes macaddr input as
six groups of two hex digits, with the condensed forms as the only
variants); the second input contains a minus sign, which no macaddr
format includes. For comparison, an out-of-range two-digit-plus
field is rejected as expected:

SELECT '1ff:0:0:0:0:0'::macaddr;
ERROR: invalid octet value in "macaddr" value: "1ff:0:0:0:0:0"

Actual behavior: the overlong field is accepted and the stored octet
is the input value modulo 2^32 (then masked to a byte), i.e. a
different MAC address than the one entered, silently.

Two observations from the source (src/backend/utils/adt/mac.c,
macaddr_in): the first two sscanf formats use unbounded "%x"
conversions, while the five condensed formats in the same function
already use "%2x"; and C99 specifies that %x stores out-of-range
values as the conversion modulo the target width rather than
failing, so the subsequent a > 255 checks test the wrapped value.
The newer macaddr8 type rejects these inputs (its input function
does not use sscanf, per the discussion in
20170312193858(dot)GW9812(at)tamriel(dot)snowman(dot)net).

Happy to provide additional cases or a patch if useful.

I found this while doing differential testing for pgrust.