Omarchy’s kernel fix for the critical TCP bug CVE-2026-98432 lands on the edge channel
Patched linux-omarchy builds are live on edge after a community report flagged the 9.8-rated IPv4 TCP use-after-free. According to the publish log, the kernel hasn’t been promoted to rc or stable yet.
Image: omacom/omarchy-pkgs issue #1780 (GitHub)
Omarchy’s kernel packages have caught up with CVE-2026-98432, the critical Linux TCP bug that even prompted a warning from the Go Security Team. Kernel builds that include the upstream fix are now published on Omarchy’s edge package channel, following a report filed by ChrisDrit in the omarchy-pkgs repository on October 29, 2026.
The bug itself is a use-after-free in the IPv4 TCP handshake. According to the CVE record published by the Linux kernel CNA on October 15, 2026, a child socket created from a SYN request takes over that request’s IP options without copying them, so a retransmitted SYN processed at the same time on another CPU can read memory that has already been freed. The kernel CNA rates it 9.8 (Critical) on CVSS 3.1, with a network attack vector and no privileges or user interaction required. The fix, titled “ipv4: free inet_opt and ireq_opt after an RCU grace period”, switches two frees to kfree_rcu(), and the record lists it as fixed in 7.2.10 and 7.3, as well as 6.18.56, 6.12.113, 6.6.159, 6.1.190, 5.15.223 and 5.10.272. NVD still lists the entry as “Received”.
The reason it got so much attention: in a post forwarded to oss-security, the Go Security Team wrote that “in an exploit described by Anthropic, a server using Multipath TCP (MPTCP) listeners is shown to be vulnerable to Remote Code Execution (RCE)”, while stressing that “the underlying bug is not specific to MPTCP”. Since Go 1.24, Go programs enable MPTCP by default on Linux listen sockets. The team explains how to switch that off with GODEBUG=multipathtcp=0, but calls disabling MPTCP program by program “a fragile mitigation” and says “the best fix for this vulnerability is to upgrade to a patched kernel version”.
On the Omarchy side, ChrisDrit reported that linux-omarchy 7.2.8-9, which he described as the current repo build, was affected, as seen on his Framework 13 running 7.2.8-9-omarchy. Krzysztof Wilczyński replied the same day that the fix would ship with 7.2.13. The update that actually landed went further: #1878 moved the EEVDF, BORE and MuQSS kernels to 7.2.14-1 and was merged on October 30, and #1906 fixed the name of the linux-omarchy package on October 31. Emir Beganović then closed the issue, citing both pull requests. ChrisDrit’s own backport of the fix onto 7.2.8, #1785, is still open.
A follow-up, #1968, bumped the kernels again to 7.2.15-1 and was merged on November 1. Both 7.2.14 and 7.2.15 are well past 7.2.10, the first 7.2 release with the fix. According to the pkgs.omarchy.org publish log, the package named linux-omarchy reached edge as 7.2.14-1 on October 31, and the November 1 publish shipped 7.2.15-1 builds for the BORE, EEVDF and MuQSS kernels.
The catch is the channel. The release bot’s comments on #1878 and #1968 list only edge/x86_64, and in the publish log from October 29 to the morning of November 2, the only promotions to rc moved Mac and Aurora packages, while the 4.5.0rc3 cut on November 2 covered omarchy and omarchy-settings. No promotion of linux-omarchy to rc or stable shows up in that window.
That matters because of how packages travel. The omarchy-pkgs README describes the channels as edge → rc → stable: a merge publishes to edge within minutes, and outside the “fast ring” (vendor binaries, static tools, themes and the like), rc and stable only change when a maintainer promotes them or cuts a release. The kernel recipes updated by these pull requests build for x86_64 only.
One more thing to keep an eye on: kernel.org already flags 7.2.15 as end of life, with 7.3.1 as the latest stable release. If you run a server-style workload on your Omarchy machine, the advice from the Go team applies here too: the real fix is a patched kernel, and for Omarchy that build currently lives on edge.
