CVE-2026-43403 Overview
CVE-2026-43403 is a Linux kernel vulnerability in the namespace filesystem (nsfs) subsystem. The flaw resides in the namespace iteration ioctls, which performed insufficient permission checks. Privileged services could observe namespaces belonging to other privileged services, enabling cross-service information leakage on shared hosts. The upstream fix introduces a may_see_all_namespaces() helper that centralizes the policy decision until the namespace tree (nstree) implementation adapts to a more granular model.
Critical Impact
A local authenticated actor with limited privileges can leak information about, and potentially interact with, namespaces owned by other privileged services, undermining container and service isolation boundaries.
Affected Products
- Linux kernel builds containing the nsfs namespace iteration ioctls prior to the upstream fix
- Distributions packaging the affected stable branches referenced in the kernel.org commits
- Container and multi-tenant hosts that rely on namespace isolation between privileged services
Discovery Timeline
- 2026-05-08 - CVE-2026-43403 published to the National Vulnerability Database
- 2026-05-12 - Last updated in the NVD database
Technical Details for CVE-2026-43403
Vulnerability Analysis
The Linux kernel exposes namespace objects through the nsfs pseudo-filesystem. Iteration ioctls on nsfs allow a process to walk available namespaces and obtain references to them. The original implementation gated access primarily on holding sufficient capabilities, without verifying that the caller should be allowed to enumerate namespaces created by other equally privileged contexts.
This design conflates privilege with visibility. Two services running with elevated capabilities in separate containers, sandboxes, or service contexts could enumerate each other's namespaces. That enumeration leaks the existence, identifiers, and structure of peer workloads, and can be a stepping stone to deeper cross-boundary access on the same host. The attack requires local access with low privileges and no user interaction, while exposing confidentiality, integrity, and availability of adjacent workloads.
Root Cause
The root cause is an overly permissive authorization check in the namespace iteration ioctl handlers within nsfs. The code path treated capability ownership as sufficient justification to traverse arbitrary namespaces, omitting a check that the caller has a legitimate relationship to the target namespace. The upstream fix introduces may_see_all_namespaces() as a single policy gate consumed by the iteration paths, restoring the principle that visibility must be earned rather than implied by privilege level.
Attack Vector
Exploitation requires local code execution in a context that holds some capabilities, such as a containerized service running as root inside its own user namespace. The actor invokes the affected nsfs iteration ioctls to enumerate namespaces outside its expected scope. Returned handles can be used to inspect peer service configuration, leak workload metadata, or expand an existing compromise across tenant boundaries on the same kernel. See the patch series via Kernel Git Commit 0ad650e and Kernel Git Commit 3376b34 for the specific code paths affected.
Detection Methods for CVE-2026-43403
Indicators of Compromise
- Unexpected processes opening file descriptors against /proc/*/ns/* entries belonging to workloads outside their assigned namespace scope
- ioctl calls against nsfs file descriptors originating from services that have no legitimate need to enumerate namespaces
- Container runtime audit events showing capability-bearing processes performing namespace discovery operations
Detection Strategies
- Enable Linux audit rules for ioctl syscalls targeting file descriptors backed by nsfs and alert on callers outside an allowlist of orchestration components
- Correlate openat events against /proc/<pid>/ns/ paths with the issuing process identity to surface cross-tenant enumeration attempts
- Use eBPF tracing to instrument the nsfs ioctl entry points and record caller capabilities, target namespace inode, and originating cgroup
Monitoring Recommendations
- Track kernel package versions across the fleet and alert on hosts running builds that predate the patch commits referenced on kernel.org
- Monitor container escape and lateral movement telemetry for sequences that begin with namespace enumeration followed by access to peer service resources
- Baseline which workloads legitimately invoke namespace iteration ioctls and treat deviations as investigation candidates
How to Mitigate CVE-2026-43403
Immediate Actions Required
- Identify hosts running affected Linux kernel versions and prioritize multi-tenant systems, container hosts, and shared service infrastructure
- Apply the upstream stable kernel updates that include the may_see_all_namespaces() helper introduced by the referenced commits
- Audit which local services hold capabilities such as CAP_SYS_ADMIN and reduce the capability surface where the service does not require it
Patch Information
The fix is delivered as a series of upstream Linux kernel commits. Reference Kernel Git Commit 0ad650e, Kernel Git Commit 2f3dea2, Kernel Git Commit 3376b34, and Kernel Git Commit e6b899f. Rebuild custom kernels against these patches or install the distribution package that includes them.
Workarounds
- Drop unnecessary capabilities from container and service profiles using seccomp and capability bounding sets to limit access to namespace iteration ioctls
- Constrain workloads with user namespaces so that privileged processes operate inside an isolated UID range rather than the host root namespace
- Restrict access to nsfs ioctl paths through Linux Security Modules such as SELinux or AppArmor policies that deny non-orchestration services from invoking namespace traversal operations
# Example: drop namespace-related capabilities from a systemd service
# /etc/systemd/system/example.service.d/hardening.conf
[Service]
CapabilityBoundingSet=~CAP_SYS_ADMIN CAP_SYS_PTRACE
NoNewPrivileges=yes
RestrictNamespaces=yes
PrivateMounts=yes
ProtectKernelTunables=yes
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


