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 mlx5etcdel_flow() 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>