Look up another CVE · open CVE-2026-64123 in the interactive tracker
CVE-2026-64123
net: hsr: defer node table free until after RCU readers
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem net/hsr. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-64123 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 | fixed | 6.1.176-1 | Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
HSR node-list and node-status generic-netlink operations run under rcu_read_lock(). They walk hsr->node_db through hsr_get_next_node() and hsr_get_node_data(), but RTM_DELLINK teardown removes the same node table with plain list_del() and frees each node immediately. That lets a generic-netlink reader hold a struct hsr_node pointer across hsr_dellink(). In a KASAN build, widening the reader window after hsr_get_next_node() obtains the node reproduces a slab-use-after-free when the reader copies node->macaddress_A; the freeing stack is hsr_del_nodes() from hsr_dellink(). Use list_del_rcu() and defer the free through the existing hsr_free_node_rcu() callback. This matches the lifetime rule used by the HSR prune paths, which already delete nodes with list_del_rcu() and call_rcu().
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/hsr/hsr_framereg.c
- What this is
- HSR NETWORK PROTOCOLMAINTAINERS section matched on net/hsr/ · netdev@vger.kernel.org · Orphan
- Kernel module
- hsr
Check it on the machine
grep -w CONFIG_HSR /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 hsrPrints 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 does not build this code in 1 release. It does build it in 3 releases, so the answer depends on which release the machine runs.
- bookwormn
- trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- n
- not enabled on any flavour - this release does not build the code
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_HSR
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-07-19 (3 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.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/hsr
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.3 | 5.10.259 | 0ea70fb46940 |
| 5.3 | 5.15.210 | 8be6685cdd12 |
| 5.3 | 6.1.176 | c5580114e049 |
| 5.3 | 6.6.143 | 7713f4aafb57 |
| 5.3 | 6.12.93 | 6324423a8e65 |
| 5.3 | 6.18.57 | 48d09dea506d |
| 5.3 | 7.0.11 | 8c3af18bb0d7 |
| 5.3 | 7.1 | aaec7096f996 |
| 5.2.12 | 0 | 0 |
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 netlink access: generic-netlink HSR_C_GET_NODE_LIST/HSR_C_GET_NODE_STATUS and rtnetlink RTM_DELLINK. The bug is not reachable via HSR/PRP network frames despite HSR being a network redundancy protocol.
- AC:LAttack complexity, low
- The attacker controls both sides of the race by issuing concurrent GENL node queries and RTM_DELLINK on separate threads; no unpredictable victim state or memory layout is required beyond having an HSR interface configured.
- PR:LPrivileges required, low
- Reliable exploitation requires CAP_NET_ADMIN to delete the HSR device via RTM_DELLINK (and typically to create it); CAP_NET_ADMIN is obtainable by an unprivileged user through user namespaces (unshare -Urn), and the GENL read operations themselves carry no admin-perm flag.
- UI:NUser interaction, none
- No victim interaction is required; the race is triggered entirely by the attacker's own concurrent netlink operations.
- S:UScope, unchanged
- Impact is confined to kernel memory corruption and privilege escalation within the same kernel/host security boundary, not a cross-boundary escape such as VM or sandbox breakout.
- C:HConfidentiality impact, high
- This is a slab use-after-free on struct hsr_node; freed objects can be reallocated and read through fields like macaddress_A/B and block_buf, enabling arbitrary kernel memory disclosure.
- I:HIntegrity impact, high
- UAF on a kmalloc'd hsr_node with spinlock and pointer fields (block_buf, seq_blocks) provides standard heap-spray primitives for arbitrary kernel writes and potential code execution.
- A:HAvailability impact, high
- Use-after-free on hsr_node during RCU-protected traversal causes kernel oops/panic even without full exploitation, as confirmed by KASAN on the macaddress_A copy path.