Linux Kernel up to 6.1.17/6.2.4 mpi3mr find_first_zero_bit allocation of resources

Summaryinfo

A vulnerability was found in Linux Kernel up to 6.1.17/6.2.4. It has been classified as critical. Affected by this issue is the function find_first_zero_bit of the component mpi3mr. The manipulation leads to allocation of resources. This vulnerability is referenced as CVE-2023-53376. No exploit is available. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.1.17/6.2.4. This issue affects the function find_first_zero_bit of the component mpi3mr. The manipulation with an unknown input leads to a allocation of resources vulnerability. Using CWE to declare the problem leads to CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. Impacted is confidentiality, integrity, and availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Use number of bits to manage bitmap sizes To allocate bitmaps, the mpi3mr driver calculates sizes of bitmaps using byte as unit. However, bitmap helper functions assume that bitmaps are allocated using unsigned long as unit. This gap causes memory access beyond the bitmap sizes and results in "BUG: KASAN: slab-out-of-bounds". The BUG was observed at firmware download to eHBA-9600. Call trace indicated that the out-of-bounds access happened in find_first_zero_bit() called from mpi3mr_send_event_ack() for miroc->evtack_cmds_bitmap. To fix the BUG, do not use bytes to manage bitmap sizes. Instead, use number of bits, and call bitmap helper functions which take number of bits as arguments. For memory allocation, call bitmap_zalloc() instead of kzalloc() and krealloc(). For memory free, call bitmap_free() instead of kfree(). For zero clear, call bitmap_clear() instead of memset(). Remove three fields for bitmap byte sizes in struct scmd_priv which are no longer required. Replace the field dev_handle_bitmap_sz with dev_handle_bitmap_bits to keep number of bits of removepend_bitmap across resize.

It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2023-53376 since 09/17/2025. The exploitation is known to be difficult. Technical details of the vulnerability are known, but there is no available exploit.

The vulnerability scanner Nessus provides a plugin with the ID 265559 (Linux Distros Unpatched Vulnerability : CVE-2023-53376), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.1.18 or 6.2.5 eliminates this vulnerability. Applying the patch 6a675a6d57d31da43d8da576465c1cd5d5b0bd3d/8ac713d2e9845e9234bb12ae5903040685d5aff9/339e61565f81a6534afdc18fd854b2e2628bf5db 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 databases at Tenable (265559) and CERT Bund (WID-SEC-2025-2092). Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Affected

• Amazon Linux 2
• Red Hat Enterprise Linux
• SUSE Linux
• Oracle Linux
• SUSE openSUSE
• RESF Rocky Linux
• Open Source Linux Kernel
• Dell Secure Connect Gateway
• IBM QRadar SIEM

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.1.0
• 6.1.1
• 6.1.2
• 6.1.3
• 6.1.4
• 6.1.5
• 6.1.6
• 6.1.7
• 6.1.8
• 6.1.9
• 6.1.10
• 6.1.11
• 6.1.12
• 6.1.13
• 6.1.14
• 6.1.15
• 6.1.16
• 6.1.17
• 6.2.0
• 6.2.1
• 6.2.2
• 6.2.3
• 6.2.4

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

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion