CVE-2022-49429 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: Prevent panic when SDMA is disabled
If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to hfi1_write_iter() will dereference a NULL pointer and panic. A typical stack frame is:
sdma_select_user_engine [hfi1]
hfi1_user_sdma_process_request [hfi1]
hfi1_write_iter [hfi1]
do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64
The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with EINVAL.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/22/2025
The vulnerability CVE-2022-49429 represents a critical null pointer dereference issue within the Linux kernel's RDMA hfi1 driver component. This flaw specifically manifests when the hfi1 module is initialized with the HFI1_CAP_SDMA capability disabled, creating a dangerous condition where subsequent write operations can trigger system panics. The vulnerability resides in the hfi1_write_iter() function which fails to properly validate the availability of SDMA resources before attempting to access them, leading to a kernel oops condition that terminates system stability.
The technical exploitation pathway begins with the loading of the hfi1 module without SDMA support, followed by a write operation through the kernel's file system interface. When hfi1_write_iter() is invoked, it attempts to call sdma_select_user_engine() which operates on a NULL pointer reference due to the disabled SDMA capability. The call stack progression shows this sequence: sdma_select_user_engine() calls hfi1_user_sdma_process_request() which then invokes hfi1_write_iter(), ultimately leading through the standard kernel I/O processing chain including do_iter_readv_writev, do_iter_write, vfs_writev, and finally do_writev before reaching the system call handler. This represents a classic case of inadequate null pointer validation in kernel space operations.
The operational impact of this vulnerability extends beyond simple system instability to potentially enable denial of service attacks against systems running RDMA hardware. Since the hfi1 driver is commonly used in high-performance computing environments and data center networks, an attacker could exploit this condition to crash the entire system or cause service interruptions. The vulnerability affects systems using Intel Omni-Path and other InfiniBand-compatible hardware that relies on the hfi1 driver for communication. This type of kernel panic can result in complete system shutdown requiring manual intervention and potentially data loss from unclean shutdowns, making it particularly dangerous in production environments where system availability is critical.
The fix for this vulnerability implements proper input validation by testing for SDMA capability within the hfi1_write_iter() function and returning an EINVAL error code when SDMA is not available. This approach follows the principle of defensive programming and aligns with CWE-476 which addresses null pointer dereference issues. The solution prevents the kernel from attempting to access uninitialized or unavailable resources while providing a clear error indication to user-space applications. From an ATT&CK perspective, this vulnerability relates to T1499.004 (Endpoint Termination) and T1566.001 (Phishing: Spearphishing Attachment), as it can be exploited through kernel-level attacks or by leveraging compromised applications that attempt to write to RDMA devices. Organizations should ensure their systems are updated with the patched kernel version to prevent exploitation, as the vulnerability can be triggered through normal file system operations without requiring special privileges or complex attack vectors.
The remediation strategy should include immediate kernel updates across all systems utilizing RDMA hardware, particularly in enterprise data center environments where hfi1 drivers are commonly deployed. System administrators should also implement monitoring for kernel panic events and ensure proper patch management protocols are in place to address similar vulnerabilities in the future. The vulnerability demonstrates the importance of thorough capability checking in kernel drivers and highlights the need for comprehensive testing of driver behavior under various configuration states to prevent similar issues from arising in other kernel subsystems.