CVE-2026-89864: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Bound i2c->length in I2C bsg handlers
struct qlai2caccess carries a 16-bit length field alongside a fixed 64-byte buffer:
struct qlai2caccess { uint16t device, offset, option, length; uint8t buffer[0x40]; } packed;
qla2x00writei2c() and qla2x00readi2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both:
- write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00writesfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00readsfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array.
A caller holding CAPSYSRAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.
Affected Software
Event History
Frequently Asked Questions
What level of access does an attacker need to exploit this issue?
The caller must hold CAP_SYS_RAWIO and be able to submit requests to the affected I2C BSG handlers.
What makes a request malicious?
An oversized user-supplied i2c->length value is used without validation before memory copies and DMA transfers. The length field is 16-bit, while the embedded I2C buffer is only 64 bytes and the DMA-pool buffer is 256 bytes.
What is the potential impact of exploitation?
A successful request can corrupt both kernel heap memory and the kernel stack. In the write path it can also cause DMA to read beyond the 256-byte DMA buffer.