Linux Kernel Red Scheduler 0-Day Exploit Enables Physical Memory R/W

On July 20, 2026, researchers from 1day.dev publicly disclosed the full details of a Linux kernel 0-day vulnerability that existed in the network scheduler of Red Hat systems. This vulnerability was initially discovered and exploited with the intention of being submitted to Pwn2Own 2026 (Red Hat category). However, due to a delay in registration, it was not entered into the contest.

Although the vulnerability was reported by another researcher and no CVE has been issued, the issue was patched in June 2026. The published analysis does more than just detail the bug; it elaborates on a sophisticated exploit strategy that evolves a limited slab Use-After-Free (UAF) vulnerability into full physical memory read/write access.

Cause of the Vulnerability

The vulnerability resides in the network scheduler subsystem of the Linux kernel, specifically in the red scheduler. This subsystem has historically been a prime target for attacks due to its complexity and interaction with various network components.

The discoverer targeted Red Hat systems because they enable unprivileged user namespaces by default, which provides attackers with an unprivileged attack surface.

The root of the issue was introduced in commit 3f14b37 (January 2024) and fixed in commit a8a0289 (June 2026). This left the vulnerability dormant in the kernel for approximately 2.5 years.

According to the 1day.dev article, the bug arose from the tcf_qevent_handle() function improperly handling the TC_ACT_CONSUMED return value from tcf_classify(). This return value indicates that the socket buffer (skb) is retained by the fragmentation defragmentation engine (e.g., out-of-order fragment processing by act_ct). In this state, ownership of the skb does not belong to the caller, and thus it must not be accessed twice.

The fix was straightforward: a new case for TC_ACT_CONSUMED was added to the switch statement, ensuring the return of __NET_XMIT_STOLEN.

case TC_ACT_CONSUMED:
 *ret = __NET_XMIT_STOLEN;
 return NULL;

Exploit Strategy

The most valuable section of the analysis lies in its breakdown of the highly sophisticated exploit chain, which contrasts sharply with the simplicity of the bug fix. The discoverer executed the attack in four stages:

Stage 1: From Slab UAF to Page UAF The initial step involved leveraging a limited UAF primitive on the slab allocator. The researchers then extended this limited primitive into a more versatile page-level UAF.

Stage 2: From Page UAF to Physical Memory R/W Using the page-level UAF, the attackers established arbitrary read/write access to the physical memory map (physmap). This allowed them to bypass logical kernel space addresses and directly access the physical address space.

Stage 3: Arbitrary Physical Memory R/W With the established primitive, the attackers manipulated kernel data structures and tampered with page tables, enabling them to read and write to arbitrary locations in physical memory.

Stage 4: Privilege Escalation (uid=0) Finally, the attackers modified the process privilege information to escalate their access to root (uid=0), gaining full control of the system.

Impact and Assessment

The detailed exploit strategy revealed in this disclosure underscores the continued vulnerability of complex sub-systems like network schedulers to advanced attacks. Specifically, the thought process behind escalating a limited slab-level bug into a physical memory manipulation exploit highlights the gaps in kernel defense mechanisms, such as KASLR and CFI, and serves as a valuable case study for security researchers.

The 1day.dev researchers missed the opportunity to present their findings at Pwn2Own due to delayed registration. However, the fact that this bug, which went unpatched for nearly 2.5 years, was reported just before a major vulnerability discovery event by a different researcher raises important questions about the timing of vulnerability disclosures and the challenges of information-sharing among researchers.

Editorial Opinion

This case serves as a strong reminder for organizations operating Red Hat-based environments to promptly apply patches. The default policy of enabling unprivileged user namespaces, combined with the complexities of kernel subsystems, highlights the serious attack surface this creates. The detailed disclosure of the exploit chain by the discoverers also poses the risk of secondary attacks by those attempting to replicate the technique. Consequently, defenders must bolster monitoring and protection mechanisms for network-related kernel components.

In the longer term, this case may increase pressure on Linux distributors to reevaluate the default settings for unprivileged user namespaces. Modern kernel vulnerabilities increasingly rely on chaining sophisticated exploit primitives, such as the progression from a limited UAF to full system control demonstrated in this case. This signals that simply advancing defensive measures is insufficient; instead, reducing the attack surface must become a more critical strategy.

Perhaps the most compelling issue highlighted by this case is the potential for competitive events like Pwn2Own to inadvertently delay vulnerability disclosures.

References

• “A Linux Kernel 0-day Journey - From a limited UAF to Physical Memory R/W”, by 1day.dev via fro — Lobsters, 2026-07-20T20:15:57.000Z (ARR)
• Source URL: https://1day.dev/posts/linux-kernel-0day.html