agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedFrom: PG Bug reporting form <noreply@postgresql.org>
To: pgsql-bugs@lists.postgresql.org
Cc: malis@pgrust.com
Subject: BUG #19583: macaddr input accepts octet fields longer than 8 hex digits
Date: Wed, 29 Jul 2026 00:49:33 +0000
Message-ID: <19583-ca7c85d40164f18b@postgresql.org> (raw)
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:
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.
view thread (6+ messages) latest in thread
Message-ID: <19583-ca7c85d40164f18b@postgresql.org>
Permalink: ../19583-ca7c85d40164f18b@postgresql.org/
Also on: postgresql.org/message-id/19583-ca7c85d40164f18b@postgresql.org
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: noreply@postgresql.org, pgsql-bugs@lists.postgresql.org, malis@pgrust.com
Subject: Re: BUG #19583: macaddr input accepts octet fields longer than 8 hex digits
In-Reply-To: <19583-ca7c85d40164f18b@postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox