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

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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(). (CVE-2026-89761)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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(). (CVE-2026-89761)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
475487	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Cloud Security	Google COS Security Checks	Local	high
475487	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	high
475030	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_6, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_6, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_6, sys-kernel/lakitu-vgpu-kernel-6_6: security update to 19216.700.7	Tenable Cloud Security	Google COS Security Checks	Local	high
475030	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_6, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_6, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_6, sys-kernel/lakitu-vgpu-kernel-6_6: security update to 19216.700.7	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	high
362907	Debian dla-4817 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
468988	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/csql-kernel-6_12, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_12: security update to 19506.505.8	Tenable Cloud Security	Google COS Security Checks	Local	high
468988	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/csql-kernel-6_12, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_12: security update to 19506.505.8	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	high
351155	Debian dsa-6528 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
345410	Linux Distros Unpatched Vulnerability : CVE-2026-89761	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-89761

high

Tenable Plugins

high

high

high

high

high

high

high

high

high