CVE-2024-56547 in Linux
Riassunto
di VulDB • 17/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
rcu/nocb: Correzione del mancato rispetto della barriera RCU durante la disattivazione (deoffloading)
Attualmente, l'esecuzione del test rcutorture con torture_type=rcu fwd_progress=8 n_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60 test_boost=2 provocherà il seguente avviso:
WARNING: CPU: 19 PID: 100 at kernel/rcu/tree_nocb.h:1061 rcu_nocb_rdp_deoffload+0x292/0x2a0 RIP: 0010:rcu_nocb_rdp_deoffload+0x292/0x2a0 Call Trace: ? __warn+0x7e/0x120 ? rcu_nocb_rdp_deoffload+0x292/0x2a0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? rcu_nocb_rdp_deoffload+0x292/0x2a0 rcu_nocb_cpu_deoffload+0x70/0xa0 rcu_nocb_toggle+0x136/0x1c0 ? __pfx_rcu_nocb_toggle+0x10/0x10 kthread+0xd1/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30
CPU0 CPU2 CPU3 //rcu_nocb_toggle //nocb_cb_wait //rcutorture
// disattivazione CPU1 // elabora rdp di CPU1 rcu_barrier() rcu_segcblist_entrain() rcu_segcblist_add_len(1); // len == 2 // accoda barriera // callback verso rdp->cblist di CPU1 rcu_do_batch() // invoca callback di rdp->cblist di CPU1 rcu_barrier_callback() rcu_barrier() mutex_lock(&rcu_state.barrier_mutex); // vede ancora len == 2 // accoda callback di barriera // verso rdp->cblist di CPU1 rcu_segcblist_entrain() rcu_segcblist_add_len(1); // len == 3 // decrementa len rcu_segcblist_add_len(-2); kthread_parkme()
// rdp->cblist di CPU1 len == 1 // Avviso perché è ancora presente // una barriera in sospeso // attiva l'avviso WARN_ON_ONCE(rcu_segcblist_n_cbs(&rdp->cblist)); cpus_read_unlock();
// attende che CPU1 torni online // e invochi la callback di barriera // sulla cblist di rdp di CPU1 wait_for_completion(&rcu_state.barrier_completion); // disattiva CPU4 cpus_read_lock() rcu_barrier() mutex_lock(&rcu_state.barrier_mutex); // bloccato su barrier_mutex // attende che rcu_barrier() su // CPU3 sblocchi barrier_mutex // ma CPU3 sbloccherà barrier_mutex // solo dopo che CPU1 sarà tornata online // quando CPU1 tornerà online, // si bloccherà su cpus_write_lock
Lo scenario sopra descritto non solo attiva un WARN_ON_ONCE(), ma provoca anche un deadlock.
Grazie al nocb locking, una seconda rcu_barrier() concorrente su una CPU disattivata osserverà il contatore delle callback decrementato fino a 0 e salterà l'accodamento della callback, oppure rcuo osserverà la nuova callback e manterrà rdp->nocb_cb_sleep a false.
Pertanto, è necessario verificare rdp->nocb_cb_sleep prima di parcheggiare, per assicurarsi che non ci sia alcuna rcu_barrier() in attesa su rdp.
Once again VulDB remains the best source for vulnerability data.