Linux Kernel CVE-2026-98369

Requires the host to actually process IPsec/xfrm transport-mode traffic, since the vulnerable path is xfrm_trans_reinject() reinjecting transport-mode packets deferred through a workqueue (behavior introduced by commit 4f4920669d21). The dangerous condition arises specifically when queued skbs carry non-refcounted (noref) dst entries (e.g. from ip_route_input_noref) AND a network device is concurrently unregistered so dst_dev_put() swaps dst->dev for blackhole_netdev - the finish callback then runs in process (workqueue) context lacking the RCU read lock and refcounts. Limiting factors: exploitation is a timing-sensitive race requiring the netdevice-unregistration window to overlap with queued reinjection; it needs local low-privilege access per the CVSS PR:L rating; and it only affects kernels built with CONFIG_PREEMPT_RCU where local_bh_disable() does not establish an RCU read-side critical section. Not exploitable against hosts not using xfrm transport mode.

Signals converge on LOW real-world priority despite the 7.8 'High' CVSS. The vendor (Linux kernel CNA) vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H claims local, low-complexity, low-privilege access with full High confidentiality/integrity/availability impact, but this appears inflated relative to the actual defect: the issue was surfaced by a syzbot RCU-lockdep warning in ip6_pkt_drop() and the fix adds missing rcu_read_lock(), skb_dst_force() and dev_hold() around xfrm_trans_reinject(). The underlying danger is a use-after-free of non-refcounted dst entries and of skb->dev (replaced by blackhole_netdev on netdevice unregistration) while packets sit queued in a workqueue - a race condition, which contradicts the vendor's AC:L rating; a concurrent netdevice-unregistration window realistically makes this AC:H. EPSS is 0.18% (7th percentile) - very low exploitation probability. There is no CISA KEV listing and no public exploit identified. SSVC-style read: exploitation = none observed, automatable = no (timing-dependent kernel race requiring IPsec/xfrm transport-mode processing), technical impact = partial-to-total but hard to weaponize. Net: a legitimate correctness/UAF fix worth patching in normal cycles, not an emergency. Note the conflict explicitly: CVSS claims C:H/I:H but the demonstrated manifestation is an RCU lockdep warning / potential crash, so the H/H/H impact is unverified - treat as primarily an availability (crash) risk unless vendor confirms memory-corruption-to-privesc.

On a host using IPsec/xfrm transport mode, a local low-privileged actor induces xfrm transport-mode packet reinjection (processed via workqueue) while a network device is being unregistered, causing a finish callback to dereference a now-freed or blackholed dst/skb->dev. The resulting use-after-free most plausibly crashes the kernel (DoS). No public proof-of-concept exists; the flaw was found by syzbot fuzzing, not a released exploit.