CVE-2024-40990

What it actually does

The RDMA/mlx5 driver accepts a user-supplied max_sge value without bounds checking and subsequently uses that value in calculations and memory operations, permitting values larger than the hardware or driver maximum.

Why it matters to the business

Organizations running RDMA workloads on affected mlx5 hardware face elevated risk of kernel crashes, memory corruption, or potential privilege escalation on systems that have not yet applied the upstream fix; the low EPSS score indicates limited observed exploitation but the kernel's widespread use in high-performance computing and storage increases exposure surface.

How an attack unfolds

An attacker with the ability to issue RDMA verbs or create shared receive queues supplies an oversized max_sge attribute; the driver stores and later dereferences the unchecked value, resulting in out-of-bounds access or uninitialized resource use that can be leveraged for denial of service or code execution.

How to fix it

Upgrade the Linux kernel to a version containing commit 7186b81c1f15e39069b1af172c6a951728ed3511 or later; rebuild and reboot all affected hosts; where immediate patching is impossible, restrict untrusted users from RDMA device access via cgroups or permissions.

How to confirm the fix worked

Verify the running kernel source contains commit 7186b81c1f15e39069b1af172c6a951728ed3511 or confirm the max_sge validation check is present in drivers/infiniband/hw/mlx5/srq.c; re-test RDMA queue creation with boundary values after the update.

Typical attack path

1. Identify a system exposing RDMA interfaces or allowing unprivileged RDMA verb submission
2. Craft an RDMA create_srq or similar request containing a max_sge value exceeding the driver's limit
3. Submit the request to trigger unchecked insertion and subsequent use of the oversized value
4. Observe kernel panic, memory corruption, or attempt to chain the resulting primitive for privilege escalation

How to detect it

Search kernel logs for RDMA/mlx5 error messages or oops related to srq creation; inspect audit logs for unusual RDMA verb submissions from non-standard processes; review any crash dumps containing mlx5_srq references.

What your security team should do

• Prioritize kernel upgrade to the fixed commit across all RDMA-enabled systems within the next maintenance window
• Audit user permissions on /dev/infiniband/* devices and apply least-privilege controls
• Monitor EPSS and threat-intel feeds for any rise in exploitation activity against this class of Linux kernel input-validation flaws
• Include the patched commit hash in SBOM and vulnerability scanning policies