CVE-2026-80757 in Linux
Summary
by MITRE • 09/03/2026
In the Linux kernel, the following vulnerability has been resolved:
selinux: reject a class permission count below its inherited common
security_get_permissions() maps an inherited common's permissions into an array sized by the class's own permissions.nprim, but class_read() takes that nprim verbatim from the policy image and never checks that it covers the common. A class that inherits a common of N permissions while declaring a smaller nprim is accepted, and on load the common's permissions are written past the class-sized array -- an out-of-bounds heap write.
Reject a class whose permission count is below its inherited common's. Well-formed policies, where the class count already includes the inherited permissions, are unaffected.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The Linux Security Modules (LSM) framework provides a mandatory access control mechanism through SELinux, which relies on policy objects to define security rules for system resources. A critical vulnerability exists within the selinux subsystem during the processing of class definitions in the loaded policy image. Specifically, the function security_get_permissions is responsible for mapping inherited common permissions into an array sized according to the specific number of permissions declared for a given class object. This operation assumes that the count of permissions associated with the class itself is sufficient to accommodate not only its own unique permissions but also those inherited from parent classes or commons. However, the validation logic within class_read fails to verify this relationship before proceeding with memory allocation and data copying operations.
The technical flaw arises because class_read accepts the permission count directly from the policy image without verifying that it encompasses all inherited common permissions. When a malformed policy defines a class with an nprim value smaller than the number of permissions in its inherited commons, the subsequent call to security_get_permissions allocates a buffer based on this insufficient size. Consequently, when the system attempts to write the full set of inherited and specific permissions into this undersized array, it results in an out-of-bounds heap write. This memory corruption allows data intended for one part of the SELinux policy structure to overwrite adjacent memory regions, potentially corrupting kernel data structures or enabling arbitrary code execution if the attacker can control the content of the malformed policy file used during loading.
From a threat modeling perspective, this vulnerability is classified under CWE-787: Out-of-bounds Write, as it involves writing data beyond the allocated buffer boundary in heap memory. In terms of attack vectors and techniques, this aligns with ATT&CK technique T1059: Command and Scripting Interpreter if an attacker can inject a malicious policy file into the system loading process, or more broadly under privilege escalation paths where kernel memory corruption leads to gaining higher privileges. The impact is severe because it compromises the integrity of the SELinux subsystem itself, potentially allowing bypasses of mandatory access controls that are critical for maintaining system security boundaries in multi-tenant environments or hardened systems.
Mitigation strategies primarily involve ensuring that only well-formed and validated policy files are loaded into the kernel. Administrators should utilize updated versions of the selinux-utils package where this validation check has been implemented to reject classes with insufficient permission counts relative to their inherited commons. For organizations unable to immediately patch, restricting access to tools like semodule or setfiles to trusted users reduces the risk of exploitation by unprivileged actors who might attempt to load a crafted policy file designed to trigger the heap overflow. Regular auditing of SELinux policies and keeping kernel packages up to date are essential practices to maintain the integrity of mandatory access control mechanisms against such memory corruption vulnerabilities.