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

selinux: reject a permission value exceeding the class permission count

perm read() bounds a permission value by SEL VEC MAX but never by the nprim of the owning class or common, which is taken verbatim from the policy image. security get permissions() then writes perms[value - 1] into an nprim-sized kcalloc() array, so a class declaring fewer permissions than its largest permission value drives an out-of-bounds heap write. The top-level symbol tables are validated this way; the nested per-class permission table is not.

Reject a permission whose value exceeds nprim, which is already set when perm read() runs. Well-formed policies are unaffected.

[PM: tweak comment for line length]