{"uuid": "21c3887e-ff3d-4d5f-8cad-62fe4c6eb629", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57930", "type": "seen", "source": "https://t.me/cvedetector/15930", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57930 - Linux Kernel Array Dereference Vulnerability in Tracing\", \n  \"Content\": \"CVE ID : CVE-2024-57930 \nPublished : Jan. 21, 2025, 12:15 p.m. | 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ntracing: Have process_string() also allow arrays  \n  \nIn order to catch a common bug where a TRACE_EVENT() TP_fast_assign()  \nassigns an address of an allocated string to the ring buffer and then  \nreferences it in TP_printk(), which can be executed hours later when the  \nstring is free, the function test_event_printk() runs on all events as  \nthey are registered to make sure there's no unwanted dereferencing.  \n  \nIt calls process_string() to handle cases in TP_printk() format that has  \n\"%s\". It returns whether or not the string is safe. But it can have some  \nfalse positives.  \n  \nFor instance, xe_bo_move() has:  \n  \n TP_printk(\"move_lacks_source:%s, migrate object %p [size %zu] from %s to %s device_id:%s\",  \n            __entry->move_lacks_source ? \"yes\" : \"no\", __entry->bo, __entry->size,  \n            xe_mem_type_to_name[__entry->old_placement],  \n            xe_mem_type_to_name[__entry->new_placement], __get_str(device_id))  \n  \nWhere the \"%s\" references into xe_mem_type_to_name[]. This is an array of  \npointers that should be safe for the event to access. Instead of flagging  \nthis as a bad reference, if a reference points to an array, where the  \nrecord field is the index, consider it safe. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-21T13:37:00.000000Z"}