CVE-2026-46150

What it actually does

This Linux kernel flaw affects fanotify permission events. Under specific mark-handling conditions, fsnotify_get_mark_safe() can incorrectly return false for a mark belonging to an unrelated notification group. That false result can cause the kernel to skip or bypass a fanotify-based permission check that should have been enforced. Because fanotify is commonly used by security, monitoring, and access-control tooling to mediate file access, the technical result is a local authorization bypass: a low-privileged local user may access or modify files in ways that a fanotify permission policy was intended to block. The CVSS vector indicates local access is required, exploitation complexity is low, user interaction is not required, and confidentiality and integrity impact may be high, with no direct availability impact.

Why it matters to the business

Organizations relying on Linux fanotify-based controls for file access enforcement, malware scanning, data loss prevention, sandboxing, or security monitoring may have those controls silently bypassed on affected kernels. The likely consequence is unauthorized local access to sensitive files, unauthorized modification of protected content, or failure of endpoint security controls to block risky file operations. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has very low EPSS probability with no public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, the risk is higher on multi-user Linux systems, shared compute platforms, developer workstations, container hosts, and servers where untrusted or semi-trusted local users can execute code.

How an attack unfolds

An attacker first needs local code execution with low privileges on an affected Linux system. They then perform file operations that interact with fanotify permission events while the kernel is managing multiple fsnotify or fanotify marks, including detached marks not associated with the current notification group. By triggering the vulnerable mark-handling path, the kernel can incorrectly treat a relevant permission event as though no applicable mark requires enforcement. As a result, the file operation proceeds without the expected fanotify permission decision. If a security product, access-control daemon, or monitoring service depends on fanotify permission events to approve or deny access, the attacker may read protected data or alter files that should have been blocked. There are no named threat actors or active exploitation campaigns reported in the supplied intelligence.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the fanotify detached-mark handling issue. No exact fixed package versions were provided in the input, so use the fixed kernel packages published by the operating system or distribution vendor for this vulnerability. Prioritize systems that allow local shell access, run untrusted workloads, support multiple users, host containers, or rely on fanotify-based security controls. If immediate patching is not possible, reduce exposure by limiting local interactive access, restricting execution of untrusted code, isolating workloads, reviewing reliance on fanotify permission enforcement for high-value files, and applying compensating controls such as discretionary access controls, mandatory access controls, file integrity monitoring, and least-privilege filesystem permissions.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version and package changelog against the Linux distribution advisory that includes the fanotify fix. Ensure the system has rebooted into the fixed kernel after package installation; merely installing the package is insufficient if the vulnerable kernel is still running. Validate that fanotify-dependent security tooling continues to receive and enforce permission events by running controlled allow/deny file-access tests for protected paths. For exposure assessment, inventory Linux hosts by kernel version and distribution patch level, then map systems that use fanotify-based controls such as endpoint security agents, malware scanners, DLP tools, file access brokers, or custom fanotify daemons.

Typical attack path

1. Obtain local access to an affected Linux system using a low-privileged account or already-running local process.
2. Identify or infer that fanotify permission events are being used for file access control, scanning, sandboxing, or policy enforcement.
3. Trigger file operations under conditions involving multiple fsnotify/fanotify marks, including marks detached from unrelated groups.
4. Cause fsnotify_get_mark_safe() to return false for an unrelated detached mark, leading the kernel to skip the intended permission check.
5. Access or modify files that the fanotify-based policy should have denied.
6. Use the unauthorized file access to collect sensitive data, tamper with application files, bypass endpoint controls, or support further local privilege or lateral movement activity.

How to detect it

This issue is a kernel authorization bypass and may not leave a unique exploit signature. Detection should focus on evidence of suspicious local file access that should have been denied by fanotify-based controls, missing or inconsistent fanotify permission-denial events, and abnormal behavior from software that depends on fanotify. Review auditd logs, Linux Security Module logs such as SELinux or AppArmor, endpoint security telemetry, file integrity monitoring events, EDR process/file telemetry, syslog or journald records for fanotify-based agents, and application logs for unexpected reads or writes to protected files. Look for low-privileged users or service accounts accessing sensitive paths shortly before or after expected security tooling failed to log a corresponding allow/deny decision. If fanotify-based security products are deployed, compare their policy logs against kernel audit records to find file operations that occurred without the expected permission event. Because there are no supplied public exploit indicators, no named threat actors, and no KEV listing, detection should be behavior-based rather than IOC-based.

What your security team should do

• Inventory Linux systems and identify those running affected kernel builds, especially multi-user servers, container hosts, shared development systems, and systems executing untrusted local code.
• Prioritize kernel updates from the relevant Linux distribution vendor and reboot systems into the fixed kernel.
• Give higher remediation priority to hosts where fanotify is used for security enforcement, malware scanning, DLP, sandboxing, or access-control decisions.
• Until patched, restrict local account access, reduce the ability to run arbitrary code, and harden filesystem permissions around sensitive data.
• Do not rely on fanotify permission controls as the sole protection for high-value files on unpatched systems; layer with MAC policies such as SELinux or AppArmor where appropriate.
• Run post-patch validation tests to confirm fanotify permission events are still generated and enforced as expected.
• Monitor for suspicious local file access or modification attempts against paths protected by fanotify-based controls, particularly by low-privileged users or service accounts.