CVE-2026-68341

CVE-2026-68341 is a use-after-free in the OpenVPN kernel module where llist_for_each_entry() iterates over a peer release list while ovpn_peer_put() can drop the final reference and free the object mid-iteration. The bug: llist_for_each_entry() advances by reading peer->release_entry.next in the loop's increment expression, which executes after the loop body. If ovpn_peer_put() frees the peer on the last reference, the next-pointer read accesses freed memory. The fix (llist_for_each_entry_safe) caches the next pointer before executing the body — correct for this call site. The EPSS score of 0.00206 fundamentally misreads this. It treats it as a standard kernel UAF and weighs deployment prevalence heavily. But the real analytical question is whether ovpn_peer_put()'s reference-drop semantics create a structurally recurring risk across other hot paths in the module. The same unsafe iteration pattern exists elsewhere in the kernel (netfilter, inet subsystems were patched for this in the mid-2010s), and OVPN inherits the same dangerous primitive without the institutional memory of those prior failures. The immediate action is to audit every llist iteration site in the OVPN module. Specifically, find every llist_for_each_entry() call and examine whether the loop body contains any reference-drop function (ovpn_peer_put or equivalents). Rank findings by blast radius: code paths that call reference-dropping functions inside list iterations carry catastrophic potential, while read-only iterations carry zero risk from this pattern. This audit is manual and relies on reviewer expertise — the kernel has lockdep for lock ordering but no equivalent for validating lock-free iteration against object destruction models. Determine whether ovpn_peer_put() always frees synchronously or has async deferral paths. If freeing is deferred, the UAF might not manifest in basic testing (where memory pressure is low) but could surface under production load. Also determine whether the attacker can control which peer receives the last reference drop. If it's deterministic teardown order, exploitability is lower. If heap layout can be controlled through active tunnel traffic, the UAF becomes primitive extraction into the kernel heap allocator. This is not merely a patched bug — it's evidence of a gap between 'this pattern is known-dangerous' and 'we have no tooling to prevent its reuse.' The next module consuming llist primitives with the same assumptions will produce the same vulnerability class.

Reviewed through automated stages and approved by a human before publication.