CVE-2025-38398
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-07-25

Last updated on: 2025-11-19

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: spi: spi-qpic-snand: reallocate BAM transactions Using the mtd_nandbiterrs module for testing the driver occasionally results in weird things like below. 1. swiotlb mapping fails with the following message: [ 85.926216] qcom_snand 79b0000.spi: swiotlb buffer is full (sz: 4294967294 bytes), total 512 (slots), used 0 (slots) [ 85.932937] qcom_snand 79b0000.spi: failure in mapping desc [ 87.999314] qcom_snand 79b0000.spi: failure to write raw page [ 87.999352] mtd_nandbiterrs: error: write_oob failed (-110) Rebooting the board after this causes a panic due to a NULL pointer dereference. 2. If the swiotlb mapping does not fail, rebooting the board may result in a different panic due to a bad spinlock magic: [ 256.104459] BUG: spinlock bad magic on CPU#3, procd/2241 [ 256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b ... Investigating the issue revealed that these symptoms are results of memory corruption which is caused by out of bounds access within the driver. The driver uses a dynamically allocated structure for BAM transactions, which structure must have enough space for all possible variations of different flash operations initiated by the driver. The required space heavily depends on the actual number of 'codewords' which is calculated from the pagesize of the actual NAND chip. Although the qcom_nandc_alloc() function allocates memory for the BAM transactions during probe, but since the actual number of 'codewords' is not yet know the allocation is done for one 'codeword' only. Because of this, whenever the driver does a flash operation, and the number of the required transactions exceeds the size of the allocated arrays the driver accesses memory out of the allocated range. To avoid this, change the code to free the initially allocated BAM transactions memory, and allocate a new one once the actual number of 'codewords' required for a given NAND chip is known.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-07-25
Last Modified
2025-11-19
Generated
2026-05-07
AI Q&A
2025-07-25
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 5 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-476 The product dereferences a pointer that it expects to be valid but is NULL.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is in the Linux kernel's spi-qpic-snand driver. It occurs because the driver initially allocates memory for BAM transactions based on an assumed number of 'codewords' (units related to NAND chip page size), but this initial allocation is too small. When the actual number of codewords is larger, the driver accesses memory beyond the allocated range, causing out-of-bounds memory access. This leads to memory corruption, which can cause errors such as buffer mapping failures, write failures, and kernel panics due to NULL pointer dereferences or bad spinlock states.


How can this vulnerability impact me? :

This vulnerability can cause system instability and crashes. Specifically, it can lead to kernel panics during device reboot due to memory corruption, resulting in NULL pointer dereferences or spinlock errors. This can cause unexpected system reboots or failures, potentially leading to data loss or service interruptions on affected devices using the vulnerable driver.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring kernel logs for specific error messages related to the qcom_snand driver. Look for messages such as 'swiotlb buffer is full', 'failure in mapping desc', 'failure to write raw page', 'write_oob failed (-110)', or kernel panics related to 'spinlock bad magic' or 'kernel paging request'. Commands like 'dmesg | grep qcom_snand' or 'journalctl -k | grep qcom_snand' can help identify these symptoms.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version where the qcom_snand driver properly reallocates BAM transactions memory after determining the actual number of codewords required. This prevents out-of-bounds memory access. Until an update is applied, avoid using the affected driver or the mtd_nandbiterrs module for testing, and monitor for related kernel errors to prevent system panics.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart