CVE-2022-49433 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: Prevent use of lock before it is initialized
If there is a failure during probe of hfi1 before the sdma_map_lock is initialized, the call to hfi1_free_devdata() will attempt to use a lock that has not been initialized. If the locking correctness validator is on then an INFO message and stack trace resembling the following may be seen:
INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Call Trace: register_lock_class+0x11b/0x880 __lock_acquire+0xf3/0x7930 lock_acquire+0xff/0x2d0 _raw_spin_lock_irq+0x46/0x60 sdma_clean+0x42a/0x660 [hfi1]
hfi1_free_devdata+0x3a7/0x420 [hfi1]
init_one+0x867/0x11a0 [hfi1]
pci_device_probe+0x40e/0x8d0
The use of sdma_map_lock in sdma_clean() is for freeing the sdma_map memory, and sdma_map is not allocated/initialized until after sdma_map_lock has been initialized. This code only needs to be run if sdma_map is not NULL, and so checking for that condition will avoid trying to use the lock before it is initialized.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2025
The vulnerability described in CVE-2022-49433 represents a critical synchronization issue within the Linux kernel's RDMA hfi1 driver implementation. This flaw manifests as a race condition or improper initialization sequence that can lead to system instability and potential security implications. The vulnerability specifically affects the hfi1 driver which is part of the Intel Omni-Path Fabric hardware support in the Linux kernel. The issue arises during the device probe phase when hardware initialization fails, creating a scenario where the locking mechanism is accessed before proper initialization has occurred.
The technical root cause of this vulnerability lies in the improper ordering of initialization steps within the device probe function. According to the kernel's locking correctness validator framework, the sdma_map_lock variable is being used before it has been properly initialized through the standard kernel locking initialization routines. This violates fundamental kernel programming practices and can trigger kernel panic conditions or undefined behavior. The vulnerability is classified under CWE-665 Improper Initialization and specifically relates to improper locking initialization as outlined in the Linux kernel locking guidelines. The stack trace demonstrates that the error occurs in the sdma_clean function when attempting to acquire a lock that has not yet been registered with the kernel's lock dependency validator.
The operational impact of this vulnerability extends beyond simple system crashes to potentially enable privilege escalation or denial of service conditions. When the locking correctness validator is enabled, which is common in security-hardened environments, the system will generate INFO messages and stack traces indicating the improper lock usage. This can be exploited by malicious actors to cause system instability or to potentially bypass security mechanisms. The vulnerability affects systems running Linux kernels with RDMA support, particularly those utilizing Intel Omni-Path Fabric hardware, and represents a significant risk in enterprise computing environments where such hardware is deployed. The condition is particularly dangerous because it occurs during device initialization, meaning that any system boot process involving affected hardware could be compromised.
Mitigation strategies for this vulnerability involve ensuring proper code flow and initialization ordering within the kernel driver. The recommended fix implements a simple but critical conditional check that verifies whether sdma_map is not NULL before attempting to use sdma_map_lock. This approach aligns with the ATT&CK framework's defense evasion techniques by preventing improper lock usage that could be leveraged for privilege escalation. System administrators should ensure their kernel versions include the patched implementation, which typically involves applying the upstream kernel patch that adds the NULL check before lock usage. Additionally, organizations should maintain regular kernel update schedules and consider disabling the locking correctness validator only as a temporary workaround while awaiting proper patches, as this validation is crucial for identifying other potential synchronization issues in the kernel. The fix demonstrates proper kernel development practices by ensuring that all locking primitives are properly initialized before use, thereby preventing the type of improper lock usage that could lead to system compromise or denial of service conditions.