CVE-2026-89761

In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix out-of-bounds write when null terminating a label vec

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().