CVE-2026-80739

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock

In case mlx5e add fdb flow() fails in lower levels, the flow is deleted via mlx5e tc del flow(), and mlx5e tc del flow() is acquiring ESW devcom lock without condition. In addition, in case of peer flow, mlx5e add fdb flow() 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 mlx5e tc del flow() before acquiring ESW devcom lock.

Possible unsafe locking scenario: CPU0 ---- lock(&comp->lock key#2); lock(&comp->lock key#2); *** DEADLOCK *** Call Trace: dump stack lvl+0x69/0xa0 print deadlock bug.cold+0xbd/0xca lock acquire+0x1671/0x2ec0 lock acquire+0x10e/0x2e0 down read+0x95/0x430 mlx5 devcom for each peer begin+0x4e/0xe0 [mlx5 core] mlx5e tc del flow+0x11d/0xa70 [mlx5 core] mlx5e flow put+0x99/0x100 [mlx5 core] mlx5e add fdb flow+0x409/0xf00 [mlx5 core] mlx5e configure flower+0x2a86/0x4100 [mlx5 core] mlx5e rep setup tc cls flower+0x12f/0x1b0 [mlx5 core] mlx5e rep setup tc cb+0x153/0x750 [mlx5 core] tc setup cb add+0x1dc/0x470 fl change+0x2f4d/0x626d [cls flower] tc new tfilter+0x79b/0x2310 rtnetlink rcv msg+0x778/0xad0 do syscall 64+0x70/0x960 entry SYSCALL 64 after hwframe+0x4b/0x53