CVE-2026-74602 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer()
In rb_allocate_cpu_buffer(), bpage->order was omitted, leaving it as 0. This is an issue for a ring-buffer with subbufs bigger than PAGE_SIZE if when freed: free_buffer_page() relies on this value. Align the value with the actual allocation size (buffer::subbuf_order).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/23/2026
The Linux kernel's ring buffer implementation contains a critical initialization flaw within the rb_allocate_cpu_buffer function that can lead to memory corruption and system instability under specific configuration conditions. This vulnerability arises from an omission in setting the page order for reader pages during the allocation phase of the CPU buffer setup. Specifically, the bpage->order field is left uninitialized at zero rather than being aligned with the actual size of the allocated sub-buffer as defined by the buffer::subbuf_order parameter. While this oversight may not manifest immediately under default configurations where sub-buffers are typically page-sized or smaller, it becomes a severe issue when the ring buffer is configured to use sub-buffers larger than PAGE_SIZE. In such scenarios, the kernel allocates memory using higher-order allocations that span multiple physical pages, but the metadata tracking these allocations fails to reflect this reality due to the missing initialization step.
The operational impact of this flaw materializes primarily during the deallocation process when free_buffer_page is invoked. This function relies heavily on the page order value to correctly determine how many contiguous pages were allocated and must be released back to the system memory manager. When bpage->order remains at zero, the kernel assumes a single-page allocation regardless of the actual multi-page footprint reserved for larger sub-buffers. Consequently, only one page is freed while the remaining associated pages are left in an inconsistent state within the allocator's tracking structures. This discrepancy can lead to double-free errors if those orphaned pages are subsequently reallocated and then freed again through other code paths, or it may result in memory leaks where portions of allocated physical memory become permanently inaccessible to both the ring buffer subsystem and general system use. Over time, such memory management anomalies contribute to resource exhaustion and potential denial-of-service conditions for affected systems.
From a technical classification perspective, this vulnerability aligns with CWE-457 which describes an Uninitialized Variable usage error. The failure to properly initialize bpage->order constitutes a classic instance of using uninitialized data that dictates critical control flow during memory deallocation. Furthermore, the exploitation potential relates to CWE-120 Buffer Overflow if the incorrect freeing mechanism leads to heap corruption or use-after-free scenarios when subsequent allocations reuse the improperly freed memory regions. In terms of adversarial tactics, this flaw could be leveraged within ATT&CK technique T1499 Endpoint Denial of Service by causing kernel panics through repeated allocation and deallocation cycles that trigger the faulty free logic. It also touches upon aspects of privilege escalation if an attacker can manipulate ring buffer parameters to induce memory corruption in a way that allows for arbitrary code execution, although this would require additional conditions beyond just triggering the initial bug.
Mitigation strategies must address both immediate remediation and long-term defensive coding practices. The primary fix involves ensuring that rb_allocate_cpu_buffer correctly assigns bpage->order based on buffer::subbuf_order before any pages are allocated or referenced. This ensures consistency between allocation size tracking and deallocation logic. System administrators should apply kernel updates provided by their distribution vendors as soon as patches become available, particularly for systems running custom ring buffers with large sub-buffer sizes such as those used in high-performance tracing tools like ftrace or perf. For environments where immediate patching is not feasible, restricting the maximum size of ring buffer sub-buffers to PAGE_SIZE or less can serve as a temporary workaround to avoid triggering the faulty deallocation path. Additionally, developers should enforce strict initialization checks for all structure fields that influence memory management operations to prevent similar uninitialized variable vulnerabilities in future kernel versions.