CVE-2024-27019

What it actually does

Concurrent nft_unregister_obj() and __nft_obj_type_get() lack synchronization when iterating the nf_tables_objects list, creating a data race on list entries that can expose kernel memory contents.

Why it matters to the business

Organizations running affected Linux kernels face a low-probability local confidentiality exposure on systems performing frequent netfilter object registration changes; the issue is old, unexploited in the wild, and carries minimal operational disruption risk.

How an attack unfolds

An attacker with local access races an object unregistration against a type lookup inside the netfilter subsystem; success leaks kernel data but requires precise timing and is not known to be used by any threat actors.

How to fix it

Upgrade to a kernel containing commit 811edaae81eb044891594f00062a828f51b22cb1 (eprintsug/ulcc-core) or cade34279c2249eafe528564bd2e203e4ff15f88 (stable/linux.git) or later; rebuild and reboot.

How to confirm the fix worked

Confirm the running kernel includes one of the listed RCU-protected list iteration commits; inspect /proc/version or kernel source for the fix and test concurrent object registration/unregistration workloads.

Typical attack path

1. Obtain local user access on a vulnerable Linux system
2. Trigger concurrent nft_unregister_obj and nft_obj_type_get operations via crafted netfilter configuration
3. Win the data race to read inconsistent list pointers
4. Extract kernel memory contents from the resulting read

How to detect it

Review kernel logs and audit trails for unusual netfilter object registration patterns around the time of any suspected local activity; no public indicators of prior exploitation exist.

What your security team should do

• Prioritize patching production systems that expose netfilter object management to untrusted local users
• Monitor EPSS and KEV status for any future rise in exploit activity
• Apply the listed commit-based fixes rather than relying on workarounds