CVE-2024-27397

What it actually does

Race condition in nftables set element timeout handling during control-plane transactions allows an element to expire while a transaction is unfinished, leading to use-after-free in set backends when .insert/.deactivate/sync gc paths rely on a stale transaction timestamp instead of current time.

Why it matters to the business

Local attackers can achieve kernel memory corruption on affected Linux systems, potentially resulting in privilege escalation, container escape, or full host compromise; low exploitability reduces immediate risk but kernel-level impact makes any successful exploitation severe for servers or multi-tenant environments.

How an attack unfolds

An attacker with local access crafts nftables set operations that race element insertion against timeout expiration during an ongoing transaction; by triggering the window where the element is freed yet still referenced from packet-path .lookup/.update or async gc, the attacker reclaims the memory to corrupt kernel structures and escalate privileges.

How to fix it

Upgrade Linux kernel to commit f8dfda798650241c1692058713ca4fef8e429061 or later stable releases containing the timestamp-based timeout fix; for affected tor packages on Debian 11-14 apply version 0.1.2.15-1 or newer; rebuild and reboot systems after kernel updates.

How to confirm the fix worked

Confirm kernel source contains the timestamp field addition in nftables per-netns area and updated .insert/.deactivate/sync gc paths; run regression tests exercising concurrent nftables transactions with timed set elements; verify no crash or slab corruption under load with element expiration.

Typical attack path

1. Obtain local unprivileged shell on target Linux host
2. Load or interact with nftables to create sets with timeout elements
3. Trigger concurrent transaction and packet-path operations to hit the expiration race
4. Trigger use-after-free and perform heap grooming to control freed object
5. Execute kernel code or overwrite credentials for privilege escalation

How to detect it

Review kernel audit logs and nftables trace events for unusual transaction patterns coinciding with set element expirations; inspect crash dumps or dmesg for use-after-free signatures in nf_tables paths; correlate with local user activity around nft command invocations.

What your security team should do

• Prioritize kernel updates on internet-facing or multi-tenant systems within standard patch windows given low EPSS and absence from KEV
• Restrict unprivileged nftables access via capabilities or seccomp where possible
• Monitor for local privilege-escalation attempts post-patch using existing EDR rules
• Track downstream dependents of the kernel package for broader ecosystem exposure