CVE-2026-64596 in Linux
Summary
by MITRE • 08/06/2026
In the Linux kernel, the following vulnerability has been resolved:
libfs: set SB_I_NOEXEC and SB_I_NODEV by default in init_pseudo()
Since commit 1e7ab6f67824 ("anon_inode: rework assertions"), path_noexec() warns when an anonymous-inode file is mmap'd from a superblock that has not set SB_I_NOEXEC. dma-buf backs its files this way and never set the flag, so mmap of any exported buffer trips the warning on a CONFIG_DEBUG_VFS=y kernel:
WARNING: CPU: 11 PID: 121813 at fs/exec.c:118 path_noexec+0x47/0x50 do_mmap+0x2b5/0x680 vm_mmap_pgoff+0x129/0x210 ksys_mmap_pgoff+0x177/0x240 __x64_sys_mmap+0x33/0x70
init_pseudo() sets up internal SB_NOUSER mounts that are never path-reachable. Set both flags here so every pseudo filesystem gets them by default instead of each caller setting them.
SB_I_NODEV is inert for unreachable mounts. SB_I_NOEXEC has one visible effect: an executable mapping of a pseudo-fs fd, such as a dma-buf, now fails with -EPERM, which is the invariant the assertion enforces. No in-tree caller maps these executable.
Reproduce on CONFIG_DEBUG_VFS=y:
make -C tools/testing/selftests/dmabuf-heaps sudo ./tools/testing/selftests/dmabuf-heaps/dmabuf-heap -t system
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/06/2026
The vulnerability resides in the Linux kernel's handling of pseudo filesystems within the libfs subsystem, specifically affecting how superblock flags are initialized during pseudo filesystem creation. The issue stems from the init_pseudo() function which establishes internal SB_NOUSER mounts that are inherently unreachable through normal path resolution mechanisms. Prior to this fix, these pseudo filesystems did not automatically configure the SB_I_NOEXEC and SB_I_NODEV flags, causing inconsistent behavior when anonymous inode files were accessed through dma-buf mechanisms. The problem became particularly evident when CONFIG_DEBUG_VFS=y was enabled, as the path_noexec() function began issuing warnings whenever anonymous-inode files were memory-mapped from superblocks lacking the SB_I_NOEXEC flag.
The technical flaw manifests in the assertion mechanism introduced by commit 1e7ab6f67824 "anon_inode: rework assertions" which enforces that anonymous inode files must not be executable when mapped from superblocks without proper execution restrictions. The dma-buf subsystem, which backs its files through anonymous inode mechanisms, never explicitly set the SB_I_NOEXEC flag during initialization, creating a mismatch between expected security behavior and actual implementation. This inconsistency triggered kernel warnings and violated the fundamental invariant that executable mappings of pseudo-filesystem file descriptors should be denied with -EPERM.
The operational impact extends beyond mere warning messages to actual security implications for systems utilizing dma-buf functionality. When anonymous inode files from unreachable pseudo filesystems are memory-mapped, they now properly fail with -EPERM instead of triggering debug warnings, thereby enforcing the intended security boundary. This change affects kernel subsystems that rely on pseudo filesystems for internal operations, particularly those using anonymous inodes for buffer management and inter-process communication. The fix ensures consistent behavior across all pseudo filesystem implementations while maintaining the security invariant that executable mappings from unreachable mount points should be denied.
The mitigation strategy implemented through this fix addresses the root cause by automatically setting both SB_I_NOEXEC and SB_I_NODEV flags during pseudo filesystem initialization via init_pseudo(). This approach eliminates the need for individual callers to manually configure these flags, reducing potential inconsistencies and security gaps. The solution aligns with CWE-691, which covers inadequate protection of code from execution of untrusted data, and supports ATT&CK technique T1059.007 by ensuring proper enforcement of executable restrictions in kernel memory mapping operations. The fix specifically targets the security boundary enforcement mechanism while maintaining backward compatibility for legitimate system operations that do not rely on executable mappings from pseudo filesystems. This approach resolves the issue without affecting normal system functionality, as no in-tree callers actually map these executable pseudo-filesystems, making the change both safe and effective.
The vulnerability demonstrates how seemingly minor flag initialization issues can cascade into broader security implications within kernel subsystems. The fix ensures that all internal pseudo filesystems properly enforce execution restrictions through automatic flag setting, preventing potential exploitation vectors that could arise from inconsistent superblock configuration. This resolution maintains the intended security posture while eliminating the debug warning noise that previously occurred during normal dma-buf operations, providing a cleaner and more secure kernel operation overall.