Cloudanix VulnDB

CVE-2026-80931

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel driver for certain 1-Wire to I2C adapter chips can let a malicious or faulty chip feed bad data that crashes the whole system or lets an attacker run code with kernel privileges.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Medium

What it actually does

The vulnerability allows an oversized length byte returned by a downstream I2C device to trigger an out-of-bounds read in w1_f19_i2c_read() inside w1_f19_i2c_master_transfer(), exceeding the allocated I2C_SMBUS_BLOCK_MAX + 2 buffer and writing up to roughly 222 bytes past its end.

Why it matters to the business

Systems that expose the DS28E17 1-Wire-to-I2C bridge to untrusted hardware can experience kernel memory corruption, leading to crashes, denial of service, or potential local privilege escalation; the issue affects any kernel build that includes the w1_ds28e17 driver and has been public for 18 days.

How an attack unfolds

An attacker with local access supplies or emulates a DS28E17 device that returns a length byte greater than 32 on an I2C_M_RECV_LEN transaction; the driver reads that many bytes without an early bounds check, overwriting adjacent kernel memory before the SMBus core can validate the length.

How to fix it

Apply the upstream kernel commit that adds explicit length checks against I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites before calling w1_f19_i2c_read(); rebuild and deploy the patched kernel on all affected systems.

How to confirm the fix worked

Confirm the driver source contains the added length > I2C_SMBUS_BLOCK_MAX rejection at the RECV_LEN handling sites; test with a device that returns an oversize length byte and verify the transaction now returns -EPROTO without memory corruption.

Typical attack path

  1. Gain local access or control of hardware attached to the 1-Wire bus
  2. Configure or emulate a slave device to respond with a length byte > I2C_SMBUS_BLOCK_MAX on a block read
  3. Trigger an I2C_M_RECV_LEN transaction through the w1 ds28e17 master_xfer path
  4. Observe or exploit the resulting kernel memory corruption

How to detect it

Inspect kernel logs for oops or BUG reports referencing w1_f19_i2c_master_transfer or w1_f19_i2c_read; look for unexpected -EPROTO returns on I2C block reads from DS28E17 devices; examine memory dumps or KASAN reports for out-of-bounds accesses originating in the w1 subsystem.

What your security team should do

  • Patch kernels containing the w1_ds28e17 driver to the fixed version as soon as possible
  • Disable the w1_ds28e17 module if the hardware is not required
  • Monitor for kernel oops or slab corruption reports involving w1_f19_i2c_master_transfer

The record

In the Linux kernel, the following vulnerability has been resolved: w1: ds28e17: reject an oversize length on an I2C block read w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the device. The downstream slave puts a length byte in buf[0]. The driver then reads that many bytes into buf[1] with w1_f19_i2c_read(). buf[0] is controlled by the device and can be 0 to 255. w1_f19_i2c_read() only rejects a zero count. The caller buffer is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read run past it, up to about 222 bytes out of bounds. The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That check runs after master_xfer returns. By then the write is already done. i2c-algo-bit rejects an oversize length before it copies, and returns -EPROTO. Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the same way i2c-algo-bit does.

Affected packages

Ecosystem Package Introduced Fixed