Look up another CVE · open CVE-2026-53161 in the interactive tracker
CVE-2026-53161
misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context
Published 2026-06-25 (4 months ago) by the Linux kernel CNA. Subsystem drivers/misc. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-53161 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
There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.
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/misc/fastrpc.c
- What this is
- QUALCOMM FASTRPC DRIVERMAINTAINERS section matched on drivers/misc/fastrpc.c · linux-arm-msm@vger.kernel.org · Maintained
- Kernel module
- fastrpc
Check it on the machine
grep -w CONFIG_QCOM_FASTRPC /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 fastrpcPrints 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
- trixieMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- 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_QCOM_FASTRPC
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-25 (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.13%, higher than 2.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/misc
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.1 | 5.10.259 | c6e5c2be09f8 |
| 5.1 | 5.15.210 | e1e3a05efe59 |
| 5.1 | 6.1.176 | d42679eef34d |
| 5.1 | 6.6.143 | df08fadcf0e5 |
| 5.1 | 6.12.94 | ecea4967c2bf |
| 5.1 | 6.18.36 | 5278ccd357e0 |
| 5.1 | 7.0.13 | fbe0947420ee |
| 5.1 | 7.1 | e85eb5feca8e |
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 code is reached through local FastRPC misc-device file operations and ioctls on /dev/fastrpc-* rather than by network or physical input.
- AC:LAttack complexity, low
- The attacker can create in-flight DSP invokes and race close/interruption against DSP response workqueue cleanup, and the race can be retried under attacker control.
- PR:LPrivileges required, low
- No in-driver capability check gates open or invoke; in plausible Qualcomm/Android deployments an unprivileged local app can reach FastRPC directly or through a HAL-provided fd.
- UI:NUser interaction, none
- Exploitation requires only attacker-controlled local ioctls, close, and timing; no separate victim action is needed.
- S:UScope, unchanged
- The memory corruption affects the kernel driver and kernel memory within the same OS security authority, with no VM or sandbox boundary escape inherent to the bug.
- C:HConfidentiality impact, high
- This is a kernel use-after-free of fastrpc_user reachable from deferred context cleanup, and UAF conditions can be shaped into kernel memory disclosure primitives.
- I:HIntegrity impact, high
- The UAF can dereference attacker-reclaimed kernel heap state through buffer/map cleanup paths, making kernel memory corruption and potential control-flow or arbitrary-write exploitation defensible.
- A:HAvailability impact, high
- At minimum the stale fastrpc_user dereference can crash or oops the kernel during workqueue cleanup, causing high availability impact.