net/mlx5e: Fix peer flow lists handling

Vulnerability

In the Linux kernel, the net/mlx5e driver contains a vulnerability in mlx5e_tc_del_fdb_peer_flow() that leads to a list corruption (use-after-free) when removing peer flows. The code refactored in a cited change (commit 74cec142f89b) only clears the DUP flag when the list of peer flows is empty. However, if a concurrent user (e.g., the neighbor update workqueue task updating a peer flow's parent encap entry) holds a reference to a peer flow, the flow is not removed from the peer list and the DUP flag remains set. This causes mlx5e_tc_del_fdb_peers_flow() to attempt removal from eswitch instances that were never peered, resulting in a NULL pointer dereference or a list corruption warning [1].

Exploitation

An attacker with access to trigger these operations on a system using the affected mlx5_core kernel module can exploit a race condition. The attacker must be able to create and delete TC flower filters (requiring CAP_NET_ADMIN and a configured eswitch) and trigger a concurrent neighbor update hold on a peer flow. The race window is small, but the issue manifests as a denial-of-service via kernel panic or memory corruption.

Impact

Successful exploitation leads to a kernel list corruption (use-after-free) or NULL pointer dereference, causing a system crash or hang. This results in a denial-of-service condition. No privilege escalation is described, but an out-of-bounds write to the peer list head may corrupt kernel memory.

Mitigation

The fix was included in Linux kernel version 6.6 (as part of a stable update). The commit 74cec142f89b (“net/mlx5e: Fix peer flow lists handling”) was backported to stable releases. Users should update to a kernel containing this fix. No workaround is documented; loading the mlx5_core module without TC offload may reduce exposure.