Linux Kernel CVE-2025-68333

Exploitation is confined to kernels built with CONFIG_PREEMPT_RT=y (the real-time preemption variant) that also use the sched_ext BPF-based scheduler, and only in the Linux 6.18 release-candidate series (rc1-rc6); stable kernels and non-RT builds are not affected. The deadlock arises only when deferred_irq_workfn() runs against the current CPU's runqueue and a hardware interrupt lands precisely while rq->__lock is held, so it is a non-deterministic race, not a reliably triggerable condition. Limiting factors: requires local presence on the host (AV:L) and some privilege/scheduling activity (PR:L), affects only a narrow RT+sched_ext configuration, and impacts only pre-release kernels - meaning no deployed production system running a stable release is exposed.

This is a low-priority, defense-in-depth kernel hardening fix rather than an attacker-driven vulnerability. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 5.5) correctly captures the profile: local access only, no confidentiality or integrity impact, and availability-only consequence (a deadlock/hang). CWE-667 (improper locking) matches the root cause - recursive acquisition of rq->__lock when deferred_irq_workfn() runs in softened IRQ context on PREEMPT_RT=y kernels. No EPSS score, no CISA KEV listing, and no public exploit were provided, so by the precision rules this is 'no public exploit identified at time of analysis.' Crucially, the affected set is limited to Linux 6.18 release candidates (rc1-rc6), which are pre-release kernels not used in production, so real-world exposure is minimal. One conflicting signal: the input Tags assert 'Information Disclosure,' but the CVSS vector is explicitly C:N/I:N/A:H - there is NO confidentiality impact, so the tag is wrong and should be disregarded. Overall this is a high-CVSS-relative-to-impact edge case with negligible real-world risk: a timing-dependent, local availability bug on RT kernels that never shipped in a stable release.

On a PREEMPT_RT=y kernel built from Linux 6.18-rc with sched_ext in use, the deferred IRQ work function executes in a preemptible per-CPU task context; if it processes the current CPU's runqueue and is interrupted while holding rq->__lock, a re-entrant attempt to take the same lock deadlocks that CPU. This is a race condition triggered by normal scheduling activity and interrupt timing rather than a crafted payload, so there is no public exploit and deliberate triggering by a local user would be unreliable.