CVE-2021-47261

What it actually does

Out-of-bounds memory access in init_cq_frag_buf during CQ resize operations because get_cqe always references the primary cq->buf instead of the temporary resize_buf, leading to kernel panic on enlargement.

Why it matters to the business

Unexpected system crashes and denial of service for RDMA workloads on affected mlx5 hardware, disrupting high-performance networking and storage operations until the system is restarted or patched.

How an attack unfolds

An attacker with local access or control over RDMA connections triggers a CQ resize operation via ib_resize_cq, causing the mlx5 driver to access elements beyond the current buffer bounds and panic the kernel during the resize path.

How to fix it

Update the Linux kernel to a version containing the fix that replaces get_cqe with mlx5_frag_buf_get_wqe in init_cq_frag_buf; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the kernel source contains the corrected init_cq_frag_buf implementation using mlx5_frag_buf_get_wqe; test CQ resize operations under load to ensure no panic occurs.

Typical attack path

1. Obtain local execution or RDMA client control on a system using mlx5 IB
2. Initiate a CQ resize operation that invokes init_cq_frag_buf on the temporary buffer
3. Trigger the faulty get_cqe call that references the wrong buffer
4. Cause out-of-bounds access and kernel panic

How to detect it

Search kernel logs and crash dumps for stack traces containing init_cq_frag_buf, mlx5_ib_resize_cq, and references to llt_rdma functions; examine dmesg and kdump outputs for the exception RIP at init_cq_frag_buf.

• init_cq_frag_buf+103
• mlx5_ib_resize_cq
• llt_rdma_setup_qp
• ret_from_fork_nospec_begin

What your security team should do

• Prioritize kernel updates on systems exposing RDMA/IB interfaces
• Restrict untrusted local access and RDMA client privileges until patched
• Monitor for kernel panic reports referencing init_cq_frag_buf or mlx5_ib_resize_cq