CVE-2026-89865: scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers
The FRU and I2C bsg handlers stage their transfer in a DMAPOOLSIZE (256-byte) bounce buffer obtained from dmapoolalloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00writesfp().
qla2x00writesfp() can override the transfer length with a user-supplied value:
if (len == 1) opt |= BIT0; if (opt & BIT0) len = sfp;
sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAXFRUSIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash.
Allocate the buffer with dmapoolzalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In all five FRU/I2C handlers, allocate the DMA buffer with dma_pool_zalloc() instead of dma_pool_alloc(), so any bytes beyond the initialized prefix are zero and not stale DMA-pool heap data.
Linux kernel (qla2xxx: FRU/I2C bsg handlers) DMA buffer zeroing (dma_pool_zalloc vs dma_pool_alloc) = Use dma_pool_zalloc() in all five FRU/I2C handlers
Event History
Frequently Asked Questions
What access would an attacker need to trigger the stale-memory write?
The transfer length can be overridden by a user-supplied payload byte in the FRU and I2C BSG handlers. Exploitation therefore requires the ability to submit requests to those handlers.
What data could be exposed or corrupted?
The device can DMA-read bytes beyond the initialized portion of a 256-byte DMA bounce buffer and write stale DMA-pool heap contents to device flash. Depending on the handler, up to roughly 219 unintended bytes may be written.
Is there an interim mitigation if the kernel fix cannot be deployed immediately?
The provided information identifies the affected path as the FRU and I2C BSG handlers. Restricting access to submitting requests through those handlers can reduce exposure until the buffer-zeroing fix is applied.