{"uuid": "77aac787-7f49-4d3c-8057-820c82cde33f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-56654", "type": "seen", "source": "https://t.me/cvedetector/13778", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56654 - Linux Bluetooth RCU List Corruption Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-56654 \nPublished : Dec. 27, 2024, 3:15 p.m. | 32\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nBluetooth: hci_event: Fix using rcu_read_(un)lock while iterating  \n  \nThe usage of rcu_read_(un)lock while inside list_for_each_entry_rcu is  \nnot safe since for the most part entries fetched this way shall be  \ntreated as rcu_dereference:  \n  \n Note that the value returned by rcu_dereference() is valid  \n only within the enclosing RCU read-side critical section [1]_.  \n For example, the following is **not** legal::  \n  \n  rcu_read_lock();  \n  p = rcu_dereference(head.next);  \n  rcu_read_unlock();  \n  x = p->address; /* BUG!!! */  \n  rcu_read_lock();  \n  y = p->data; /* BUG!!! */  \n  rcu_read_unlock(); \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"27 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-27T16:51:12.000000Z"}