Look up another CVE · open CVE-2026-74456 in the interactive tracker
CVE-2026-74456
can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-74456 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-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6466-1 · 2026-08-25 · text | 6.12.105-1 | Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 ("net: usb: lan78xx: Fix double free issue with interrupt buffer allocation").
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/net/can/usb/peak_usb/pcan_usb_core.c
- What this is
- CAN NETWORK DRIVERSMAINTAINERS section matched on drivers/net/can/ · linux-can@vger.kernel.org · Maintained
- Kernel module
- peak_usb
Check it on the machine
grep -wE 'CONFIG_CAN|CONFIG_CAN_PEAK_USB' /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 peak_usbPrints 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_CAN, CONFIG_CAN_PEAK_USB
- 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-08-15 (2 months 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/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 3.4 | 5.10.265 | 914c3b8fa175 |
| 3.4 | 5.15.216 | 5f2fa5840c34 |
| 3.4 | 6.1.183 | b9088d581fff |
| 3.4 | 6.6.151 | 525640b93d3e |
| 3.4 | 6.12.103 | 4bb332507513 |
| 3.4 | 6.18.44 | 92d0de80ca22 |
| 3.4 | 7.1.8 | dfb17bf04a76 |
| 3.4 | 7.2 | 9b3d5a6d952c |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DSA-6466-1 | 2026-08-25 | trixie 6.12.105-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 flaw is only reached when a privileged local actor brings the PEAK CAN netdev up via rtnetlink/ioctl (peak_usb_ndo_open→peak_usb_start); CAN-bus traffic and remote protocols never call this setup path, but the entry is a local syscall rather than USB packet processing.
- AC:LAttack complexity, low
- Any usb_submit_urb() failure on RX setup deterministically hits the broken error path; an attacker can reliably force -ENODEV/-ENOENT by disconnecting/resetting the adapter or presenting a rogue PEAK-class gadget while repeatedly running ip link set canX up/down.
- PR:LPrivileges required, low
- Bringing the CAN interface up requires CAP_NET_ADMIN on RTM_SETLINK (rtnl_setlink/netif_open), which is Low under CNA guidance; on automotive/industrial diagnostic hosts this is commonly held by technician/service accounts even though unauthenticated remote attackers cannot reach the path.
- UI:NUser interaction, none
- No separate victim interaction is needed beyond the attacker (or their malware) issuing the privileged link-up that enters peak_usb_start; they can also script repeated up/down cycles while manipulating USB state themselves.
- S:UScope, unchanged
- The double-free corrupts host kernel kmalloc slab state within the peak_usb driver scope and does not by itself cross a security boundary such as VM escape, container breakout, or IOMMU bypass.
- C:HConfidentiality impact, high
- This is a kmalloc RX-buffer double-free with URB_FREE_BUFFER set; per CNA guidance such heap double-free/UAF-class bugs enable controlled reallocation and arbitrary kernel memory disclosure, not merely a bounded leak.
- I:HIntegrity impact, high
- Freeing the same 64–2048 byte RX slab object twice corrupts SLUB freelist/metadata and provides a standard heap corruption primitive that can be groomed into arbitrary kernel writes or control-flow hijacking.
- A:HAvailability impact, high
- KASAN already reports a double-free in usb_free_urb() on this path; even without full exploitation, allocator corruption typically causes kernel BUG/oops/panic and repeated trigger cycles can deny CAN/USB service on shared diagnostic systems.