CVE-2024-57982

What it actually does

Out-of-bounds read in xfrm state lookup when hash and resize run concurrently; hmask observed larger than the hlist array due to non-atomic update ordering between state_bydst pointer and state_hmask.

Why it matters to the business

Linux systems performing IPsec or xfrm operations may experience kernel memory disclosure or crashes, increasing risk of information leaks or denial of service on servers and network appliances.

How an attack unfolds

Attacker induces parallel rehash and state lookup operations; the lookup helper reads an oversized hmask and traverses beyond the allocated hash table, allowing controlled out-of-bounds kernel read.

How to fix it

Apply kernel patches that prefetch state_hmask and pointers before RCU lookup and add lockdep assertions; replace spinlock usage with RCU in xfrm_state_lookup_byaddr where applicable. Upgrade affected packages to the versions listed in fixed_versions when available.

How to confirm the fix worked

Confirm presence of prefetch logic and lockdep assertions in xfrm code; verify state_hmask and state_bydst updates are ordered correctly under RCU; run kernel selftests for xfrm hash resizing under concurrency.

Typical attack path

1. Trigger concurrent xfrm state insertion/resize and lookup paths
2. Force observation of stale oversized hmask value
3. Walk hlist using invalid index to read kernel memory beyond allocation
4. Repeat to leak sensitive data or induce crash

How to detect it

Inspect kernel logs for xfrm hash-related warnings or oops during high xfrm churn; correlate with processes performing frequent IPsec state changes; look for unexpected RCU stalls or memory access violations in xfrm modules.

What your security team should do

• Prioritize patching Linux kernels on systems using IPsec/xfrm
• Monitor EPSS and threat actor activity for escalation
• Test patches in staging before broad deployment due to concurrency-sensitive networking code
• Audit custom xfrm usage for additional exposure