CVE-2024-27010

What it actually does

Recursive locking deadlock on struct Qdisc q.lock when mirred egress redirect or mirror action sends a packet back to the same device or creates a device loop under a classful egress qdisc; the fix adds a per-CPU owner field and drops the packet on re-entry by the same CPU.

Why it matters to the business

Systems performing advanced Linux traffic control with mirred actions risk kernel soft lockups or hangs under specific packet patterns, leading to network service disruption; low urgency given absence from KEV and stable low EPSS, though widespread Linux kernel use increases potential blast radius.

How an attack unfolds

An attacker with local privileges to install tc qdisc rules configures a mirred redirect that creates a self-loop or inter-device cycle, then injects matching traffic; the softirq path re-enters the same qdisc lock, triggering the deadlock and system instability.

How to fix it

Upgrade the Linux kernel to a version containing commit e6b90468da4dae2281a6e381107f411efb48b0ef or later stable releases that include the owner-field check; rebuild and reboot with the fixed kernel; test mirred configurations in a lab before production deployment.

How to confirm the fix worked

Verify the running kernel contains commit e6b90468da4dae2281a6e381107f411efb48b0ef; attempt the provided tc recreation commands and confirm packets are dropped instead of deadlocking; monitor dmesg for absence of recursive locking warnings under load.

Typical attack path

1. Obtain privileges to modify qdisc configuration on the target host
2. Add root htb qdisc and a matchall filter with mirred egress redirect to the same or cyclic device
3. Send crafted or flood traffic that matches the filter to trigger recursion
4. Observe kernel deadlock warning and subsequent soft lockup

How to detect it

Search kernel logs and dmesg for 'WARNING: possible recursive locking detected' together with '&sch->q.lock' and __dev_queue_xmit; inspect audit logs for tc invocations that add mirred actions; correlate with soft lockup or hung task reports.

• WARNING: possible recursive locking detected
• &sch->q.lock
• __dev_queue_xmit
• tc qdisc add.*mirred egress redirect
• Possible unsafe locking scenario

What your security team should do

• Apply the fixed kernel commit e6b90468da4dae2281a6e381107f411efb48b0ef on all systems that use tc mirred actions
• Audit existing qdisc configurations for self or cyclic redirects and remove them
• Add kernel lockdep and soft-lockup detectors to CI and production monitoring
• Restrict unprivileged users from tc qdisc modifications via capabilities or SELinux