CVE-2024-26740

What it actually does

Causes a potential deadlock in the Linux kernel networking stack when act_mirred redirects packets from egress to ingress paths, allowing the same socket lock to be acquired recursively instead of queuing via backlog.

Why it matters to the business

Leads to system instability, hangs, or crashes in network environments using traffic control redirection, resulting in downtime and requiring kernel updates across affected deployments.

How an attack unfolds

An attacker sends network traffic that triggers act_mirred ingress redirection on egress-to-ingress reversal, reaching the originating socket while its lock is still held and causing a deadlock without using the Rx backlog for all such cases.

How to fix it

Update the Linux kernel to the version containing commit 7c787888d164689da8b1b115f3ef562c1e843af4 which applies backlog queuing for all egress-to-ingress mirred reversals.

How to confirm the fix worked

Confirm the kernel tree contains commit 7c787888d164689da8b1b115f3ef562c1e843af4, rebuild, and retest mirred configurations under load to verify absence of tcp_v4_rcv deadlock warnings.

Typical attack path

1. Identify Linux systems with act_mirred configured for ingress redirection
2. Generate traffic causing egress-to-ingress flow reversal on the same socket
3. Trigger repeated inline Rx processing to acquire held socket locks
4. Induce deadlock leading to system hang or lockdep-reported failure

How to detect it

Review kernel logs and lockdep reports for tcp_v4_rcv deadlock entries involving act_mirred and socket locks; check system stability under traffic redirection workloads.

What your security team should do

• Apply the fixed kernel commit or equivalent stable release on all affected systems
• Audit tc mirred rules for ingress redirection usage
• Enable lockdep and monitor kernel logs for related deadlock reports during testing