CVE-2026-80739: net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock
In case mlx5eaddfdbflow() fails in lower levels, the flow is deleted via mlx5etcdelflow(), and mlx5etcdelflow() is acquiring ESW devcom lock without condition. In addition, in case of peerflow, mlx5eaddfdbflow() is called while holding ESW devcom comp lock. This results in an AA deadlock.
To fix this, introduce a new PEER flag that is set on flows created as peer flows (the duplicate flows on peer devices), and check it in mlx5etcdelflow() before acquiring ESW devcom lock.
Lockdep splat: ============================================ WARNING: possible recursive locking detected ============================================ Possible unsafe locking scenario: CPU0 ---- lock(&comp->lockkey#2); lock(&comp->lockkey#2); DEADLOCK Call Trace: <TASK> dumpstacklvl+0x69/0xa0 printdeadlockbug.cold+0xbd/0xca lockacquire+0x1671/0x2ec0 lockacquire+0x10e/0x2e0 downread+0x95/0x430 mlx5devcomforeachpeerbegin+0x4e/0xe0 [mlx5core] mlx5etcdelflow+0x11d/0xa70 [mlx5core] mlx5eflowput+0x99/0x100 [mlx5core] mlx5eaddfdbflow+0x409/0xf00 [mlx5core] mlx5econfigureflower+0x2a86/0x4100 [mlx5core] mlx5erepsetuptcclsflower+0x12f/0x1b0 [mlx5core] mlx5erepsetuptccb+0x153/0x750 [mlx5core] tcsetupcbadd+0x1dc/0x470 flchange+0x2f4d/0x626d [clsflower] tcnewtfilter+0x79b/0x2310 rtnetlinkrcvmsg+0x778/0xad0 dosyscall64+0x70/0x960 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK>
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
The issue occurs when creation of an FDB flow fails at a lower level and the failed flow is subsequently deleted. It specifically involves peer flows, which are duplicate flows on peer devices, because flow creation can already hold the ESW devcom component lock when deletion attempts to acquire it again.
What is the practical impact if the issue is triggered?
The affected locking sequence can cause recursive acquisition of the ESW devcom component lock, resulting in an ABBA deadlock. The provided lockdep trace identifies mlx5e_tc_del_flow() as attempting the conflicting lock acquisition.
How does the available fix prevent the deadlock?
The fix adds a PEER flag to flows created as peer flows. mlx5e_tc_del_flow() checks this flag before acquiring the ESW devcom lock, avoiding re-acquisition of the lock for peer-flow cleanup.