Look up another CVE · open CVE-2026-89761 in the interactive tracker
CVE-2026-89761
apparmor: fix out-of-bounds write when null terminating a label vec
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem security/apparmor. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89761 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
aa_vec_unique() null terminates at vec[n - dups] when VEC_FLAG_TERMINATE is passed. If the components are all distinct no duplicates are dropped, dups is 0 and the terminator goes to vec[n], so the caller has to provide room for n + 1 entries. aa_label_strn_parse() sets up its vector with vec_setup(profile, vec, len, gfp) and then calls aa_vec_unique(vec, len, VEC_FLAG_TERMINATE), but vec_setup() does not reserve the terminator entry. Up to LOCAL_VEC_ENTRIES it uses the local array of LOCAL_VEC_ENTRIES pointers, above that it allocates exactly len pointers. The terminator therefore lands one entry past the end of the local array when len is LOCAL_VEC_ENTRIES, and one entry past the end of the allocation when len is larger. len comes from the number of "//&" separated components in the label name and label_count_strn_entries() does not bound it. An unprivileged task reaches the parse by writing to /proc/self/attr/apparmor/current or through lsm_set_self_attr(2), both of which go through do_setattr(), and the name is parsed before the change_profile permission is checked. The query_label() path behind the securityfs .access file, which is mode 0666, performs no permission check at all. Every component has to resolve to a loaded profile, so a system with policy loaded is required. The other two VEC_FLAG_TERMINATE users work on a label vec that aa_label_alloc() has already sized with "+ 1 for null terminator entry on vec". Reserve the same entry in vec_setup() and DEFINE_VEC(). Passing len + 1 from the caller instead would move len == LOCAL_VEC_ENTRIES out of the local array and into kzalloc().
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.
security/apparmor/include/label.h
- What this is
- APPARMOR SECURITY MODULEMAINTAINERS section matched on security/apparmor/ · apparmor@lists.ubuntu.com · Supported
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid, bookworm · linux-6.12?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
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
Signals
- Published
- 2026-09-11 (37 days 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.12%, higher than 1.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- security/apparmor
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.13 | 6.12.109 | 9124e078ea22 |
| 4.13 | 6.18.50 | 28069434aef6 |
| 4.13 | 7.2.4 | 36bdd0b45ec3 |
| 4.13 | 7.3 | 9f1e40193eef |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-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
- An unprivileged local process reaches aa_label_strn_parse() by writing a compound label to /sys/kernel/security/apparmor/.access (mode 0666) via query_label()/query_data(), or via /proc/self/attr/apparmor/current and lsm_set_self_attr(2) through do_setattr(); there is no network-facing path.
- AC:LAttack complexity, low
- The attacker fully controls the "//&"-separated label string and thus the vector length; when at least eight distinct profiles are loaded (typical Ubuntu/Debian/SUSE policy, or attacker-loaded via user namespaces) with no duplicates, aa_vec_unique() deterministically writes NULL one pointer past the stack array or heap allocation, with no race.
- PR:LPrivileges required, low
- query_label() on the world-writable .access file performs no capability or change_profile check, and do_setattr() parses the name before AA_MAY_CHANGE_PROFILE is tested, so a basic unprivileged local user suffices; real root is not required.
- UI:NUser interaction, none
- The attacker opens and writes the .access query or their own procattr themselves; no victim action such as mounting a filesystem or opening a file is required.
- S:UScope, unchanged
- The out-of-bounds write corrupts kernel stack or heap within the same kernel security authority. This is standard local privilege-escalation impact, not a VM escape or IOMMU/sandbox boundary crossing.
- C:HConfidentiality impact, high
- The one-pointer out-of-bounds write lands in adjacent stack locals or the next kmalloc object. With attacker-chosen allocation size (component count) for heap grooming, that corruption can be leveraged as a kernel memory-disclosure primitive, so confidentiality impact is high.
- I:HIntegrity impact, high
- aa_vec_unique() writes a NULL pointer one slot past a LOCAL_VEC_ENTRIES stack array or a heap buffer sized exactly to the attacker-chosen component count. An out-of-bounds write that corrupts adjacent kernel objects is a write primitive suitable for control-flow hijacking.
- A:HAvailability impact, high
- Corrupting an adjacent stack pointer, heap object, or stack canary can oops, panic, or hang the kernel; the unexploited NULL write alone is sufficient for denial of service.