CVE-2021-47438

What it actually does

Incomplete cleanup on error return from mlx5_core_destroy_cq leaves debug and resource objects allocated, producing a kernel memory leak visible via kmemleak.

Why it matters to the business

Systems using affected Mellanox network adapters may experience gradual memory exhaustion during channel or PTP reconfiguration operations, eventually causing performance degradation or instability.

How an attack unfolds

An attacker with local privileges triggers repeated ethtool private-flag changes that invoke mlx5e_set_priv_flags and the failing destroy path, accumulating unreferenced objects until memory pressure occurs.

How to fix it

Apply the upstream fix that completes all destroy operations before returning and moves mlx5_debug_cq_remove to the start of the function; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting mlx5_core_destroy_cq for the early debug-remove call and the completed destroy sequence before any error return; run kmemleak scan after flag changes to verify no new leaks.

Typical attack path

1. Obtain local shell on target system with ethtool access
2. Repeatedly toggle tx-port-timestamp private flag via ethtool
3. mlx5e_safe_switch_params calls mlx5_core_destroy_cq which returns early
4. Memory objects allocated during create path remain referenced only in debug tree
5. kmemleak reports grow over successive failed destroy operations

How to detect it

Search kernel logs and kmemleak output for unreferenced mlx5 CQ debug objects allocated via add_res_tree and mlx5_debug_cq_add; correlate with ethtool process activity changing private flags.

What your security team should do

• Prioritize kernel update on all hosts with mlx5 hardware within standard change windows
• Monitor kmemleak reports on systems performing frequent ethtool private-flag modifications
• Restrict ethtool access to privileged users only