CVE-2023-54168

What it actually does

User-controlled log_sq_bb_count value allows shift wrapping in set_user_sq_size() during RDMA/mlx4 queue setup, bypassing size validation and enabling incorrect buffer allocation that can lead to memory corruption.

Why it matters to the business

Systems using RDMA hardware on affected Linux kernels face elevated risk of crashes or unauthorized memory access; low exploit likelihood and absence from known campaigns limit immediate operational disruption, though kernel updates remain necessary for long-term stability.

How an attack unfolds

An attacker with local access supplies a crafted log_sq_bb_count value that triggers arithmetic wrap during shift operations in mlx4 queue initialization, resulting in malformed queue structures that may be leveraged for further memory corruption or denial of service.

How to fix it

Upgrade to linux 6.16.5-1 or later on Debian 14, or apply the equivalent kernel commit 3d5ae269c4bd392ec1edbfb3bd031b8f42d7feff in custom builds; rebuild and reboot with the patched kernel; disable mlx4 RDMA interfaces if immediate patching is impossible.

How to confirm the fix worked

Confirm the running kernel version matches or exceeds the listed fixed releases, verify presence of check_shl_overflow() in the mlx4 set_user_sq_size() function via source inspection or binary diff, and test RDMA queue creation with boundary values for log_sq_bb_count.

Typical attack path

1. Obtain local execution context on a system with mlx4 RDMA hardware enabled
2. Invoke RDMA user-space commands that reach set_user_sq_size() with oversized log_sq_bb_count
3. Trigger the unchecked left shift that wraps around
4. Cause allocation of undersized or invalid send queue buffers
5. Leverage resulting memory layout for corruption or crash

How to detect it

Review kernel logs for RDMA/mlx4 initialization failures or warnings around queue size calculations; examine audit logs for unusual user-space RDMA calls; no public exploit artifacts are known so focus on post-patch verification rather than historical indicators.

What your security team should do

• Prioritize kernel package updates on all systems exposing RDMA/mlx4
• Inventory hosts with mlx4 hardware and schedule reboots within standard change windows
• Monitor EPSS and KEV feeds for any future rise in exploit activity
• Apply defense-in-depth by restricting unprivileged RDMA access via capabilities or namespaces