Odebrany

CVE-2026-98369

opublikowano: 06.10.2026, 11:18

modyfikacja: 06.10.2026, 11:18

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

xfrm: dodaj brakujące rcu_read_lock(), skb_dst_force() i dev_hold() dla xfrm_trans_reinject()

syzbot zgłosił podejrzane ostrzeżenie dotyczące użycia RCU w ip6_pkt_drop():

OSTRZEŻENIE: podejrzane użycie RCU w ip6_pkt_drop
include/net/addrconf.h:389 podejrzane użycie funkcji rcu_dereference_check()!

Zadzwoń do śledzenia:
__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]
proces_scheduled_works+0xa8e/0x14e0 jądro/workqueue.c:3405
wątek_pracownika+0xa47/0xfb0 jądro/workqueue.c:3486

Kiedy zatwierdzisz 4f4920669d21 („xfrm: Wprowadź ponownie pakiety w trybie transportu przez
workqueue”) przekonwertował xfrm_trans_reinject z zadania na kolejkę roboczą,
pętla ponownego wstrzyknięcia przestała działać w kontekście softirq. Pracownicy kolejki roboczej
uruchom w kontekście procesu, gdzie local_bh_disable() nie wprowadza RCU
sekcja krytyczna strony odczytu w CONFIG_PREEMPT_RCU.

Ponieważ wywołania zwrotne zakończenia (takie jak ip6_rcv_finish) spodziewają się, że będą działać pod adresem
Blokada odczytu RCU (przeszukiwanie tras, wyszukiwanie l3mdev i uzyskiwanie dostępu
Struktury danych chronione RCU), wywołując je w kontekście kolejki roboczej bez
rcu_read_lock() wyzwala ostrzeżenia o blokowaniu RCU.

Co więcej, pakiety umieszczane w kolejce roboczej za pomocą funkcji xfrm_trans_queue_net()
może przenosić wpisy dst niezliczone (noref) (np. z ip_route_input_noref).
Dodatkowo, w przypadku wyrejestrowania urządzenia sieciowego, dst_dev_put() zastępuje dst->dev
z blackhole_netdev, więc wpisy dst nie utrzymują skb->dev przy życiu
stał w kolejce roboczej.

Napraw te problemy poprzez:
1. Wywołanie skb_dst_force(skb) w xfrm_trans_queue_net() będąc jeszcze w
sekcję RCU dzwoniącego, aby upewnić się, że dst zostanie zliczony przed ustawieniem się w kolejce.
2. Trzymanie referencji na skb->dev poprzez dev_hold()/dev_put() w kolejce roboczej
odroczenie, aby skb->dev pozostało ważne podczas przetwarzania wywołania zwrotnego Finish().
3. Pobranie funkcji rcu_read_lock() wokół pętli wywołania zwrotnego zakończenia
xfrm_trans_reinject().

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().

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve