Missing Synchronization Affecting python3-perf package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS10-PYTHON3PERF-20658134
- published9 Oct 2026
- disclosed6 Oct 2026
Introduced: 6 Oct 2026
NewCVE-2026-98369 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 python3-perf.
NVD Description
Note: Versions mentioned in the description apply only to the upstream python3-perf package and not the python3-perf package as distributed by Centos.
See How to fix? for Centos:10 relevant fixed versions and status.
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:
- 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.
- Holding a reference on skb->dev via dev_hold()/dev_put() across workqueue deferral so skb->dev remains valid during finish() callback processing.
- Acquiring rcu_read_lock() around the finish callback invocation loop in xfrm_trans_reinject().
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2546410
- https://access.redhat.com/security/cve/CVE-2026-98369
- https://git.kernel.org/stable/c/0cda8273265d30cac6423834fd7d4acb75f04fdb
- https://git.kernel.org/stable/c/41e47f1664be86c91326f0afe0504a1162d00907
- https://git.kernel.org/stable/c/6601d91a85761f33351c71e04ec0bbd294ca07ce
- https://git.kernel.org/stable/c/664fc0941df7c1918b2cd4de6ee00469ba77d8e4
- https://git.kernel.org/stable/c/68a317b4aec8ca1868a39d69e40f9e29baa4f40a
- https://git.kernel.org/stable/c/6eb3b071be8e260543c604550c54dac66e6b174b
- https://git.kernel.org/stable/c/d2f5082f9e84653fa1a9e8aebaaff23e688f5e19