Odebrany

CVE-2026-97595

opublikowano: 25.09.2026, 13:17

modyfikacja: 25.09.2026, 17: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ę:

mac802154: naprawiono możliwość wykorzystania danych sdata poprzez kolejkowane ramki RX

Producent oprogramowania RX ieee802154_subif_frame() kolejkuje otrzymanie sygnału nawigacyjnego
i ramki poleceń MAC na local->rx_beacon_list / rx_mac_cmd_list i
planuje proces roboczy kontekstu procesu, przechowując surowy plik mac_pkt->sdata (i
skb->dev == sdata->dev) bez odniesienia i bez żadnych blokad:

- listy nie mają blokady: producent softirq list_add_tail()s podczas gdy
mac_wq worker list_del()s, więc interfejsy rodzeństwa na tym samym fiszy są uszkodzone
lista;

- pracownicy wyrejestrowują interfejs po jego zwolnieniu.
mac802154_rx_mac_cmd_worker() dotyka bezpośrednio mac_pkt->sdata i
mac802154_rx_beacon_worker() -> mac802154_process_beacon() dereferencje
skb->dev (== sdata->dev). Usunięcie interfejsu powoduje zwolnienie jego danych
(netdev_priv), podczas gdy ramka w kolejce nadal na nią wskazuje, więc późniejszy proces roboczy
run jest darmowy po użyciu.

Reprodukowane przez KASAN poprzez zalanie interfejsu ofiary poleceniem MAC
ramki i usunięcie ich (ścieżka sygnału nawigacyjnego to ta sama klasa poprzez skb->dev):

BŁĄD: KASAN: płyta-use-after-free w mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154]
Odczytaj rozmiar 4 pod adresem ffff888002f9ea18 przez zadanie kworker/u8:1/31
Kolejka robocza: phy0-mac-cmds mac802154_rx_mac_cmd_worker [mac802154]
Zadzwoń do śledzenia:
mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154]
proces_one_work+0x611/0xe80
wątek_pracownika+0x52e/0xdc0
kthread+0x30c/0x630
ret_from_fork+0x2fd/0x3e0

Napraw obie listy razem:

- dodaj local->rx_lock i korzystaj z niego przy każdym dostępie do listy: softirq
producent (zwykły spin_lock, kontekst softirq) i pracownicy oraz kolor
(spin_lock_bh, kontekst procesu);

- przypnij interfejs na czas życia ramki znajdującej się w kolejce
netdev_hold()/netdev_put(), więc pracownik może bezpiecznie odwołać się do sdata /
skb->dev nawet podczas usuwania interfejsu;

- usuń z kolejki pod blokadą na początku i opróżnij całą listę w pętli
workers (wcześniej przetwarzali jedną ramkę na przebieg i polegali na a
później ustawić w kolejce, aby spuścić resztę);

- usuwać jeszcze nierozpoczęte ramki interfejsu zanim zostanie on wyrejestrowany,
z ieee802154_if_remove() (po okresie karencji RCU) i z
pętla ieee802154_remove_interfaces() — ta ostatnia jest całością
ścieżka rozrywania, która nie przechodzi przez ieee802154_if_remove().

Proces roboczy w locie, który już usunął z kolejki ramkę, zachowuje własnego netdeva
odniesienie; unregister_netdevice() następnie czeka na to w netdev_run_todo(),
który działa w rtnl_unlock() (rtnl zwolniony) i po uruchomieniu interfejsu
został zamknięty, więc nie przypina rtnl. Pracownik zablokowany w stowarzyszeniu
TX opóźnia tylko wyrejestrowanie jednego interfejsu (zwykłe „oczekiwanie na %s
stać się wolnym”), nie obowiązuje rtnl. Służy do tego funkcja netdev_hold().
powód zamiast cancel_work_sync() w rtnl, co spowodowałoby zablokowanie
nieograniczone oczekiwanie MLME TX pracownika przez ieee802154_sync_queue().

Proces roboczy mac-command dodatkowo pomija przetwarzanie w przypadku zatrzymania
interfejs (ieee802154_sdata_running()), unikając niepotrzebnego skojarzenia
reakcja podczas rozbiórki.

In the Linux kernel, the following vulnerability has been resolved:

mac802154: fix use-after-free of sdata via queued RX frames

The RX softirq producer ieee802154_subif_frame() queues received beacon
and MAC-command frames onto local->rx_beacon_list / rx_mac_cmd_list and
schedules a process-context worker, storing a raw mac_pkt->sdata (and
skb->dev == sdata->dev) with neither a reference nor any locking:

- the lists have no lock: the softirq producer list_add_tail()s while the
mac_wq worker list_del()s, so sibling interfaces on the same phy corrupt
the list;

- the workers dereference the interface after it may have been freed.
mac802154_rx_mac_cmd_worker() touches mac_pkt->sdata directly, and
mac802154_rx_beacon_worker() -> mac802154_process_beacon() dereferences
skb->dev (== sdata->dev). Removing an interface frees its sdata
(netdev_priv) while a queued frame still points at it, so a later worker
run is a use-after-free.

Reproduced under KASAN by flooding a victim interface with MAC command
frames and removing it (the beacon path is the same class via skb->dev):

BUG: KASAN: slab-use-after-free in mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154]
Read of size 4 at addr ffff888002f9ea18 by task kworker/u8:1/31
Workqueue: phy0-mac-cmds mac802154_rx_mac_cmd_worker [mac802154]
Call Trace:
mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154]
process_one_work+0x611/0xe80
worker_thread+0x52e/0xdc0
kthread+0x30c/0x630
ret_from_fork+0x2fd/0x3e0

Fix both lists together:

- add local->rx_lock and take it around every list access: the softirq
producer (plain spin_lock, softirq context) and the workers and flush
(spin_lock_bh, process context);

- pin the interface for the lifetime of a queued frame with
netdev_hold()/netdev_put(), so the worker can safely dereference sdata /
skb->dev even while the interface is being removed;

- dequeue under the lock at the head and loop-drain the whole list in the
workers (they previously processed one frame per run and relied on a
later enqueue to drain the rest);

- drop not-yet-started frames of an interface before it is unregistered,
from ieee802154_if_remove() (after the RCU grace period) and from the
ieee802154_remove_interfaces() loop -- the latter is the whole-phy
teardown path, which does not go through ieee802154_if_remove().

An in-flight worker that already dequeued a frame keeps its own netdev
reference; unregister_netdevice() then waits it out in netdev_run_todo(),
which runs at rtnl_unlock() (rtnl released) and after the interface has
been closed, so it does not pin rtnl. A worker blocked in an association
TX only delays that one interface's unregister (the usual "waiting for %s
to become free"), it does not hold rtnl. netdev_hold() is used for this
reason instead of a cancel_work_sync() under rtnl, which would block on
the worker's unbounded MLME TX wait via ieee802154_sync_queue().

The mac-command worker additionally skips processing for a stopped
interface (ieee802154_sdata_running()), avoiding a needless association
response during teardown.

>_ 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