CVE-2023-52851

What it actually does

Double free of the same QP object in mlx5_mkey_cache_init error path when workqueue allocation fails, followed by use-after-free when ib_destroy_qp_user is later invoked during cleanup.

Why it matters to the business

Potential kernel crashes or memory corruption on systems using Mellanox InfiniBand adapters during driver initialization under memory pressure; low practical risk given the narrow failure condition but still requires patching to maintain stability on affected hardware.

How an attack unfolds

An attacker with local access triggers the unlikely workqueue allocation failure in mlx5_mkey_cache_init during mlx5_ib driver probe; the missing cleanup call leaves a QP pointer dangling so that subsequent __mlx5_ib_add error handling frees the QP twice, allowing a UAF read in ib_destroy_qp_user.

How to fix it

Upgrade the Linux kernel to a version containing commit 437f033e30c897bb3723eac9e9003cd9f88d00a3 or later; rebuild and reboot with the patched kernel on any system that loads the mlx5_ib module.

How to confirm the fix worked

Verify the running kernel contains commit 437f033e30c897bb3723eac9e9003cd9f88d00a3; confirm absence of the double-free splat in dmesg when forcing mlx5_mkey_cache_init to fail.

Typical attack path

1. Cause workqueue creation to fail inside mlx5_mkey_cache_init (e.g., via memory pressure or -EINTR)
2. mlx5_ib_stage_post_ib_reg_umr_init still calls mlx5r_umr_resource_cleanup which frees the QP
3. __mlx5_ib_add then performs its own cleanup path that again destroys the already-freed QP
4. UAF read occurs inside ib_destroy_qp_user when the stale QP pointer is dereferenced

How to detect it

Search kernel logs and dmesg for strings indicating workqueue creation failure followed by KASAN UAF reports referencing ib_destroy_qp_user and mlx5r_umr_resource_cleanup; inspect crash dumps for slab-use-after-free at the QP address.

• workqueue: Failed to create a rescuer kthread for wq "mkey_cache"
• infiniband mlx5_0: mlx5_mkey_cache_init:981: failed to create work queue
• infiniband mlx5_0: mlx5_ib_stage_post_ib_reg_umr_init:4075: mr cache init failed -12
• BUG: KASAN: slab-use-after-free in ib_destroy_qp_user
• mlx5r_umr_resource_cleanup

What your security team should do

• Apply the fixed kernel commit to all systems exposing the mlx5_ib driver
• Monitor kernel logs for "failed to create work queue" and "mr cache init failed" messages as indicators of exposure
• Reboot after kernel update to ensure the patched mlx5 driver is loaded