HIGH Introduced in 7.0
apparmor VerifyTags OOB
CVE-2026-90246
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
KernelScan AI7.1HIGH
01Description
In the Linux kernel, the following vulnerability has been resolved: apparmor: fix integer overflow in verify_tags() bounds check verify_tags() validates the tagset table unpacked from a policy blob. For each set it reads a count and checks that advancing the index by that count stays inside sets.table[]: u32 cnt = tags->sets.table[i]; if (i+cnt >= tags->sets.size) { i, cnt and sets.size are all u32, so i+cnt is evaluated modulo 2^32. sets.table[] is filled by unpack_tagsets() with aa_unpack_u32(), so every entry is a raw unbounded 32-bit word taken from the policy blob, and verify_tags() is the function that is supposed to validate it. A count close to U32_MAX makes the sum wrap to a small value, the guard passes, and the inner loop then walks sets.table[++i] past the end of the kcalloc(size, sizeof(u32)) allocation. Note that sets.size is bounded by 65535, because unpack_tagsets() reads it with aa_unpack_array() as a u16, so the wrap cannot be reached by growing the table; it is reached purely through the attacker-supplied count. With sets.size = 2 and sets.table = { 0, 0xffffffff }: i = 0: cnt = 0, guard 0 + 0 >= 2 is false, inner loop does not run i = 1: cnt = 0xffffffff, guard (1 + 0xffffffff) mod 2^32 == 0 >= 2 is false, so the guard is bypassed and the inner loop reads sets.table[2] -- one element past a two element allocation The walk continues until an out-of-bounds value happens to be >= hdrs.size or the access faults, so a crafted policy yields an out-of-bounds read on the policy load path (aa_replace_profiles -> aa_unpack -> unpack_policydb -> unpack_tags -> verify_tags). unpack_tags() runs before the perms and DFA tables are unpacked, so no other table needs to be well formed to reach it. Policy load is gated by aa_may_manage_policy(), which checks CAP_MAC_ADMIN relative to the subject's own user namespace rather than the init user namespace, so with the default unprivileged_userns_apparmor_policy=1 the path is reachable from an unprivileged task in a matched-level nested namespace, not only by a globally privileged one. Perform the addition in u64 so that it cannot wrap, restoring the intended i + cnt < sets.size guarantee.
02KernelScan AI Analysis
Risk summary
An unprivileged local user who can create a user namespace can load a crafted AppArmor policy that triggers an unbounded out-of-bounds heap read in the kernel. This can leak kernel memory contents or crash the kernel. Systems that restrict unprivileged user namespaces are not exposed to this attack path.
Vulnerability analysis
AppArmor's policy tag validator reads an attacker-supplied 32-bit count from the policy blob and adds it to a loop index to check whether the walk stays inside a heap-allocated array. Because both values are unsigned 32-bit, a count near the maximum causes the sum to wrap to a small number, the bounds check passes, and the validator reads past the end of the allocation until it hits a stop condition or faults. The fix performs the addition in 64-bit arithmetic so the sum cannot wrap, restoring the intended bounds guarantee. The vulnerable path is the AppArmor policy load, which requires CAP_MAC_ADMIN; with the default unprivileged user-namespace AppArmor policy setting, an unprivileged local task in a nested user namespace can obtain that capability and trigger the bug with a crafted policy blob, requiring no special hardware or configuration beyond AppArmor being enabled.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| mainline | 7.0 | 7.3-rc1 | 465946d3c560 |
| 7.2 | 7.0 | 7.2.6 | ef79a405f839 |