https://vulnerability.circl.lu/sightings/feed 2026-05-07T22:44:52.580645+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent sightings. https://vulnerability.circl.lu/sighting/1aefc983-c48d-48c2-b27e-1eaa0e76a523/export 2026-05-07T22:44:52.968500+00:00 Automation user http://vulnerability.circl.lu/user/automation {"uuid": "1aefc983-c48d-48c2-b27e-1eaa0e76a523", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46704", "type": "seen", "source": "https://t.me/cvedetector/5561", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-46704 - Linux Kernel Workqueue: Data Race Vulnerability\", \n \"Content\": \"CVE ID : CVE-2024-46704 \nPublished : Sept. 13, 2024, 7:15 a.m. | 19\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nworkqueue: Fix spruious data race in __flush_work() \n \nWhen flushing a work item for cancellation, __flush_work() knows that it \nexclusively owns the work item through its PENDING bit. 134874e2eee9 \n(\"workqueue: Allow cancel_work_sync() and disable_work() from atomic \ncontexts on BH work items\") added a read of @work->data to determine whether \nto use busy wait for BH work items that are being canceled. While the read \nis safe when @from_cancel, @work->data was read before testing @from_cancel \nto simplify code structure: \n \n data = *work_data_bits(work); \n if (from_cancel && \n !WARN_ON_ONCE(data & WORK_STRUCT_PWQ) && (data & WORK_OFFQ_BH)) { \n \nWhile the read data was never used if !@from_cancel, this could trigger \nKCSAN data race detection spuriously: \n \n ================================================================== \n BUG: KCSAN: data-race in __flush_work / __flush_work \n \n write to 0xffff8881223aa3e8 of 8 bytes by task 3998 on cpu 0: \n instrument_write include/linux/instrumented.h:41 [inline] \n ___set_bit include/asm-generic/bitops/instrumented-non-atomic.h:28 [inline] \n insert_wq_barrier kernel/workqueue.c:3790 [inline] \n start_flush_work kernel/workqueue.c:4142 [inline] \n __flush_work+0x30b/0x570 kernel/workqueue.c:4178 \n flush_work kernel/workqueue.c:4229 [inline] \n ... \n \n read to 0xffff8881223aa3e8 of 8 bytes by task 50 on cpu 1: \n __flush_work+0x42a/0x570 kernel/workqueue.c:4188 \n flush_work kernel/workqueue.c:4229 [inline] \n flush_delayed_work+0x66/0x70 kernel/workqueue.c:4251 \n ... \n \n value changed: 0x0000000000400000 -> 0xffff88810006c00d \n \nReorganize the code so that @from_cancel is tested before @work->data is \naccessed. The only problem is triggering KCSAN detection spuriously. This \nshouldn't need READ_ONCE() or other access qualifiers. \n \nNo functional changes. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"13 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T09:36:00.000000Z"} 2024-09-13T09:36:00+00:00