Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: BUG #19583: macaddr input accepts octet fields longer than 8 hex
 digits
To: pgsql-bugs@lists.postgresql.org
From: PG Bug reporting form <noreply@postgresql.org>
Cc: malis@pgrust.com
Reply-To: malis@pgrust.com, pgsql-bugs@lists.postgresql.org
Date: Wed, 29 Jul 2026 00:49:33 +0000
Message-ID: <19583-ca7c85d40164f18b@postgresql.org>
Auto-Submitted: auto-generated
Archived-At: 
 <https://www.postgresql.org/message-id/19583-ca7c85d40164f18b%40postgresql.org>
Precedence: bulk

The following bug has been logged on the website:

Bug reference:      19583
Logged by:          Michael Malis
Email address:      malis@pgrust.com
PostgreSQL version: 19beta2
Operating system:   MacOS
Description:       =20

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.GW9812@tamriel.snowman.net).

Happy to provide additional cases or a patch if useful.

I found this while doing differential testing for pgrust.