CVE-2026-80845: xfrm: avoid lock inversion in nat keepalive work
In the Linux kernel, the following vulnerability has been resolved:
xfrm: avoid lock inversion in nat keepalive work
natkeepalivework() walks the state table while xfrmstatewalk() holds net->xfrm.xfrmstatelock. Its callback then acquires x->lock, which conflicts with the delete path taking the same locks in reverse order via xfrmstatedelete() and xfrmstatedelete(). This creates an AB-BA deadlock that is reported by lockdep when a NAT keepalive worker races with SA deletion.
Fix this by splitting the keepalive walk into two phases. First, collect the candidate states while the walk holds xfrmstatelock and take a reference on each state. Then, after the walk completes, process each collected state and acquire x->lock without nesting it under xfrmstatelock.
Affected Software
Event History
Frequently Asked Questions
When can this deadlock occur?
It can occur when the NAT keepalive worker is walking XFRM states at the same time that a security association is being deleted. The conflicting lock order between the keepalive path and deletion path can create an AB-BA deadlock.
What is the operational impact of triggering the issue?
The affected work can deadlock, preventing the involved kernel paths from making progress. Lockdep reports the issue when the NAT keepalive worker races with security association deletion.
How does the resolved implementation prevent the lock inversion?
It first collects candidate states and takes references while holding xfrm_state_lock. It then processes those states only after the walk is complete, acquiring each state lock without nesting it under xfrm_state_lock.