A new Linux kernel vulnerability, CVE-2026-98276, is a race condition in the socket code that can lead to a use-after-free of a UDP socket. The Linux kernel CVE team scores it CVSS 7.8 (High): it needs a local account that can run code, but no special privileges and no user interaction. AlmaLinux 8, 9, and 10 are affected. Patched kernels are available in the testing repository today, and we would like your help verifying them before we release them to production.
More information about the vulnerability:
- CVE announcement from the Linux kernel CVE team: https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-98276.mbox
- Upstream fix:
9ed55f3dbef4(“net: lock the socket in sock_gettstamp()”)
Summary
Every socket in the kernel carries a word of flag bits. Changing one of those bits is a read-modify-write of the whole word, so the kernel’s rule is that it must only be done while holding the socket lock. Otherwise two CPUs can read the same old value, each set its own bit, and whichever writes last silently undoes the other.
One place broke that rule. The SIOCGSTAMP family of ioctls, which an application uses to ask when a packet arrived, turns on packet timestamping for the socket the first time it is called, and it did so without taking the socket lock.
The reporters found a way to make that matter. When a UDP socket is bound to a port, the kernel marks it with a flag that says “free this socket only after a grace period”, because the UDP receive path looks sockets up without taking any lock and relies on that delay. If a timestamp ioctl on the same socket races with the bind(), the ioctl’s unlocked write can wipe out that flag. The socket is then freed immediately when it is closed, while the receive path may still be holding a pointer to it: a use-after-free.
The bug has been present since the start of the kernel’s git history (2.6.12). The fix, written by Eric Dumazet, takes the socket lock in the ioctl when the timestamping flag actually has to be set, and leaves the common case lockless.
Impact
This is a local vulnerability. To trigger it, an attacker needs to run code on the system as an ordinary user, create a UDP socket, and race the bind() and ioctl calls against each other. It cannot be triggered by network traffic alone.
Any AlmaLinux system where untrusted users can run code should be treated as exposed: multi-tenant hosts, shared build and CI machines, and anything that runs user-supplied containers. The reporters demonstrated the use-after-free with a kernel memory checker; we are not aware of a public exploit at the time of writing.
Red Hat rates the flaw Moderate with a CVSS score of 7.0, judging the race hard to win reliably. The kernel CVE team rates it 7.8 (High). We think a local-to-root class of bug in the generic socket code deserves prompt attention either way.
Patching ahead of our upstream
Security is a top priority at AlmaLinux. At the time of writing, no fixed RHEL kernel is available, and Red Hat lists the RHEL 8, 9, and 10 kernels as affected. Our core team has backported the upstream fix to every supported AlmaLinux branch from the Linux stable kernels (5.15 and 6.12). The decision to ship ahead of a CentOS Stream / RHEL update was made by our technical steering committee, ALESCo.
The AlmaLinux 8 kernel (4.18) predates a 2019 rework of how these ioctls are handled, so the fix could not be applied as is. We adapted it to the equivalent helpers in that kernel and adjusted the three protocol handlers (qrtr, ax25, and netrom) that called them with the socket lock already held, following what the upstream code has done since that rework. Testing on AlmaLinux 8 is therefore especially welcome.
These kernels are available in the testing repository today. After the community has helped verify them, we will release them to the production repositories. This post will be updated when that happens.
Patched kernel versions
- AlmaLinux 8:
kernel-4.18.0-553.184.2.el8_10 - AlmaLinux 9:
kernel-5.14.0-687.66.2.el9_8 - AlmaLinux 10:
kernel-6.12.0-211.74.2.el10_2
Install the version listed for your release, or higher.
Help us test
sudo dnf install -y almalinux-release-testing
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot
Confirm with uname -r or rpm -q kernel against the versions above.
If you do not want the testing repo enabled afterwards (and on a production box you almost certainly do not), disable it once you have rebooted:
sudo dnf config-manager --disable almalinux-testing
If you run into anything, please let us know in AlmaLinux chat or on bugs.almalinux.org.
Is there a workaround?
Not a practical one. The trigger is an ordinary ioctl on an ordinary UDP socket, both of which any process may use, so there is no module to block or firewall rule to add. The only thing that reduces exposure is limiting who can run code on the machine. Install the patched kernel and reboot as soon as you can.
Thanks
Thanks to Jungwoo Lee and Wongi Lee for reporting this vulnerability, to Eric Dumazet for writing the upstream fix, to Simon Horman for reviewing it, and to the Linux kernel CVE team.
Thanks to the AlmaLinux core team for turning around patched builds for every supported release, and to ALESCo for moving quickly to approve shipping ahead of upstream. And thank you in advance to everyone in the community who helps us test these kernels.
Stay informed
Remaining aware of these vulnerabilities and acting quickly can keep your systems and data safe. Follow the AlmaLinux Blog, join the Mattermost Community Chat, and subscribe to the Announce and Security mailing lists to stay informed. We will update this post when the patched kernels move from testing to production.
