CVE-2026-72123 in Linuxinformazioni

Riassunto

di VulDB • 15/08/2026

Nel kernel Linux è stata risolta la seguente vulnerabilità:

can: bcm: posticipare il deallocazione di rx_op al workqueue per correggere l'UAF su thrtimer

Il commit f1b4e32aca08 ("can: bcm: usare call_rcu() invece del costoso synchronize_rcu()") ha sostituito synchronize_rcu() in bcm_delete_rx_op() con call_rcu() e introdotto il flag RX_NO_AUTOTIMER.

Tuttavia, questo controllo sul flag è stato omesso per thrtimer nel percorso veloce (fast-path) di ricezione dei pacchetti. Durante la fase di teardown dell'operazione BCM RX, un lettore RCU concorrente (bcm_rx_handler) può andare in race condition e riarmare thrtimer tramite bcm_rx_update_and_send() dopo che call_rcu() è stato programmato. Una volta trascorso il periodo di grazia RCU, bcm_op viene liberato. Il successivo scatto di thrtimer dereferenzia quindi l'op già deallocato, causando un Use-After-Free (UAF).

L'aggiunta dei controlli sui flag nel percorso veloce rx (bcm_rx_update_and_send) non chiude completamente la race condition TOCTOU e introduce latenza per ogni frame CAN. Al contrario, chiamare hrtimer_cancel() direttamente all'interno della callback RCU (contesto softirq) è fatale poiché hrtimer_cancel() può andare in sleep, innescando un panic "scheduling while atomic".

Si risolve il problema posticipando la cancellazione del timer e la liberazione della memoria a un workqueue dedicato non vincolato (bcm_wq). La callback RCU ora accoda un elemento di lavoro a bcm_wq, che cancella in modo sicuro entrambi i timer e dealloca la memoria nel contesto di processo sleepable. Viene utilizzato un workqueue dedicato per prevenire il saturamento del WQ su tutto il sistema ed è svuotato/distrutto pulitamente al caricamento del modulo (module unload) per evitare page fault durante rmmod.

Poiché il lavoro posticipato può ora sopravvivere oltre il contesto chiamante per una durata illimitata, si acquisisce anche un riferimento a op->sk quando viene assegnato e lo si rilascia solo dopo che il lavoro posticipato ha cancellato entrambi i timer, in modo che un socket non possa più essere liberato mentre è ancora armato un timer la cui callback (bcm_send_to_user()) dereferenzia op->sk.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Responsabile

Linux

Prenotare

09/08/2026

Divulgazione

15/08/2026

Moderazione

accettato

CPE

pronto

EPSS

0.00215

KEV

no

Attività

basso

Fonti

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!