CVE-2026-80912 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
selinux: reject an unclaimed class value in security_get_classes()
security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate.
Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/04/2026
The Linux Security Modules framework, specifically SELinux, relies on a complex policy database to enforce mandatory access controls across the operating system. A critical flaw was identified within the security_get_classes() function, which is responsible for retrieving the list of defined security classes from the loaded policy. The underlying data structure used by SELinux allows for sparse class identifiers, meaning that not every integer value in the potential range corresponds to an actual defined class. This sparsity is normally handled by validation functions such as policydb_class_isvalid(), which ensure that only legitimate, declared classes are processed during standard operations. However, security_get_classes() bypasses this safety mechanism when constructing its internal array representation of these classes for user-space consumption or further kernel processing.
The technical root cause lies in how the function allocates and populates an array based on p_classes.nprim, which represents the highest class identifier value rather than the count of defined classes. The implementation iterates through this range and fills entries at index value minus one. When a particular integer within this range does not correspond to a declared security class in the policy database, the corresponding slot remains uninitialized or null. This creates an array containing NULL pointers interspersed with valid class structures. Subsequently, sel_make_classes() processes every entry in this newly built array and passes each element to sel_make_dir(), which ultimately invokes d_alloc_name(). Because d_alloc_name expects a valid string pointer for directory name allocation, passing it a NULL pointer results in an invalid memory dereference.
This vulnerability can lead to a kernel panic or system crash if triggered by local users with appropriate privileges to query security classes. The operational impact is significant as it compromises the stability and availability of systems running SELinux. An attacker who can induce this code path may cause denial-of-service conditions, disrupting critical services that depend on continuous system uptime. While conforming policies that strictly define every class they declare are unaffected by this flaw due to their dense nature, non-conforming or legacy policies with gaps in class identifiers remain vulnerable. The absence of a validity check before array population means any policy deviation from strict density can trigger the NULL pointer dereference during routine security module operations.
Mitigation strategies involve applying kernel patches that update selinux_get_classes() to validate each class identifier against the policy database before adding it to the output array. This ensures that only valid, declared classes are included in the returned list, preventing the creation of arrays with null entries. Administrators should ensure their SELinux policies adhere strictly to best practices by avoiding sparse definitions where possible and keeping kernel versions up to date to receive these security fixes. From a classification perspective, this issue aligns with CWE-476, which denotes NULL Pointer Dereference vulnerabilities arising from improper handling of uninitialized or null values in data structures. In the context of attack techniques, it relates to ATT&CK T1053 Scheduled Task/Job, as local privilege escalation often involves manipulating system processes that may trigger such kernel-level faults during security audits or policy reloads.