CVE-2026-46104

What it actually does

This is a Linux kernel SELinux flaw in socket permission checks when Linux Security Modules are stacked. The affected helpers directly dereference sk->sk_security and incorrectly assume the SELinux socket security blob is located at offset zero. In configurations where another LSM allocates socket blob storage before SELinux, the kernel may read the wrong security blob and pass invalid security identifiers or object class values into SELinux AVC permission checks. The most likely impact is local denial of service through incorrect access-control decisions, kernel warnings, instability, or crashes during socket or netlink permission handling. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Systems running affected Linux kernel versions with SELinux and stacked LSM configurations may be exposed to local availability disruption. A low-privileged local user or compromised workload could potentially trigger kernel instability or service interruption, which may affect multi-user servers, container hosts, CI/CD runners, and shared compute platforms. The EPSS score is very low and there is no known KEV listing or known ransomware association, so broad active exploitation is not currently indicated; however, kernel availability bugs should still be prioritized for systems that allow untrusted local code execution.

How an attack unfolds

An attacker first needs local code execution with low privileges on an affected Linux system. The system must use SELinux in a stacked LSM configuration where SELinux is not the first consumer of the socket security blob. The attacker then performs socket or netlink operations that cause SELinux socket permission helpers such as sock_has_perm() or nlmsg_sock_has_extended_perms() to run. Because the vulnerable code reads sk->sk_security directly instead of using the SELinux socket blob accessor, the permission helper may interpret another LSM's blob as SELinux state. That can result in invalid SID or class values being submitted to AVC checks, which may lead to faulty permission handling, kernel warnings, or a crash. There is no public evidence in the provided data of weaponized exploitation, named threat actor use, or ransomware use.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix changing SELinux socket permission helpers to use the proper SELinux socket blob accessor, selinux_sock(), instead of directly dereferencing sk->sk_security. Because no exact fixed package versions were provided, use the security advisory and package metadata from the relevant Linux distribution or kernel vendor to identify the corrected kernel release. Prioritize patching hosts that run SELinux with LSM stacking, shared multi-user systems, container hosts, and systems that execute untrusted local workloads. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workload execution, hardening container isolation, and reviewing whether LSM stacking is required in the current configuration. Avoid disabling SELinux as a primary mitigation unless directed by the vendor and only after assessing the security tradeoff, because doing so may reduce overall system protection.

How to confirm the fix worked

Confirm the running kernel version and compare it with the vendor advisory for the fixed release containing the SELinux socket blob accessor change. Validate that the installed kernel package is the patched version and that the system has rebooted into that kernel, not merely installed it. Review kernel configuration and boot parameters to determine whether SELinux and LSM stacking are enabled. Where source or changelog validation is possible, confirm the fix references replacing direct sk->sk_security access in SELinux socket permission helpers with selinux_sock(). After remediation, monitor kernel logs while exercising normal socket and netlink workloads and confirm there are no recurring SELinux AVC anomalies, kernel oops messages, BUG/WARN traces, or crashes associated with SELinux socket permission paths.

Typical attack path

1. Gain local low-privileged execution on a Linux host, for example through a shell, compromised service account, container escape prerequisite, or untrusted workload execution path.
2. Confirm or assume the host runs an affected Linux kernel with SELinux enabled and LSM stacking configured such that another LSM allocates socket blob storage before SELinux.
3. Trigger socket or netlink activity that reaches SELinux socket permission checks.
4. Cause the vulnerable helper to read the wrong socket security blob through sk->sk_security.
5. Force invalid SELinux SID or class values into AVC checks, potentially causing kernel instability, service disruption, or denial of service.

How to detect it

There are no reliable public indicators of compromise specific to this vulnerability, and exploitation would likely appear as local kernel instability rather than a distinctive network signature. To assess possible prior exploitation, review kernel logs, system journals, audit logs, SELinux AVC logs, and crash dumps from affected hosts. Focus on unexplained crashes, kernel oopses, warnings, or panics around SELinux socket or netlink permission paths, especially on systems using LSM stacking. Useful log sources include journalctl -k output, /var/log/kern.log, /var/log/messages, /var/log/audit/audit.log, kdump/vmcore artifacts, and distribution crash reporting tools. Look for stack traces or warnings referencing sock_has_perm(), nlmsg_sock_has_extended_perms(), SELinux AVC checks, invalid SID/class handling, or sk_security access. Correlate suspicious kernel events with local user sessions, container starts, CI jobs, or processes performing high-volume socket or netlink operations immediately before the crash. Absence of these artifacts does not prove non-exploitation, because a successful denial-of-service trigger may leave limited forensic evidence if the system panics or reboots quickly.

• sock_has_perm
• nlmsg_sock_has_extended_perms
• sk->sk_security
• sk_security
• selinux_sock
• avc: denied
• SELinux:
• kernel: BUG:
• kernel: WARNING:
• kernel: Oops:
• kernel panic
• /var/log/audit/audit.log
• /var/log/kern.log
• /var/log/messages
• /var/crash/
• /var/lib/systemd/coredump/

What your security team should do

• Inventory Linux systems running SELinux, especially those using LSM stacking or hosting untrusted local users, containers, CI jobs, or shared workloads.
• Check distribution vendor advisories for the fixed kernel version and schedule kernel updates with reboot validation.
• Prioritize patching shared compute, container host, and multi-tenant Linux systems over single-purpose systems without local untrusted code execution.
• Monitor kernel logs, audit logs, and crash dumps for SELinux AVC anomalies, kernel warnings, oopses, or panics involving socket or netlink permission checks.
• Restrict local access and untrusted workload execution until patched on high-risk systems.
• Ensure vulnerability scanners and asset inventory tools check the running kernel version, not only the installed package version.
• Because this issue is not KEV-listed and has very low EPSS, treat it as important for exposed local-execution environments but not as evidence of broad internet-scale exploitation.