IPFire ships emergency Core Update 205 to patch actively exploited Linux kernel TCP flaw
Today's release fast-tracks a 9.8-scored use-after-free flaw in exchange for a mandatory reboot and a kernel that's otherwise unchanged.
IPFire's newest emergency update is live, and its lead maintainer isn't mincing words. As of today, the open-source firewall project shipped Core Update 205 for its 2.29 line, and Michael Tremer has essentially one message: install it now.
The reason is plain. The update carries a freshly built Linux kernel (6.18.60) that plugs CVE-2026-98432, a use-after-free bug in the kernel's TCP stack scoring a 9.8 out of 10. On top of that, it resolves a crash in the Broadcom network driver that was fixed upstream specifically for IPFire. That's the whole contents of the release. No surprises.
Keep in mind that this was deliberately narrow. IPFire could have bundled a dozen package bumps into a routine Core Update and waited its turn. Instead, Tremer pulled the patch forward so a critical flaw wouldn't linger until the next scheduled maintenance window.
Then comes the catch. Because the update replaces the kernel itself, you have to reboot. The fixes do nothing until you do, and neither the CVE patch nor the Broadcom stabilization takes effect on a machine that simply installed the packages and moved on. It's standard practice for kernel updates. It's also the part people skip.
The flaw behind the emergency
CVE-2026-98432 is severe enough to matter well beyond IPFire's usual audience. It went public on October 15 with a CVSS 3.1 score of 9.8, and a fix landed upstream on October 5. The bug has lurked in the kernel since Linux 4.4, which means it touches essentially every maintained release still running today. Anthropic's researcher, who found the issue, disclosed an exploit on October 27 that leaks kernel memory, defeats KASLR, then runs commands as root. That requires nothing more than network access to an IPv4 TCP listening service. No credentials. No user interaction. Just a connection request carrying IPv4 options, followed by a retransmission.
The story gets stranger from there. Go versions 1.24 and later started enabling MPTCP by default, which the Go Security Team flagged on October 29 as something that widens the attack surface. An MPTCP listener helps attackers aiming for full root, though researchers note the underlying bug isn't specific to MPTCP.
The fix is as minimal as these things get. Kernel developer Eric Dumazet swapped a plain kfree() for an RCU-aware kfree_rcu() in two kernel destructors. That approach just waits for an idle grace period before freeing memory, so readers on other CPUs finish first. IPFire ships 6.18.60, comfortably past the patched 6.18.56.
If you can't reboot right now, there are interim stopgaps. Disable MPTCP or TCP request migration. Block incoming IPv4 TCP packets that carry IP options. Both reduce exposure, though blocking IP options can disrupt the very applications that need them. Amazon said it had no evidence of wild exploitation as of late October, but Ubuntu and RHEL reportedly still lacked fixed kernels for some releases as of October 30. IPFire sidesteps that problem by shipping the patched kernel immediately.
It's a bit of a gamble for such a tight patch, honestly. A firewall update that is only a kernel and nothing else is a strange thing to ship. However, the kernel is the whole attack surface here, so a lean release is arguably exactly right. The small form factor and focused build do help, though the lack of bundled extras might make some admins uneasy at first.
The release you didn't sign up for
The Core Update 205 you got is not the one they originally planned. Everything collected for CU205 got relocated to Core Update 206, which simultaneously moved into the testing channel. It's standard IPFire emergency playbook: isolate the critical fix, let the rest keep rolling through testing. CU206 is a meatier release, so it's worth a glance since CU205 is basically just the tip.
The biggest change is a translation overhaul. IPFire ditched its home-grown localization system for GNU gettext and rebuilt how the web interface handles translations. Every interface message was reviewed, whole sentences replaced ones stitched together from code fragments, and all the work moved to a Weblate instance so contributors need only a browser. The installer also added Hungarian, Romanian, and Swedish while shrinking its image with zstd compression.
Security-wise, CU206 kills two command-injection bugs in the WIO ("Who Is Online") add-on, and it stops the web UI from launching a shell entirely rather than patching individual holes one at a time. Compromised root certificates got yanked from the store, the IPS now skips encrypted ESP traffic it can't inspect anyway, and pulling the ThreatFox ruleset now requires an Auth-Key after abuse.ch started demanding authentication in late October.
There's also a broad package refresh: OpenSSL 3.6.5, OpenSSH 10.5p1, glibc 2.44, Suricata 8.0.8, strongSwan 6.1.0, systemd 261.3, BIND 9.20.29, GCC 16.1.0, and dozens more. The build switched to dracut v112 from dracut-ng because glibc 2.44 broke module detection, which would otherwise have left systems without storage-controller drivers.
Then there's LoongArch. CU206 marks IPFire's entry into the architecture, the fourth 64-bit option after x86-64, ARM, and RISC-V. Tremer wrote that the port was made possible by build hardware gifted by China's Loongson Hobbyists' Community, a machine built around a Loongson 3A6000-HV processor. It's the fastest box in IPFire's build farm, finishing a full build in just over two hours versus roughly seven hours on real RISC-V hardware. He frames LoongArch support as both a stress test proving the build is clean and a stand against vendor lock-in for researchers and governments chasing alternatives to a dominant instruction set.
Why does this matter? Speed, mostly. IPFire shipped a patched kernel in response to a 9.8, actively exploitable flaw within days of disclosure, faster than some bigger commercial distros reported at the time. That agility comes straight from a focused, single-purpose build and a tight release process.
The kernel is the shared attack surface here, so a lean emergency update is the right call. The same openness that lets the community verify IPFire's security also let Anthropic, Akamai, Kudelski, Red Hat, and AWS analyze the underlying bug fast. It's a virtuous cycle worth protecting.
Independence has trade-offs, of course. IPFire is run by a small team funded by sponsors and a single company, Lightning Wire Labs. Emergency releases and ambitious ports like LoongArch only happen because of that ongoing support, a point the project never stops making.
To get the update, apply CU205 through the web UI or via pakfire, then reboot your system so the kernel changes actually take effect. Images are available for x86_64 and aarch64, both in ISO (671 MB) and flash formats, from IPFire's downloads page. Those who want to preview the broader CU206 feature set can switch to the testing channel and report findings through the project's Bugzilla.
