Look up another CVE · open CVE-2026-68458 in the interactive tracker
CVE-2026-68458
binder: cache secctx size before release zeroes it
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/android. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-68458 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| 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. |
The vulnerability
What the bug is
binder_transaction() bounds the scatter-gather buffer area with sg_buf_end_offset and subtracts the aligned LSM context size because the secctx is written at the tail of that area. The subtraction reads lsmctx.len, but that field has already been cleared by the time the line runs: security_secid_to_secctx(secid, &lsmctx) /* lsmctx.len set */ lsmctx_aligned_size = ALIGN(lsmctx.len, sizeof(u64)) extra_buffers_size += lsmctx_aligned_size ... security_release_secctx(&lsmctx) /* memset zeroes len */ ... sg_buf_end_offset = sg_buf_offset + extra_buffers_size - ALIGN(lsmctx.len, sizeof(u64)) /* ALIGN(0,8) */ security_release_secctx() does memset(cp, 0, sizeof(*cp)), so lsmctx.len reads back as 0 and the subtraction contributes nothing, leaving sg_buf_end_offset too large by the aligned secctx size on every transaction to a txn_security_ctx node. Each BINDER_TYPE_PTR object then derives buf_left = sg_buf_end_offset - sg_buf_offset as the sole upper bound on its copy, so the inflated end offset lets the copy run into the bytes that already hold the secctx. The aligned size must therefore be cached before release rather than re-read from the now-cleared field. Fix by caching it in lsmctx_aligned_size at function scope when it is first computed and subtracting lsmctx_aligned_size instead of re-reading lsmctx.len after release. Reuse the same value for the earlier buf_offset computation.
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/android/binder.c
- What this is
- ANDROID DRIVERSMAINTAINERS section matched on drivers/android/ · linux-kernel@vger.kernel.org · Supported
- Kernel module
- binder
Check it on the machine
grep -w CONFIG_ANDROID_BINDER_IPC /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 binderPrints 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, i386/686, i386/686-pae, i386/rt/686-pae, ppc64el/powerpc64le
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_ANDROID_BINDER_IPC
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.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/android
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.14 | 6.18.40 | 1228926e1e4d |
| 6.14 | 7.1.5 | 4257f45ee1fd |
| 6.14 | 7.2 | b34826e55aad |
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 bug is reached only through binder IPC via ioctl(BINDER_WRITE_READ) on /dev/binder or binderfs with BC_TRANSACTION/BC_TRANSACTION_SG, requiring local access to the binder device; there is no network, Bluetooth, or physical bus path to binder_transaction().
- AC:LAttack complexity, low
- This is a deterministic logic error, not a race: on every transaction to a txn_security_ctx node, security_release_secctx() zeroes lsmctx.len before sg_buf_end_offset is computed, so the attacker reliably gains extra scatter-gather space by crafting BINDER_TYPE_PTR objects.
- PR:LPrivileges required, low
- binder_open() has no capability check; on Android any untrusted_app can open /dev/binder and send transactions, and on other systems binderfs is mountable from user namespaces, so only basic local user access is required—not real root.
- UI:NUser interaction, none
- Exploitation is driven entirely by the attacker's own binder client sending a crafted transaction; no victim user action such as opening a file, mounting a filesystem, or approving a prompt is required.
- S:UScope, unchanged
- Impact is overwriting kernel-managed LSM security context data within a binder transaction buffer to spoof caller identity for privilege escalation; this is standard local kernel/Android sandbox bypass, not a VM, hypervisor, or IOMMU boundary crossing.
- C:HConfidentiality impact, high
- The inflated sg_buf_end_offset permits scatter-gather copies to overwrite the kernel-written secctx region—an out-of-bounds write relative to the intended SG boundary that can forge sender SELinux labels seen by privileged receivers, enabling unauthorized data access.
- I:HIntegrity impact, high
- Attacker-controlled user data from BINDER_TYPE_PTR copies overwrite the kernel-placed LSM security context string in the transaction buffer, directly corrupting integrity of trusted caller-identity metadata used for authorization decisions by privileged binder services.
- A:HAvailability impact, high
- Kernel transaction-buffer corruption delivered to privileged Android framework/system services can crash critical binder receivers or destabilize the device; per kernel CVSS guidance, out-of-bounds writes and memory corruption in kernel IPC paths warrant High availability impact.