Linux Kernel up to 5.18.2 RDMA hfi1_free_devdata initialization

Summaryinfo

A vulnerability has been found in Linux Kernel up to 5.18.2 and classified as problematic. This affects the function hfi1_free_devdata of the component RDMA. The manipulation leads to initialization. This vulnerability is documented as CVE-2022-49433. There is not any exploit available. The affected component should be upgraded.

Detailsinfo

A vulnerability was found in Linux Kernel up to 5.18.2 and classified as problematic. This issue affects the function hfi1_free_devdata of the component RDMA. The manipulation with an unknown input leads to a initialization vulnerability. Using CWE to declare the problem leads to CWE-665. The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used. The impact remains unknown. The summary by CVE is:

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.

The advisory is shared at git.kernel.org. The identification of this vulnerability is CVE-2022-49433 since 02/26/2025. The exploitation is known to be difficult. Technical details are known, but no exploit is available.

The vulnerability scanner Nessus provides a plugin with the ID 234545 (SUSE SLES12 Security Update : kernel (SUSE-SU-2025:1293-1)), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 4.19.247, 5.4.198, 5.10.121, 5.15.46, 5.17.14 or 5.18.3 eliminates this vulnerability. Applying the patch 66090815a24ce14cf51ef5453fc0218fe8a39bc2/addb192000d8819c0b1553453994df9bb54c28db/fc0750e659db7b315bf6348902cc8ca3cdd4b8d8/ca55150bff5817af4f857a746ecab9862c23e12a/30eb275e7ed588270ae159cc590a96658e0cfd8f/288d198f50434f29b4a26a9de4394ae2305ad8af/05c03dfd09c069c4ffd783b47b2da5dcc9421f2c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the vulnerability database at Tenable (234545). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 4.19.246
• 5.4.197
• 5.10.120
• 5.15.0
• 5.15.1
• 5.15.2
• 5.15.3
• 5.15.4
• 5.15.5
• 5.15.6
• 5.15.7
• 5.15.8
• 5.15.9
• 5.15.10
• 5.15.11
• 5.15.12
• 5.15.13
• 5.15.14
• 5.15.15
• 5.15.16
• 5.15.17
• 5.15.18
• 5.15.19
• 5.15.20
• 5.15.21
• 5.15.22
• 5.15.23
• 5.15.24
• 5.15.25
• 5.15.26
• 5.15.27
• 5.15.28
• 5.15.29
• 5.15.30
• 5.15.31
• 5.15.32
• 5.15.33
• 5.15.34
• 5.15.35
• 5.15.36
• 5.15.37
• 5.15.38
• 5.15.39
• 5.15.40
• 5.15.41
• 5.15.42
• 5.15.43
• 5.15.44
• 5.15.45
• 5.17.0
• 5.17.1
• 5.17.2
• 5.17.3
• 5.17.4
• 5.17.5
• 5.17.6
• 5.17.7
• 5.17.8
• 5.17.9
• 5.17.10
• 5.17.11
• 5.17.12
• 5.17.13
• 5.18.0
• 5.18.1
• 5.18.2

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion