Look up another CVE · open CVE-2026-72113 in the interactive tracker

CVE-2026-72113

can: bcm: add missing device refcount for CAN filter removal

7.8 EPSS 0.2% AV:L

Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem net/can. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-72113 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	fixed	6.12.101-1	Update the kernel and reboot. Fixed in 6.12.101-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.1.5-1	Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.1.5-1	Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12	fixedDLA-4745-1 · 2026-08-18 · text	6.12.101-1~deb12u1	Update the kernel and reboot. DLA-4745-1 shipped the fix on 2026-08-18, in 6.12.101-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 ("can: raw: add missing refcount for memory leak fix") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.

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.

net/can/bcm.c

What this is: CAN NETWORK LAYERMAINTAINERS section matched on net/can/ · linux-can@vger.kernel.org · Maintained
Kernel module: can_bcm

Check it on the machine

grep -wE 'CONFIG_CAN|CONFIG_CAN_BCM' /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 can_bcm

Prints 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_BCM
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

Debian tracker CVE record NVD kernel CNA record

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.17%, higher than 5.8% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: net/can

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
2.6.25	5.10.265	bd5232663524
2.6.25	5.15.216	ee8b36d0faca
2.6.25	6.1.183	dcaee869913c
2.6.25	6.6.148	84aa4807816e
2.6.25	6.12.101	633bda66fbf3
2.6.25	6.18.42	b024c21c9066
2.6.25	7.1.5	04d23061bbf1
2.6.25	7.2	d59948293ea3

Debian advisories

Advisory	Date	Shipped to	Debian
DLA-4777-1	2026-09-08	bookworm 6.1.187-1	tracker
DLA-4745-1	2026-08-18	bookworm 6.12.101-1~deb12u1	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: Exploitation requires local syscalls (socket/sendmsg/close) on PF_CAN/CAN_BCM and concurrent netdev teardown via netlink; the flaw is in local filter cleanup, not remote IP packet handling.
AC:LAttack complexity, low: An attacker can reliably win the race by concurrently closing the BCM socket or issuing RX_DELETE while deleting the bound vcan/CAN interface from the same user namespace.
PR:LPrivileges required, low: BCM sockets need no special capability, and CAP_NET_ADMIN for creating/deleting vcan interfaces is obtainable by unprivileged users via user namespaces (unshare -Urn).
UI:NUser interaction, none: No victim interaction is required; exploitation is fully attacker-driven through BCM socket setup, concurrent netdev removal, and subsequent CAN traffic to hit the stale filter.
S:UScope, unchanged: Impact is confined to kernel memory corruption and privilege escalation within the same security authority; it does not cross VM, container, or IOMMU boundaries.
C:HConfidentiality impact, high: Stale CAN filters leave a use-after-free on freed bcm_op structures; bcm_rx_handler dereferences attacker-influenced freed memory, enabling arbitrary kernel memory disclosure via heap grooming.
I:HIntegrity impact, high: The UAF in bcm_rx_handler provides write primitives over freed bcm_op fields (timers, frame buffers, socket pointers), enabling control-flow hijacking and arbitrary kernel code execution.
A:HAvailability impact, high: Accessing the freed bcm_op from bcm_rx_handler causes kernel oops/panic; UAF is inherently crash-prone even before full exploitation.