CVE-2024-40995

What it actually does

The flaw allows a local process to trigger an infinite loop inside tcf_idr_check_alloc when duplicate action indices are requested; the second request blocks indefinitely while holding rtnl_lock, starving other tasks that need the lock.

Why it matters to the business

Linux systems become unresponsive for networking configuration tasks, causing prolonged hangs in processes that manage network policies and potentially disrupting operations that rely on the kernel network stack.

How an attack unfolds

An attacker with local access crafts a sequence of netlink messages that request addition of multiple traffic-control actions using the same index; the kernel enters the loop, blocks on rtnl_lock, and leaves the system unable to perform further network configuration until the process is killed or the system is rebooted.

How to fix it

Upgrade the Linux kernel to a version containing commit 0d8a2d287c8a394c0d4653f0c6c7be4c688e5a74 or later; rebuild and reboot with the patched kernel. Where live patching is available, apply the vendor's live patch for this commit.

How to confirm the fix worked

Confirm the running kernel contains commit 0d8a2d287c8a394c0d4653f0c6c7be4c688e5a74 by inspecting /proc/version or the kernel build log; attempt to reproduce the original syzbot reproducer and verify that -EAGAIN is now returned instead of indefinite blocking.

Typical attack path

1. Obtain local unprivileged access on a Linux host
2. Open a netlink socket to the rtnetlink interface
3. Issue multiple RTM_NEWTFILTER or equivalent action-add requests that specify identical action indices
4. Observe the second request block forever while holding rtnl_lock
5. Trigger secondary effects such as hung worker threads or denial of network-policy changes

How to detect it

Review kernel logs for messages indicating tasks blocked on rtnl_lock for extended periods; look for repeated netlink messages requesting duplicate traffic-control action indices in system call traces or audit logs; examine hung-task watchdog reports in dmesg.

What your security team should do

• Prioritize patching all production Linux kernels to the fixed commit within normal change windows
• Monitor vendor advisories for backported fixes in supported distribution kernels
• Restrict unprivileged users from loading or configuring traffic-control actions via SELinux or AppArmor policies where feasible
• Include kernel version checks in vulnerability scanning and asset-inventory processes