CVE-2026-72127 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
netdev-genl: report NAPI thread PID in the caller's pid namespace
netdev_nl_napi_fill_one() reports the NAPI kthread PID in NETDEV_A_NAPI_PID using task_pid_nr(), which returns the PID in the initial pid namespace.
NETDEV_CMD_NAPI_GET does not have GENL_ADMIN_PERM and the netdev genl family is netnsok, so a caller in a child pid namespace can issue it. That caller then sees the kthread's global PID, even though the kthread is not visible in its pid namespace, where the value should be 0.
Translate the PID through the caller's pid namespace, the same way commit 3799c2570982 ("io_uring/fdinfo: translate SqThread PID through caller's pid_ns") did for the io_uring SQPOLL thread. The doit and dumpit paths both run synchronously in the caller's context, so task_active_pid_ns(current) is the caller's pid namespace.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists in the Linux kernel's netdev generic netlink interface where NAPI kthread process identifiers are improperly reported across different process identifier namespaces. The flaw occurs in the netdev_nl_napi_fill_one() function which uses task_pid_nr() to retrieve the NAPI kthread PID, but this function returns the global PID value from the initial pid namespace rather than translating it to the caller's specific namespace context.
The security implications arise from the NETDEV_CMD_NAPI_GET command lacking GENL_ADMIN_PERM permissions and operating within a netdev generic netlink family that is configured as netnsok. This configuration allows any process running in a child pid namespace to execute the command, yet when such a caller retrieves NAPI information, they receive the global PID of the kthread instead of the appropriate namespace-local value. Since the kthread is not visible within the caller's pid namespace, this creates a discrepancy where the reported PID appears valid but corresponds to an inaccessible process.
The vulnerability demonstrates a fundamental mismatch between how kernel subsystems handle process identification in namespace-aware environments versus traditional single-namespace contexts. This issue directly relates to CWE-284 Access Control and CWE-362 Concurrency Issues, as it involves improper privilege management and namespace translation errors. The problem follows ATT&CK technique T1059 Command and Scripting Interpreter where malicious actors could exploit this misreporting to bypass detection mechanisms that rely on process identification within specific namespaces.
The fix implemented mirrors the approach taken in commit 3799c2570982 which addressed similar issues with io_uring SQPOLL threads by translating thread PIDs through the caller's pid namespace. Both doit and dumpit execution paths operate synchronously within the caller's context, making task_active_pid_ns(current) the appropriate mechanism to determine which pid namespace should be used for translation. This ensures that processes in child namespaces receive properly translated PID values that correspond to their actual visibility within that namespace, maintaining consistency with the kernel's namespace isolation principles and preventing information disclosure through improper process identification.
The resolution addresses a critical gap in kernel security by ensuring proper namespace-awareness in process identifier reporting across generic netlink interfaces. This change prevents potential privilege escalation scenarios where attackers could exploit the discrepancy between global and namespace-local PIDs to bypass namespace-based security controls. The fix aligns with Linux kernel security best practices for maintaining consistent namespace behavior across all subsystems and reinforces the principle of least privilege by ensuring that processes only see identifiers that are valid within their own execution context.
This vulnerability highlights the complexity of maintaining proper namespace semantics in large-scale kernel subsystems where multiple interfaces must coordinate their handling of process identifiers. The solution demonstrates the importance of consistent translation mechanisms throughout the kernel's networking stack and provides a precedent for similar fixes in other subsystems that may exhibit comparable namespace translation issues, ultimately strengthening the overall security posture of Linux systems against namespace-based evasion techniques.