Look up another CVE · open CVE-2026-52947 in the interactive tracker
CVE-2026-52947
net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove
Published 2026-06-24 (4 months ago) by the Linux kernel CNA. Subsystem net/qrtr. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-52947 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-4665-1 · 2026-07-03 · text | 6.1.176-1 | Update the kernel and reboot. DLA-4665-1 shipped the fix on 2026-07-03, 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.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: <TASK> qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... </TASK> Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)
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/qrtr/af_qrtr.c
- What this is
- QUALCOMM IPC ROUTER (QRTR) DRIVERMAINTAINERS section matched on net/qrtr/ · linux-arm-msm@vger.kernel.org · Maintained
- Kernel module
- qrtr
Check it on the machine
grep -w CONFIG_QRTR /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 qrtrPrints 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.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_QRTR
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-06-24 (4 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.11%, higher than 1.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/qrtr
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.7 | 5.10.259 | 2aa4c12723fe |
| 4.7 | 5.15.210 | 03bfa95e452e |
| 4.7 | 6.1.176 | 474293d90880 |
| 4.7 | 6.6.143 | 2047c2aa0963 |
| 4.7 | 6.12.94 | 7de2d447072b |
| 4.7 | 6.18.36 | ab269990ed58 |
| 4.7 | 7.0.13 | 3b20ec8f31e8 |
| 4.7 | 7.1 | a2171131ecda |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4671-1 | 2026-07-05 | bullseye 6.1.176-1~deb11u1 | tracker |
| DLA-4665-1 | 2026-07-03 | bookworm 6.1.176-1 | tracker |
| DLA-4664-1 | 2026-07-03 | bullseye 5.10.259-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 vulnerable path is reachable through local AF_QIPCRTR datagram sockets via bind/autobind, sendmsg lookup, rebind, and close/release; QRTR transports are local IPC/internal device transports rather than Internet-facing network services. A local unprivileged process on a QRTR-enabled system can create and race these sockets.
- AC:LAttack complexity, low
- Although this is a race, the attacker can control both sides by repeatedly removing bound QRTR ports while concurrently causing QRTR port lookups through local sends or other QRTR activity. Syzkaller reached the race, and there are no special external conditions beyond attacker-driven concurrency.
- PR:LPrivileges required, low
- Creating AF_QIPCRTR sockets and binding ephemeral or high-numbered QRTR ports does not require CAP_NET_ADMIN or root. Control-port binding has extra checks, but exploitation does not depend on becoming the controller.
- UI:NUser interaction, none
- No victim action is required once the attacker has local code execution. The attacker can create sockets, bind/send/close them, and run the race directly.
- S:UScope, unchanged
- The corruption is within the kernel networking/QRTR subsystem and does not cross a separate security authority such as a VM, IOMMU, or sandbox boundary. A local kernel compromise remains unchanged scope.
- C:HConfidentiality impact, high
- The bug is a potential use-after-free of a QRTR socket object reachable through stale XArray/RCU lookups and refcount resurrection. Per kernel scoring guidance, UAF memory corruption can be leveraged for high-impact information disclosure.
- I:HIntegrity impact, high
- A UAF on a kernel socket object can potentially be shaped with heap spraying into write or control-flow primitives. When uncertain, this should be scored as high integrity impact rather than only a crash.
- A:HAvailability impact, high
- The observed failure is a refcount saturation warning on a stale socket reference, and the underlying UAF can lead to kernel oops, panic, or memory corruption. This is high availability impact.