[Pkg-freeradius-maintainers] Bug#1147278: freeradius built without PCRE2 support, silently falls back to POSIX regex (\w etc. broken)
manager
anders.westerbergh at molndal.se
Thu Sep 10 10:31:50 BST 2026
Package: freeradius
Version: 3.2.7+dfsg-1+deb13u2
Severity: important
Dear Maintainer,
The freeradius binary package for trixie (and confirmed still present
in current unstable/testing, 3.2.10+dfsg-1) is built without PCRE2
support. debian/control for these source versions lists no
libpcre2-dev (nor the deprecated libpcre3-dev) in Build-Depends.
FreeRADIUS's own configure step auto-detects available regex libraries
and silently disables PCRE support if the dev headers aren't present
at build time (documented behavior, not a build failure). As a result
this package falls back to the system's POSIX extended regex
implementation instead of PCRE2.
This is a silent regression with no warning or error at build time,
package install time, or daemon startup. It's only visible via:
freeradius -Xxv | grep -A6 -i regex
Debug: regex-pcre : no
Debug: regex-posix : yes
Debug: regex-posix-extended : yes
Compare against the bookworm build (3.2.1+dfsg-4+deb12u1), which
correctly links PCRE:
Debug: regex-pcre : yes
Debug: regex-posix : no
Debug: regex-posix-extended : no
Impact: POSIX ERE does not support Perl-style character classes
(\w, \d, \W, \s, etc.) used ubiquitously in real-world FreeRADIUS
unlang policy files. Any site-configured unlang regex relying on
these classes silently fails to match, with no indication why. In
our case this broke identity/realm-stripping logic used to route
EAP/MAB/hostname authentication to the correct backend, causing
legitimate devices to fall through to a guest/fallback VLAN.
Steps to reproduce:
1. Install freeradius on trixie (apt install freeradius).
2. Add a policy rule using a \w-class regex, e.g.:
if ("%{request:User-Name}" =~ /^host\/([\w\-]+)\.(.+)$/) { ... }
3. Run freeradius -X and send an Access-Request with a matching
User-Name.
4. Observe the condition evaluates FALSE even though the string
visibly matches the pattern.
5. Confirm with freeradius -Xxv | grep -A6 -i regex as above.
Suggested fix: add libpcre2-dev to Build-Depends in debian/control.
Confirmed the same gap persists in 3.2.10+dfsg-1 (current
unstable/testing) via the .dsc Build-Depends field directly, so this
is not a stable-only regression needing only a deb13u backport — it
needs fixing at the source-package level so it doesn't ride forward
into the next stable release as well.
Workaround in use: pinning to the bookworm build
(3.2.1+dfsg-4+deb12u1) via apt preferences, which was correctly
linked against PCRE.
-- System Information:
Debian Release: 13.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.107+deb13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages freeradius depends on:
ii freeradius-common 3.2.7+dfsg-1+deb13u2
ii freeradius-config 3.2.7+dfsg-1+deb13u2
ii libc6 2.41-12+deb13u3
ii libcrypt1 1:4.4.38-1
ii libct4 1.3.17+ds-2+deb13u1
ii libfreeradius3 3.2.7+dfsg-1+deb13u2
ii libgdbm6t64 1.24-2
ii libjson-c5 0.18+ds-1
ii libpam0g 1.7.0-5
ii libperl5.40 5.40.1-6
ii libreadline8t64 8.2-6
ii libsqlite3-0 3.46.1-7+deb13u1
ii libssl3t64 3.5.7-1~deb13u2
ii libsystemd0 257.13-1~deb13u1
ii libtalloc2 2:2.4.3+samba4.22.10+dfsg-0+deb13u2
ii libwbclient0 2:4.22.10+dfsg-0+deb13u2
ii perl 5.40.1-6
Versions of packages freeradius recommends:
ii freeradius-utils 3.2.7+dfsg-1+deb13u2
Versions of packages freeradius suggests:
ii freeradius-krb5 3.2.7+dfsg-1+deb13u2
ii freeradius-ldap 3.2.7+dfsg-1+deb13u2
ii freeradius-mysql 3.2.7+dfsg-1+deb13u2
ii freeradius-postgresql 3.2.7+dfsg-1+deb13u2
pn freeradius-python3 <none>
pn snmp <none>
-- no debconf information
More information about the Pkg-freeradius-maintainers
mailing list