Look up another CVE · open CVE-2026-80931 in the interactive tracker
CVE-2026-80931
w1: ds28e17: reject an oversize length on an I2C block read
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem drivers/w1. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-80931 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/w1/slaves/w1_ds28e17.c
- What this is
- W1 DALLAS'S 1-WIRE BUSMAINTAINERS section matched on drivers/w1/ · Maintained
- Kernel module
- w1_ds28e17
Check it on the machine
grep -wE 'CONFIG_W1|CONFIG_W1_SLAVE_DS28E17' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w w1_ds28e17Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookworm, trixie, forky, sid, bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_W1, CONFIG_W1_SLAVE_DS28E17
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/w1
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.15 | 5.10.270 | b30c021c6073 |
| 4.15 | 5.15.221 | 1d08877fc37e |
| 4.15 | 6.1.188 | bf76d61e118b |
| 4.15 | 6.6.157 | 0f6496b34cc2 |
| 4.15 | 6.12.109 | cb55c5da9828 |
| 4.15 | 6.18.50 | ae0c79a85270 |
| 4.15 | 7.2.4 | 6df05f630c84 |
| 4.15 | 7.3 | 169ae5e65e5a |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The overflow is reached from local userspace via /dev/i2c-* I2C_SMBUS or I2C_RDWR ioctls into w1_f19_i2c_master_transfer() on the DS28E17-created I2C adapter; i2c-dev does not require advertised I2C_FUNC_SMBUS_READ_BLOCK_DATA. There is no network path; the 1-Wire-to-I2C bridge being present is a deployment precondition.
- AC:LAttack complexity, low
- A single I2C_M_RECV_LEN block read uses the downstream slave's first data byte as the extra length with no cap, then w1_f19_i2c_read() copies that many bytes. The attacker chooses the ioctl and target address; a responding slave returning >32 (or data the attacker just wrote) overflows reliably, with no race or uncontrolled layout.
- PR:LPrivileges required, low
- i2cdev_open() has no capability check; reachability depends only on /dev/i2c-* permissions, commonly 0660 root:i2c on embedded and industrial systems. That is unprivileged local access, not real init-namespace root.
- UI:NUser interaction, none
- The attacker triggers the bug with their own open/ioctl sequence on an already-present DS28E17 I2C adapter node. No victim action such as plugging in a device or mounting a filesystem is required.
- S:UScope, unchanged
- Impact is ordinary host-kernel stack or heap corruption of the SMBus/i2c-dev transfer buffer within the same kernel authority. It does not cross a VM, IOMMU, or other separate security boundary.
- C:HConfidentiality impact, high
- A device-supplied length up to 255 causes an out-of-bounds write of about 222 bytes past the 34-byte I2C_SMBUS_BLOCK_MAX+2 buffer into adjacent kernel stack or heap. That memory corruption is defensibly leveraged for kernel information disclosure.
- I:HIntegrity impact, high
- Slave-controlled bytes are written past the end of the kernel transfer buffer, producing a substantial out-of-bounds kernel write. Such corruption is exploitable for arbitrary memory modification or control-flow hijacking.
- A:HAvailability impact, high
- The out-of-bounds kernel write can corrupt heap or stack state and cause an oops, panic, or hang. The attacker can repeat the local ioctl to deny service.