{"uuid": "24a8a826-1147-4a3b-a74d-09294626c136", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-56547", "type": "seen", "source": "https://t.me/cvedetector/13744", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56547 - Apache Linux RCU Missed Barrier Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-56547 \nPublished : Dec. 27, 2024, 2:15 p.m. | 42\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nrcu/nocb: Fix missed RCU barrier on deoffloading  \n  \nCurrently, running rcutorture test with torture_type=rcu fwd_progress=8  \nn_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60  \ntest_boost=2, will trigger the following warning:  \n  \n WARNING: CPU: 19 PID: 100 at kernel/rcu/tree_nocb.h:1061 rcu_nocb_rdp_deoffload+0x292/0x2a0  \n RIP: 0010:rcu_nocb_rdp_deoffload+0x292/0x2a0  \n  Call Trace:  \n     \n   ? __warn+0x7e/0x120  \n   ? rcu_nocb_rdp_deoffload+0x292/0x2a0  \n   ? report_bug+0x18e/0x1a0  \n   ? handle_bug+0x3d/0x70  \n   ? exc_invalid_op+0x18/0x70  \n   ? asm_exc_invalid_op+0x1a/0x20  \n   ? rcu_nocb_rdp_deoffload+0x292/0x2a0  \n   rcu_nocb_cpu_deoffload+0x70/0xa0  \n   rcu_nocb_toggle+0x136/0x1c0  \n   ? __pfx_rcu_nocb_toggle+0x10/0x10  \n   kthread+0xd1/0x100  \n   ? __pfx_kthread+0x10/0x10  \n   ret_from_fork+0x2f/0x50  \n   ? __pfx_kthread+0x10/0x10  \n   ret_from_fork_asm+0x1a/0x30  \n     \n  \nCPU0                               CPU2                          CPU3  \n//rcu_nocb_toggle             //nocb_cb_wait                   //rcutorture  \n  \n// deoffload CPU1             // process CPU1's rdp  \nrcu_barrier()  \n    rcu_segcblist_entrain()  \n        rcu_segcblist_add_len(1);  \n        // len == 2  \n        // enqueue barrier  \n        // callback to CPU1's  \n        // rdp->cblist  \n                             rcu_do_batch()  \n                                 // invoke CPU1's rdp->cblist  \n                                 // callback  \n                                 rcu_barrier_callback()  \n                                                             rcu_barrier()  \n                                                               mutex_lock(&rcu_state.barrier_mutex);  \n                                                               // still see len == 2  \n                                                               // enqueue barrier callback  \n                                                               // to CPU1's rdp->cblist  \n                                                               rcu_segcblist_entrain()  \n                                                                   rcu_segcblist_add_len(1);  \n                                                                   // len == 3  \n                                 // decrement len  \n                                 rcu_segcblist_add_len(-2);  \n                             kthread_parkme()  \n  \n// CPU1's rdp->cblist len == 1  \n// Warn because there is  \n// still a pending barrier  \n// trigger warning  \nWARN_ON_ONCE(rcu_segcblist_n_cbs(&rdp->cblist));  \ncpus_read_unlock();  \n  \n                                                                // wait CPU1 to comes online and  \n                                                                // invoke barrier callback on  \n                                                                // CPU1 rdp's->cblist  \n                                                                wait_for_completion(&rcu_state.barrier_completion);  \n// deoffload CPU4  \ncpus_read_lock()  \n  rcu_barrier()  \n    mutex_lock(&rcu_state.barrier_mutex);  \n    // block on barrier_mutex  \n    // wait rcu_barrier() on  \n    // CPU3 to unlock barrier_mutex  \n    // but CPU3 unlock barrier_mutex  \n    // need to wait CPU1 comes online  \n    // when CPU1 going online will block on cpus_write_lock  \n  \nThe above scenario will not only trigger a WARN_ON_ONCE(), but also  \ntrigger a deadlock.  \n  \nThanks to nocb locking, a second racing rcu_barrier() on an offline CPU  \nwill either observe the decremented callback counter down to 0 and spare  \nthe callback enqueue, or rcuo will observe the new callback and keep  \nrdp->nocb_cb_sleep to false.  \n  \nTherefore check rdp->nocb_cb_sleep before parking to make sure no  \nf[...]", "creation_timestamp": "2024-12-27T15:59:48.000000Z"}