CVE-2025-38398

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-qpic-snand: reallocate BAM transactions<br /> <br /> Using the mtd_nandbiterrs module for testing the driver occasionally<br /> results in weird things like below.<br /> <br /> 1. swiotlb mapping fails with the following message:<br /> <br /> [ 85.926216] qcom_snand 79b0000.spi: swiotlb buffer is full (sz: 4294967294 bytes), total 512 (slots), used 0 (slots)<br /> [ 85.932937] qcom_snand 79b0000.spi: failure in mapping desc<br /> [ 87.999314] qcom_snand 79b0000.spi: failure to write raw page<br /> [ 87.999352] mtd_nandbiterrs: error: write_oob failed (-110)<br /> <br /> Rebooting the board after this causes a panic due to a NULL pointer<br /> dereference.<br /> <br /> 2. If the swiotlb mapping does not fail, rebooting the board may result<br /> in a different panic due to a bad spinlock magic:<br /> <br /> [ 256.104459] BUG: spinlock bad magic on CPU#3, procd/2241<br /> [ 256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b<br /> ...<br /> <br /> Investigating the issue revealed that these symptoms are results of<br /> memory corruption which is caused by out of bounds access within the<br /> driver.<br /> <br /> The driver uses a dynamically allocated structure for BAM transactions,<br /> which structure must have enough space for all possible variations of<br /> different flash operations initiated by the driver. The required space<br /> heavily depends on the actual number of &amp;#39;codewords&amp;#39; which is calculated<br /> from the pagesize of the actual NAND chip.<br /> <br /> Although the qcom_nandc_alloc() function allocates memory for the BAM<br /> transactions during probe, but since the actual number of &amp;#39;codewords&amp;#39;<br /> is not yet know the allocation is done for one &amp;#39;codeword&amp;#39; only.<br /> <br /> Because of this, whenever the driver does a flash operation, and the<br /> number of the required transactions exceeds the size of the allocated<br /> arrays the driver accesses memory out of the allocated range.<br /> <br /> To avoid this, change the code to free the initially allocated BAM<br /> transactions memory, and allocate a new one once the actual number of<br /> &amp;#39;codewords&amp;#39; required for a given NAND chip is known.