CVE-2026-45865: mctp i2c: initialise event handler read bytes
In the Linux kernel, the following vulnerability has been resolved:
mctp i2c: initialise event handler read bytes
Set a 0xff value for i2c reads of an mctp-i2c device. Otherwise reads will return "val" from the i2c bus driver. For i2c-aspeed and i2c-npcm7xx that is a stack uninitialised u8.
Tested with "i2ctransfer -y 1 r10@0x34" where 0x34 is a mctp-i2c instance, now it returns all 0xff.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Set read bytes for i2c accesses of an mctp-i2c device to 0xff (e.g., so an i2ctransfer read such as r10@0x34 where 0x34 is an mctp-i2c instance returns all 0xff instead of uninitialized stack bytes).
Linux kernel mctp-i2c i2c read value for mctp-i2c device = 0xff - Compensating control
Verify the fix by testing with i2ctransfer, e.g., run "i2ctransfer -y 1 r10@0x34" where 0x34 is an mctp-i2c instance, and confirm the read returns all 0xff.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems running the Linux kernel with an mctp-i2c device are affected. The described behavior is specifically observed with the i2c-aspeed and i2c-npcm7xx I2C bus drivers.
What access does an attacker need to trigger the issue?
The CVSS vector indicates local access with low privileges and no user interaction. The issue can be triggered by reading from an mctp-i2c device, as demonstrated with an i2ctransfer read operation.
What happens when the issue is triggered?
Instead of returning 0xff bytes for reads from an mctp-i2c device, affected drivers can return an uninitialized stack u8 value. This is an availability-impacting issue according to the supplied CVSS assessment.
How can I check whether a system has the corrected behavior?
A read from an mctp-i2c instance should return all 0xff bytes. The supplied test example is "i2ctransfer -y 1 r10@0x34", where 0x34 is the mctp-i2c instance address.