CVE-2026-46302

What it actually does

This Linux kernel SELinux flaw allows a local process to monopolize access to /sys/fs/selinux/policy by opening it and keeping it open. Because the kernel previously permitted only one open of that policy interface at a time, other processes attempting to read the active SELinux policy could be blocked. The impact is denial of service against SELinux policy readers and tooling rather than code execution, privilege escalation, or data theft. The kernel fix removes the single-open restriction and reduces mutex hold time so multiple readers can access the policy interface safely.

Why it matters to the business

Systems relying on SELinux management, monitoring, compliance collection, or policy-inspection tools may experience failures or hangs if an untrusted local process deliberately holds /sys/fs/selinux/policy open. This can disrupt security operations, compliance reporting, troubleshooting workflows, and automated controls that need to read the active SELinux policy. The practical risk is lower than remotely exploitable kernel vulnerabilities because exploitation requires local code execution and current EPSS is very low, with no known KEV listing or ransomware association.

How an attack unfolds

An attacker first needs the ability to run a process on a Linux system where SELinux is enabled and the vulnerable kernel behavior is present. The attacker opens /sys/fs/selinux/policy and keeps the file descriptor open for an extended period. Because the vulnerable implementation allows only a single open at a time, legitimate SELinux-aware tools, scanners, compliance agents, or administrators attempting to read the kernel policy are blocked or fail. The attacker can maintain this condition by leaving the process running, restarting it, or automating repeated opens, causing persistent disruption to policy inspection without needing elevated privileges if the policy file is otherwise readable in that context.

How to fix it

Upgrade to a Linux kernel version that includes the SELinux change allowing multiple opens of /sys/fs/selinux/policy. Because no specific distribution packages or fixed versions were provided, use vendor advisories for the relevant Linux distribution and kernel stream, and apply the security update once available. Reboot into the fixed kernel after installation. As temporary mitigation, restrict untrusted local code execution, investigate and terminate suspicious processes holding /sys/fs/selinux/policy open, and monitor for abnormal long-lived file descriptors referencing that path. Containerized workloads should also be reviewed where host SELinux filesystem paths are exposed into containers.

How to confirm the fix worked

Confirm the host is running a vendor kernel that includes the fix for the SELinux policy open behavior. Validate by checking the active kernel version after reboot with standard OS tooling and comparing it against the distribution’s security advisory. Operationally, test that multiple concurrent reads of /sys/fs/selinux/policy can occur without blocking each other. Also verify that SELinux management, audit, compliance, and monitoring tools can read policy information normally after the update.

Typical attack path

1. Gain local execution on a vulnerable Linux host, such as through a shell, compromised service account, scheduled job, or low-privileged user session.
2. Confirm SELinux is present and /sys/fs/selinux/policy exists.
3. Open /sys/fs/selinux/policy from a process and keep the file descriptor open.
4. Hold the process open to prevent other processes from reading the SELinux policy.
5. Optionally restart or supervise the process to maintain the denial-of-service condition if it is killed.
6. Cause SELinux management, audit, compliance, or monitoring tools that read the active policy to hang, fail, or produce incomplete results.

How to detect it

Look for evidence of local processes holding /sys/fs/selinux/policy open for unusual durations. Useful sources include auditd logs, process accounting, EDR telemetry, shell history, systemd service definitions, cron entries, container runtime logs, and live forensic collection using lsof or /proc file descriptor inspection. Search for commands or scripts that repeatedly open or read /sys/fs/selinux/policy and remain running. Investigate SELinux management or compliance tool errors that coincide with a process maintaining an open descriptor to the policy file. On live systems, enumerate open file handles with lsof /sys/fs/selinux/policy or by searching /proc/*/fd symlinks for that path, then correlate the owning process, user, parent process, command line, and start time. There are no public threat actors or campaigns reported for this vulnerability in the provided data.

• /sys/fs/selinux/policy
• lsof /sys/fs/selinux/policy
• /proc/*/fd/* -> /sys/fs/selinux/policy
• cat /sys/fs/selinux/policy
• dd if=/sys/fs/selinux/policy
• open("/sys/fs/selinux/policy"
• openat(AT_FDCWD, "/sys/fs/selinux/policy"

What your security team should do

• Prioritize patching Linux systems where SELinux is enabled and where untrusted users, workloads, containers, or third-party agents can execute local code.
• Track distribution-specific kernel advisories and fixed package versions, then reboot systems into the corrected kernel after updating.
• Add monitoring for long-lived processes with open file descriptors to /sys/fs/selinux/policy, especially from unexpected users or application contexts.
• Review container and sandbox configurations to avoid exposing /sys/fs/selinux/policy to workloads that do not require it.
• Investigate recurring failures or hangs in SELinux policy inspection, compliance scans, or security agents as potential exploitation or abuse.
• Because EPSS is low and there is no KEV or known ransomware association, handle through normal kernel patch cycles unless local multi-user exposure or security-tool disruption risk is high.