CVE-2026-49427 in FreeBSD
Summary
by MITRE • 08/19/2026
Pages belonging to largepage shared memory objects were not explicitly wired. When sendfile(2) transmitted such an object with the SF_NOCACHE flag, it freed the underlying pages after transmission even though existing mappings still referred to them.
An unprivileged local user can abuse the bug to access freed kernel memory. This can be exploited to escalate privileges.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability described involves a critical flaw in the handling of large page shared memory objects within the operating system's virtual memory management subsystem, specifically affecting the sendfile(2) system call when invoked with the SF_NOCACHE flag. In modern operating systems, shared memory objects allow multiple processes to map and access the same physical pages for efficient data sharing. To ensure data integrity and prevent premature deallocation while active mappings exist, these pages are typically wired into physical memory using reference counting mechanisms that track how many virtual address spaces currently hold valid references to those specific frames. The core technical flaw lies in the failure of the sendfile implementation to explicitly wire or properly increment the reference count for large page shared memory objects during transmission when caching is disabled via SF_NOCACHE. This oversight means that while the kernel initiates the data transfer, it does not establish a persistent lock on the underlying physical pages against deallocation by other subsystems or cleanup routines that might assume no active references remain after the I/O operation completes.
When sendfile(2) executes with the SF_NOCACHE flag, its primary objective is to bypass page cache mechanisms for performance reasons, directly transferring data from a file descriptor to another without populating the system's buffer cache. However, in this specific scenario involving large page shared memory objects, the kernel incorrectly determines that once the transmission logic concludes, there are no longer any active references requiring protection against free operations. Consequently, the underlying physical pages associated with these shared memory segments are freed and returned to the general pool of available kernel memory before all existing virtual mappings have been invalidated or accounted for. This creates a classic use-after-free condition where the operating system reclaims memory that is still actively mapped into user-space address spaces. The discrepancy arises because the reference counting logic fails to account for the persistent nature of shared memory mappings when bypassing standard caching pathways, leading to a race-like state where kernel-managed resources are released while still in active use by unprivileged processes.
The operational impact of this flaw is severe, as it allows an unprivileged local user to trigger the premature freeing of kernel-owned physical pages and subsequently access that reclaimed memory through their existing mappings. Since the virtual-to-physical translation tables for these large pages remain valid from the perspective of the application process, any read or write operation targeting those addresses will interact with whatever new data has been allocated in that same physical location by other kernel subsystems or subsequent allocations. This effectively grants the attacker a window to perform arbitrary reads and potentially writes into kernel memory space without proper privilege checks. Such access can be leveraged to leak sensitive information, such as cryptographic keys, session tokens, or internal kernel structures, thereby compromising system confidentiality. More critically, it provides a reliable primitive for privilege escalation attacks by allowing an untrusted user to modify critical kernel data structures, alter execution flow, or disable security mechanisms like SELinux or AppArmor profiles from within the context of their own low-privilege process.
From a classification perspective, this vulnerability aligns with CWE-416: Use After Free, as it involves accessing memory after it has been freed by the system. It also relates to CWE-200: Information Exposure and CWE-787: Out-of-bounds Write if the attacker utilizes the mapped pages for writing operations that corrupt kernel state. In terms of adversary tactics, this flaw facilitates techniques associated with ATT&CK T1055: Process Injection or Memory Dumping when used to extract secrets, and more broadly supports privilege escalation vectors found in lateral movement phases where an initial foothold is converted into administrative control. The lack of explicit wiring represents a failure in resource management hygiene, specifically violating the principle that shared resources must remain protected until all consumers have explicitly released their claims on them.
Mitigation strategies for this vulnerability require immediate patching by the operating system vendor to correct the reference counting logic within the sendfile implementation for large page shared memory objects. The fix should ensure that when SF_NOCACHE is specified, the kernel correctly increments the pin count or wire limit for any shared memory pages involved in the transfer until all mappings are explicitly unmapped by user-space applications. Until patches are applied, administrators can mitigate risk by restricting access to sendfile(2) through mandatory access control policies if feasible, although this may impact legitimate application functionality given its widespread use in high-performance web servers and file serving daemons. Additionally, enabling kernel hardening features such as KASLR (Kernel Address Space Layout Randomization), SMEP/SMAP on x86 architectures to prevent user-mode execution of kernel pages, and strict memory isolation techniques can reduce the exploitability window by making it harder for attackers to predict target addresses or execute injected code within the freed memory regions. Regular auditing of system calls involving shared memory and monitoring for anomalous memory access patterns in critical services can also aid in early detection of exploitation attempts targeting this class of vulnerabilities.