CVE-2024-50036

What it actually does

Use-after-free in Linux kernel dst cache management: dst_entries_add() called from dst_destroy() after ip6_route_net_exit() may have already freed per-CPU data via dst_entries_destroy() during netns teardown; also enables UAF via dst_release_immediate() in CONFIG_XFRM scenarios.

Why it matters to the business

Kernel crashes, memory corruption, or local privilege escalation on Linux hosts; high operational risk for network-heavy workloads and containers, with urgency increased by public exploitation campaigns from espionage and financially motivated actors.

How an attack unfolds

Attacker with local access triggers network namespace teardown (or IPsec child dst release) while dst entries remain; the delayed decrement in dst_release() races with dst_entries_destroy(), causing dst_entries_add() to touch freed per-CPU structures, leading to UAF write or read.

How to fix it

Upgrade torvalds/linux to commit 1860e379875dfe7271c649058aeddffe5afd9d0d or later; apply vendor kernel updates containing the fix; avoid CONFIG_XFRM if immediate patching is impossible.

How to confirm the fix worked

Verify kernel git commit or package version contains 1860e379875dfe7271c649058aeddffe5afd9d0d; run reproducer that exercises dst release during netns exit and confirm no UAF in kmemleak or KASAN; check /proc/kallsyms for updated dst_release symbol.

Typical attack path

1. Obtain local code execution on target Linux system
2. Create or manipulate network namespaces or IPsec policies to hold dst entries
3. Trigger netns dismantle or dst release path concurrently with RCU grace period
4. Trigger dst_destroy() after per-CPU data freed to hit UAF
5. Leverage corruption for privilege escalation or denial of service

How to detect it

Search kernel logs for oops or warnings mentioning dst_entries_add, dst_release, dst_destroy, or ip6_route_net_exit; inspect for UAF signatures in KASAN reports during namespace teardown; correlate with process activity creating network namespaces or IPsec policies.

• dst_entries_add
• dst_release_immediate
• ip6_route_net_exit
• dst_entries_destroy

What your security team should do

• Patch to fixed commit 1860e379875dfe7271c649058aeddffe5afd9d0d within CISA timelines if applicable
• Monitor for kernel oops/panics referencing dst_entries or dst_release
• Restrict unprivileged namespace creation where feasible
• Prioritize systems with high downstream dependents or exposure to listed threat actors