Bug 2427017 - FreeRADIUS fails to start if SELinux is in enforcing mode
Summary: FreeRADIUS fails to start if SELinux is in enforcing mode
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: freeradius
Version: 43
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Antonio Torres
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-01-04 15:52 UTC by Luca Cavana
Modified: 2026-01-16 17:41 UTC (History)
3 users (show)

Fixed In Version: freeradius-3.2.8-2.fc43
Clone Of:
Environment:
Last Closed: 2026-01-16 17:41:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FREEIPA-12478 0 None None None 2026-01-04 15:53:41 UTC

Description Luca Cavana 2026-01-04 15:52:20 UTC
Upon upgrade from Fedora 42 to Fedora 43, the radiusd process crashes upon startup when launched by systemd.
The system has SELinux enabled in enforcing mode (and always had).

By modifying the startup string I was able to understand that the process goes out of memory: "ExecStartPre=/usr/sbin/radiusd -C -lstdout -xxx"

Sun Jan  4 16:42:17 2026 : Error: /etc/raddb/policy.d/filter[31]: Invalid regular expression:
Sun Jan  4 16:42:17 2026 : Error: /etc/raddb/policy.d/filter[31]:
Sun Jan  4 16:42:17 2026 : Error: /etc/raddb/policy.d/filter[31]: ^ Pattern JIT failed: no more memory

If you launch radiusd -X from root or from it's radiusd user it works.
If you temporarily put SELinux in permissive mode the service unit is able to start.

I can't find any SELinux policy violation (grep AVC /var/log/messages) that I'm aware of.

Reproducible: Always

Steps to Reproduce:
1. Upgrade a Fedora 42 system to 43, with FreeRADIUS installed
2. Reboot
Actual Results:
FreeRADIUS fails to start

Expected Results:
FreeRADIUS starts

Comment 1 Luca Cavana 2026-01-04 16:56:32 UTC
OK,

there are a couple of solutions to this problem.
It stems from the fact that FreeRADIUS 3.2.8, that is packages with Fedora 43 uses PCRE2, whereas previous versions used PCRE1 (source here: https://lists.freeradius.org/pipermail/freeradius-users/2025-August/105866.html)

There are two solutions:

1- Ship the new 3.2.8-2 which use PCRE1 again.
2- Enable the SELinux boolean radius_use_jit in the package you are shipping now (that's what I did on my system which broke).
It's all discussed here: https://lists.freeradius.org/pipermail/freeradius-users/2025-August/105855.html

The fact that nothing shows up in the log is because there is a don't audit rule in the Fedora SELinux policy package for this but my ignorance on that matter had me spend more time than necessary troubleshooting.

Anyway, F43 ships a package which is known to be broken and must be updated / modified.

Ciao,
Luca

Comment 2 Fedora Update System 2026-01-07 10:18:32 UTC
FEDORA-2026-35df324d28 (freeradius-3.2.8-2.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-35df324d28

Comment 3 Fedora Update System 2026-01-08 01:12:15 UTC
FEDORA-2026-35df324d28 has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-35df324d28`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-35df324d28

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 4 Luca Cavana 2026-01-08 07:13:02 UTC
It works, thank you for both upgrading the package and setting the boolean.

It should take care of this in the long run when they'll start using PCRE2 again.

Comment 5 Fedora Update System 2026-01-16 17:41:45 UTC
FEDORA-2026-35df324d28 (freeradius-3.2.8-2.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.