CVE-2026-23243: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-23243 Overview

A vulnerability has been identified in the Linux kernel's RDMA/umad subsystem where the ib_umad_write function fails to properly validate user-controlled input, allowing negative data_len values to propagate through to ib_create_send_mad(). This flaw can be exploited when there is a mismatch between the user MAD (Management Datagram) header size and the RMPP (Reliable Multi-Packet Transaction Protocol) header length, causing the padding calculation to exceed the segment size and trigger an out-of-bounds memory write in alloc_send_rmpp_list().

Critical Impact

Attackers with local access can trigger an out-of-bounds memory write in the kernel's RDMA subsystem, potentially leading to system crashes, denial of service, or arbitrary code execution in kernel context.

Affected Products

• Linux Kernel (multiple versions with RDMA/umad support)
• Systems with InfiniBand/RDMA hardware and drivers enabled
• Linux distributions using vulnerable kernel versions

Discovery Timeline

• 2026-03-18 - CVE CVE-2026-23243 published to NVD
• 2026-03-18 - Last updated in NVD database

Technical Details for CVE-2026-23243

Vulnerability Analysis

The vulnerability resides in the ib_umad_write function within the Linux kernel's RDMA user MAD (Management Datagram) interface. This function is responsible for handling write operations to the /dev/infiniband/umad* device files, which provide userspace applications with access to InfiniBand management interfaces.

The core issue is an integer underflow vulnerability that occurs during the calculation of data_len. This value is computed by subtracting header sizes from a user-controlled count parameter. When a specially crafted request provides a mismatched combination of user MAD header size and RMPP header length, the arithmetic can result in a negative data_len value.

Since C handles signed integers, this negative value is passed to ib_create_send_mad() where it is used in subsequent memory operations. The KASAN (Kernel Address Sanitizer) output confirms that this leads to an out-of-bounds write of 220 bytes in the alloc_send_rmpp_list() function, where the padding calculation exceeds valid segment boundaries.

The vulnerability was detected via KASAN instrumentation, which reported a slab-out-of-bounds write condition triggered by user threads interacting with the vulnerable code path.

Root Cause

The root cause is improper input validation in the ib_umad_write function. The code computes data_len from user-provided values without checking whether the result becomes negative before using it in memory allocation and copy operations. The signed integer representation allows negative values to pass through unchecked, eventually corrupting adjacent memory regions when used as a size parameter in memory operations.

Attack Vector

An attacker with local access to a system with InfiniBand/RDMA hardware enabled can exploit this vulnerability by:

1. Opening the /dev/infiniband/umad* device file (requires appropriate permissions)
2. Crafting a write request with carefully chosen MAD header size and RMPP header length values
3. Triggering the integer underflow condition that produces a negative data_len
4. Causing an out-of-bounds write in kernel memory via ib_create_send_mad()

The attack requires local access to a system with RDMA capabilities enabled. The KASAN stack trace shows the exploitation path through ib_umad_write → ib_create_send_mad, confirming the vulnerability mechanism.

Detection Methods for CVE-2026-23243

Indicators of Compromise

• KASAN kernel log messages reporting "slab-out-of-bounds" writes in ib_create_send_mad or alloc_send_rmpp_list
• Kernel panic or oops messages originating from RDMA/umad code paths
• Unexpected system crashes on systems with active InfiniBand/RDMA workloads
• Unusual access patterns to /dev/infiniband/umad* device files

Detection Strategies

• Enable KASAN (Kernel Address Sanitizer) on development and testing systems to detect memory corruption attempts
• Monitor kernel logs for RDMA-related error messages and stack traces
• Implement audit rules for access to /dev/infiniband/umad* device files
• Deploy kernel live patching solutions to detect and block exploitation attempts

Monitoring Recommendations

• Configure syslog forwarding for kernel messages containing "KASAN", "slab-out-of-bounds", or "ib_umad" keywords
• Implement file access monitoring on InfiniBand management interfaces
• Deploy endpoint detection solutions capable of identifying kernel memory corruption patterns
• Review audit logs for suspicious RDMA-related system calls

How to Mitigate CVE-2026-23243

Immediate Actions Required

• Apply the kernel security patches available from the official Linux kernel Git repository
• Restrict access to /dev/infiniband/umad* device files to only necessary users and applications
• Consider disabling RDMA/umad kernel module on systems where InfiniBand functionality is not required
• Enable KASAN on non-production systems to detect exploitation attempts

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix adds an explicit check to reject negative data_len values before creating the send buffer in ib_umad_write. Multiple commits have been backported to stable kernel branches:

• Kernel Git Commit 1371ef6
• Kernel Git Commit 205955f
• Kernel Git Commit 362e45f
• Kernel Git Commit 52ab82c
• Kernel Git Commit 5551b02
• Kernel Git Commit 6eb2919
• Kernel Git Commit 9c80d68
• Kernel Git Commit a6a3e4a

Workarounds

• Unload the ib_umad kernel module if InfiniBand user-space management is not required: modprobe -r ib_umad
• Blacklist the module to prevent automatic loading by adding blacklist ib_umad to /etc/modprobe.d/blacklist.conf
• Restrict device file permissions to root-only access: chmod 600 /dev/infiniband/umad*
• Use SELinux or AppArmor policies to limit which processes can access RDMA device files

# Configuration example
# Disable ib_umad module loading
echo "blacklist ib_umad" >> /etc/modprobe.d/blacklist-rdma.conf

# Remove module if currently loaded
modprobe -r ib_umad

# Restrict device file permissions (if module must remain loaded)
chmod 600 /dev/infiniband/umad*

# Update module dependencies
depmod -a