CVE-2026-45865

What it actually does

This Linux kernel flaw affects the MCTP-over-I2C implementation when handling reads from an MCTP I2C device. On affected systems, certain I2C bus drivers such as i2c-aspeed and i2c-npcm7xx may return an uninitialized stack byte instead of a deterministic 0xff value. A local user with permission to access the relevant I2C device can trigger undefined read behavior, which may lead to unreliable device behavior or availability impact. The issue is local, requires low privileges, does not require user interaction, and there is no indication of remote code execution.

Why it matters to the business

Systems that expose MCTP-over-I2C interfaces, especially embedded Linux, BMC, server management, or hardware-management platforms, may experience instability or disruption if a local user or compromised process abuses low-level I2C access. Because the issue is not listed in CISA KEV, has very low EPSS, and has no known public exploit maturity, broad internet-scale exploitation is unlikely; however, organizations that allow non-administrative access to /dev/i2c devices should treat it as a hardening and availability risk.

How an attack unfolds

An attacker first needs local access to a Linux system where MCTP-over-I2C is enabled and an affected I2C controller driver is in use. The attacker then determines which /dev/i2c-* bus exposes an MCTP I2C endpoint and issues raw I2C read operations, for example using tools such as i2ctransfer or custom code using the i2c-dev interface. On vulnerable kernels, the read path may return an uninitialized stack byte supplied by the bus driver instead of a fixed 0xff value. Repeated or targeted reads can cause unpredictable behavior in software expecting deterministic MCTP I2C read results and may contribute to local denial of service or instability in hardware-management workflows.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the upstream fix for the MCTP I2C read initialization issue. No exact fixed package versions were provided in the input, so use the relevant distribution, appliance, BMC, or hardware-vendor advisory to identify the corrected kernel build. As mitigation, restrict access to /dev/i2c-* device nodes to trusted administrators only, remove unneeded users from the i2c group, avoid granting CAP_SYS_RAWIO broadly, disable unused MCTP-over-I2C functionality where operationally safe, and limit local code execution paths on systems with exposed I2C buses.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor patch for the MCTP I2C read initialization fix. Verify exposure by checking whether MCTP-over-I2C support is present and whether i2c-aspeed or i2c-npcm7xx drivers are loaded or built into the kernel. Review permissions on /dev/i2c-* and confirm untrusted users cannot access them. Functional validation can include repeating the documented read behavior against a test MCTP I2C endpoint and confirming reads return deterministic 0xff bytes rather than inconsistent values. Perform this testing only on non-production or maintenance-window systems because raw I2C operations can affect hardware state.

Typical attack path

1. Obtain local shell access or execute code as a low-privileged user on a Linux system.
2. Confirm access to I2C device nodes such as /dev/i2c-* through group membership, permissions, or delegated capabilities.
3. Identify systems using MCTP-over-I2C and affected I2C controller drivers such as i2c-aspeed or i2c-npcm7xx.
4. Use i2ctransfer, i2cget, or custom i2c-dev code to issue reads against the MCTP I2C endpoint.
5. Trigger vulnerable read behavior where an uninitialized stack byte is returned instead of a deterministic 0xff value.
6. Repeat the operation or integrate it into a local script to disrupt MCTP/I2C-dependent management functions or cause service instability.

How to detect it

There are no known public exploit indicators and exploitation is local, so detection should focus on evidence of suspicious raw I2C access. Review auditd, process execution telemetry, shell history, sudo logs, EDR events, and system accounting for i2ctransfer, i2cget, or custom binaries opening /dev/i2c-* devices. Check kernel logs and persistent journal entries for MCTP or I2C-related warnings, errors, oopses, device resets, or instability involving mctp-i2c, i2c-aspeed, or i2c-npcm7xx. If auditd is available, search for open/read/ioctl activity against /dev/i2c-* by unexpected users or services. Correlate any suspicious access with operational issues in BMC, platform-management, or hardware-monitoring functions.

• i2ctransfer
• i2cget
• /dev/i2c-
• mctp-i2c
• i2c-aspeed
• i2c-npcm7xx
• i2ctransfer -y
• r10@0x34
• i2c-dev
• ioctl I2C_RDWR
• kernel: mctp
• kernel: i2c
• audit:.*\/dev\/i2c-

What your security team should do

• Prioritize patching Linux kernels on BMCs, embedded systems, server-management controllers, and hardware-management hosts that use MCTP-over-I2C.
• Inventory systems exposing /dev/i2c-* and identify where non-root users or service accounts have I2C access.
• Restrict /dev/i2c-* permissions to trusted administrative users and remove unnecessary membership in the i2c group.
• Monitor for use of raw I2C tooling such as i2ctransfer and i2cget by non-administrative users.
• Review kernel logs for MCTP, I2C, or driver instability around i2c-aspeed and i2c-npcm7xx devices.
• Because exploitation is local and EPSS is very low, prioritize internet-facing and remotely exploitable vulnerabilities first unless affected systems are critical hardware-management infrastructure.