CVE-2024-57982·Kernel vulnerability
In the Linux kernel, the following vulnerability has been resolved: xfrm: state: fix out-of-bounds read during lookup lookup and resize can run in parallel. The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array. rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask; While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) { This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again). Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent. The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side. xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.
- Severity
- high
- Software
- Kernel
- Fixed in
- 6.13.2
- Published
- 2025-02-27
Affected versions
From: 6.13
Until: 6.13.2
Fixed in: 6.13.2
How to fix this CVE
Update your Linux kernel to version 6.13.2 or later to patch a race condition in the xfrm (IPsec) subsystem that could lead to out-of-bounds memory access. This vulnerability affects the state lookup mechanism when hash table resizing occurs concurrently with packet processing. Systems using IPsec for VPN or encrypted communications should prioritize this update to prevent potential denial of service or information disclosure.
sudo dnf update kernel kernel-develDefensia detects this vulnerability
How to check if you are affected
- Check your kernel version with: uname -r (vulnerable if output matches 6.13.0 through 6.13.1)
- Verify xfrm subsystem is loaded: lsmod | grep xfrm (confirms IPsec/xfrm functionality is active)
- Search kernel logs for xfrm-related warnings: sudo grep -i 'xfrm\|ipsec' /var/log/kern.log or journalctl -k | grep -i xfrm
- After patching, reboot and confirm new kernel version: uname -r (should show 6.13.2 or higher)
FAQ
What is CVE-2024-57982?
This is a race condition vulnerability in the Linux kernel's xfrm (IPsec transform) subsystem where concurrent hash table resizing and state lookups can cause out-of-bounds memory reads. The vulnerability stems from insufficient synchronization between the hash mask update and pointer assignment during rehashing operations.
Is CVE-2024-57982 being actively exploited?
No, there is no evidence of active exploitation in the wild, and no public exploit code is available. However, the high CVSS score (7.1) and local attack vector make it a priority for timely patching.
What versions of Kernel are affected by CVE-2024-57982?
Linux kernel versions 6.13.0 through 6.13.1 are vulnerable. Version 6.13.2 and later include the fix.
How do I check if my server is vulnerable to CVE-2024-57982?
Run 'uname -r' and check if the output is 6.13.0 or 6.13.1. If it is, your system is vulnerable. Systems on kernel 6.13.2+ or other stable branches (6.12, 6.11, etc.) are not affected.
Does Defensia detect CVE-2024-57982?
Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If Kernel is installed on a monitored server, CVE-2024-57982 will appear in your dashboard with remediation steps.
Related Kernel CVEs
References
Track CVEs across your fleet automatically
Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2024-57982. Free for 1 server.
Get started free