MEDIUM 5.5

CVE-2026-46302: Linux SELinux Policy File Lock Denial-of-Service Vulnerability

A Linux kernel vulnerability allows a single process to monopolize read access to the SELinux security policy file, preventing other processes from retrieving critical security configuration. This denial-of-service condition stems from an overly restrictive locking mechanism that was originally intended to prevent memory exhaustion and inconsistent policy views, but achieves neither goal effectively. The issue is resolved by allowing concurrent reads of the policy file while maintaining data integrity through refined locking.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.5 MEDIUM · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
Affected products
3 configuration(s)
Published / Modified
2026-06-08 / 2026-07-08

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: selinux: allow multiple opens of /sys/fs/selinux/policy Currently there can only be a single open of /sys/fs/selinux/policy at any time. This allows any process to block any other process from reading the kernel policy. The original motivation seems to have been a mix of preventing an inconsistent view of the policy size and preventing userspace from allocating kernel memory without bound, but this is arguably equally bad. Eliminate the policy_opened flag and shrink the critical section that the policy mutex is held. While we are making changes here, drop a couple of extraneous BUG_ONs.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-46302 addresses a concurrency control flaw in the SELinux subsystem's policy interface at /sys/fs/selinux/policy. The kernel previously enforced a single-open-at-a-time restriction via a policy_opened flag, causing subsequent open attempts to block until the file was closed. This creates a trivial denial-of-service vector: any unprivileged local process can open the policy file and hold it indefinitely, starving other processes—including security management tools and audit daemons—of access to the kernel's active SELinux policy. The fix eliminates the policy_opened flag and refines mutex scoping, allowing multiple concurrent readers while protecting against unbounded memory allocation through alternative mechanisms.

Business impact

Organizations relying on SELinux for mandatory access control enforcement face operational disruption if unprivileged users can block policy introspection. Security monitoring tools, policy auditing software, and compliance verification utilities may fail silently or timeout when unable to read the active policy. In environments where SELinux policies are dynamically managed or frequently validated, this vulnerability can degrade defensive posture by preventing real-time policy verification and potentially masking unauthorized policy changes. The impact is particularly acute in containerized and multi-tenant systems where workload isolation depends on SELinux enforcement validation.

Affected systems

The vulnerability affects Linux kernel systems with SELinux enabled and accessible through the unprivileged /sys/fs/selinux/policy interface. This includes RHEL, CentOS, Ubuntu, Debian, and other distributions shipping SELinux-enabled kernels. Affected versions span the kernel mainline until resolution. Systems without SELinux compiled or enabled are unaffected. The vulnerability is exploitable by any local user account (UID > 0) with access to the filesystem.

Exploitability

Exploitation requires only local access and the ability to open a file, making it trivial to execute. No special privileges, kernel knowledge, or race conditions are necessary. An unprivileged process executing `open("/sys/fs/selinux/policy", O_RDONLY)` and holding the file descriptor will immediately block all other readers. The attack is completely reliable and can be sustained indefinitely or triggered repeatedly to cause transient denial-of-service against dependent applications. CVSS 5.5 reflects local-only access and availability impact without confidentiality or integrity compromise.

Remediation

Remediation requires patching the Linux kernel to incorporate the fix that removes the policy_opened flag and refines policy mutex scoping. Systems should be updated to kernel versions containing the upstream resolution. Administrators should verify their kernel version against the vendor advisory and plan updates through standard patch management cycles. Until patched, mitigation is limited to restricting filesystem access via LSM policies or strict user account isolation, though these do not fully prevent exploitation by authorized local users.

Patch guidance

Verify your kernel version and distribution against the vendor advisory from your Linux distribution (Red Hat, Canonical, Debian, etc.). The fix resolves the issue by allowing concurrent access to /sys/fs/selinux/policy while maintaining safety through refined locking. Apply kernel updates according to your organization's change management policy. Test in non-production environments to verify SELinux policy auditing tools and security monitoring continue functioning normally post-patch. Restart affected services or systems as required by your distribution's update mechanism.

Detection guidance

Monitor for repeated failed open or read attempts on /sys/fs/selinux/policy from unexpected processes. Audit filesystem access logs for sustained open file descriptors on this path. Track process behavior that prevents policy inspection—such as security tools timing out when attempting policy verification. Implement file access monitoring for /sys/fs/selinux/policy via auditd rules: `auditd -w /sys/fs/selinux/policy -p r`. Alert on sequences of concurrent reader failures or permission denied errors when legitimate processes attempt policy access. In containerized environments, monitor for suspicious process activity within workloads targeting filesystem objects in /sys/fs/selinux/.

Why prioritize this

This vulnerability should be prioritized moderately-to-high in SELinux-dependent environments. While exploitability is trivial and requires only local access, the impact on security operations is direct: blocking policy introspection prevents validation of security controls and can mask malicious SELinux policy modifications. Organizations using SELinux for container isolation, multi-tenant enforcement, or compliance-critical access control should prioritize patching. Conversely, systems where SELinux is optional or infrequently accessed can defer patching to standard maintenance windows.

Risk score, explained

The CVSS 5.5 MEDIUM severity reflects a local attack vector (AV:L) with low complexity (AC:L), unprivileged access (PR:L), no user interaction (UI:N), and unchanged scope (S:U). The score captures high availability impact (A:H) from denial-of-service, while acknowledging no direct confidentiality or integrity breach. The score appropriately underweights the operational risk in security-critical deployments; context-specific risk assessments should consider reliance on SELinux policy auditability and the ease of sustained exploitation.

Frequently asked questions

Can a malicious user or container break SELinux enforcement with this vulnerability?

No. This vulnerability prevents reading the policy, not modifying it or bypassing enforcement. SELinux access controls remain active. The impact is operational—preventing policy inspection and auditing—not a direct security control bypass.

Do I need to patch immediately if I'm not using SELinux?

No. Systems without SELinux compiled into the kernel or with SELinux disabled are unaffected. Verify your configuration with `getenforce` or `sestatus` before prioritizing this patch.

What tools are most likely to be disrupted by this vulnerability?

Policy auditing utilities, compliance scanners, security monitoring agents, and container orchestration platforms that validate SELinux enforcement may experience timeouts or failures when attempting to read /sys/fs/selinux/policy. Tools that periodically verify active policy should be tested post-patch.

Can this be exploited over the network?

No. The vulnerability requires local filesystem access and is not remotely exploitable. It is relevant only to local privilege escalation or denial-of-service scenarios involving unprivileged local users.

This analysis is for informational purposes only and does not constitute legal, compliance, or professional security advice. Organizations must independently verify vulnerability applicability to their systems, confirm patch availability through official vendor sources, and conduct internal risk assessments before deploying mitigations. CVSS scores are derived from the Common Vulnerability Scoring System and do not account for context-specific organizational risk factors. No exploit code or weaponized proof-of-concept is provided. Consult official vendor advisories and your security team before taking remedial action. Source: NVD (public-domain), retrieved 2026-07-16. Analysis generated by SEC.co (claude-haiku-4-5).