Description

In the Linux kernel, the following vulnerability has been resolved: xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for xfrm_trans_reinject() syzbot reported a suspicious RCU usage warning in ip6_pkt_drop(): WARNING: suspicious RCU usage in ip6_pkt_drop include/net/addrconf.h:389 suspicious rcu_dereference_check() usage! Call Trace: __in6_dev_get_safely include/net/addrconf.h:389 [inline] ip6_pkt_drop+0x596/0x610 net/ipv6/route.c:4620 ip6_pkt_discard+0x1c/0x30 net/ipv6/route.c:4651 xfrm_trans_reinject+0x324/0x630 net/xfrm/xfrm_input.c:806 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 When commit 4f4920669d21 ("xfrm: Reinject transport-mode packets through workqueue") converted xfrm_trans_reinject from a tasklet to a workqueue, the reinjection loop ceased running in softirq context. Workqueue workers run in process context where local_bh_disable() does not enter an RCU read-side critical section under CONFIG_PREEMPT_RCU. Because finish callbacks (such as ip6_rcv_finish) expect to run under an RCU read lock (performing route lookups, l3mdev lookups, and accessing RCU-protected data structures), invoking them in workqueue context without rcu_read_lock() triggers RCU lockdep warnings. Furthermore, packets queued to the workqueue via xfrm_trans_queue_net() may carry non-refcounted (noref) dst entries (e.g. from ip_route_input_noref). Additionally, on netdevice unregistration, dst_dev_put() replaces dst->dev with blackhole_netdev, so dst entries do not keep skb->dev alive while queued in the workqueue. Fix these issues by: 1. Calling skb_dst_force(skb) in xfrm_trans_queue_net() while still in the caller's RCU section to ensure dst is reference-counted before queuing. 2. Holding a reference on skb->dev via dev_hold()/dev_put() across workqueue deferral so skb->dev remains valid during finish() callback processing. 3. Acquiring rcu_read_lock() around the finish callback invocation loop in xfrm_trans_reinject().

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-06T09:18:31.280Z",
  "pubdate": "2026-10-06T09:18:31.280Z",
  "executiveSummary": "A vulnerability exists in the Linux kernel's XFRM (Transform) subsystem, specifically within the reinjection mechanism for transport-mode packets.\nThe issue is classified as an improper handling of RCU (Read-Copy-Update) critical sections and reference counting for network stack objects.\nThe flaw stems from a context mismatch occurring when the packet reinjection process was transitioned from softirq context to a workqueue-based process context.\nThis transition resulted in the loss of implicit RCU read-side protection and inadequate lifecycle management for skb_dst entries and net_device objects.\nImpact includes potential kernel memory corruption, use-after-free scenarios, and RCU lockdep warnings, which may lead to system instability or denial of service.\nExploitation does not require external authentication but involves triggering specific XFRM packet processing paths that result in deferred workqueue execution.\nThe risk is elevated as kernel panics or invalid memory accesses are likely when network devices are unregistered while packets are pending in the workqueue.",
  "technicalDetails": "The root cause of this vulnerability lies in the transition of xfrm_trans_reinject from a tasklet to a workqueue, as introduced in commit 4f4920669d21. In the previous softirq-based implementation, local_bh_disable() provided implicit RCU read-side protection. However, workqueue workers execute in process context, where local_bh_disable() does not maintain an RCU read-side critical section under CONFIG_PREEMPT_RCU.\nThe vulnerability manifests during the invocation of finish callbacks, such as ip6_rcv_finish. These functions perform operations like route lookups and l3mdev lookups, which strictly require an active RCU read lock. Without this, the kernel triggers 'suspicious RCU usage' warnings, indicating unsafe access to RCU-protected data structures.\nFurthermore, a lifecycle mismatch exists for packet metadata. Packets queued to the workqueue via xfrm_trans_queue_net() often contain 'noref' (non-reference-counted) dst entries, such as those derived from ip_route_input_noref. Because these entries are not properly refcounted before being placed in the workqueue, the associated dst and net_device objects may be freed if the underlying netdevice is unregistered before the workqueue executes.\nIn the event of netdevice unregistration, the kernel replaces dst->dev with a blackhole_netdev, which fails to keep the skb->dev alive for the duration of the workqueue delay. This creates a use-after-free condition where the deferred reinjection logic attempts to dereference pointers to freed memory.\nThe attack flow follows these steps: 1) The attacker injects a transport-mode XFRM packet into the network stack. 2) The system queues this packet for reinjection via xfrm_trans_queue_net(). 3) If the underlying network interface is unregistered or reconfigured, the packet remains in the workqueue with invalid object references. 4) The workqueue worker eventually invokes xfrm_trans_reinject() without the necessary RCU protection. 5) The worker attempts to access the invalidated dst or net_device, resulting in a kernel crash or memory corruption.\nThe vulnerability affects all Linux kernel versions utilizing the post-transition XFRM workqueue implementation that lack the explicit rcu_read_lock(), skb_dst_force(), and dev_hold() protections."
}