Re: [PATCH] selinux: reject a permission value exceeding the class permission count

[Bryam Vargas]

On Fri, 24 Jul 2026 11:56:11 -0400, Stephen Smalley wrote:
> Also wondering to what extent this may overlap with this series that
> was never fully merged:
> https://lore.kernel.org/selinux/20250511173055.406906-15-cgoettsche@xxxxxxxxxxxxx/

Little concrete overlap. I went through the v3 "harden against malformed
policies" series: patch 3 adds the value > SEL_VEC_MAX, nel, U16_MAX-class and
default-* enum bounds (my hunk sits on top of its perm_read value > SEL_VEC_MAX
check, already in mainline), and later patches bound the top-level symbol values
against the symtab counts. None of the 14 patches bounds a permission value
against the owning class/common nprim or touches security_get_permissions(), so
the OOB this patch closes isn't covered there. Happy to coordinate with Christian
(on Cc) so this and a revived series don't collide.

The review is right that this is incomplete. A class that inherits a common maps
the common's permissions into an array sized by the class's own nprim
(security_get_permissions() -> get_permissions_callback(), perms[value - 1]),
and nothing checks the class nprim covers the common; perm_read() doesn't catch
it because the common's values are bounded against the common's nprim. v2 adds a
class_read() check rejecting permissions.nprim < comdatum->permissions.nprim,
with the A/B for that trigger. The sparse-value NULL deref in
sel_make_perm_files() is separate -- I can fold it into the series or post it on
its own, whichever you prefer.

Correct on CAP_MAC_ADMIN too: the precondition is the load_policy permission
plus DAC write to /sys/fs/selinux/load, not the capability. That line was below
the --- so it never entered the commit message.

Thanks for the ack.

Bryam