CVE-2024-46704

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> workqueue: Fix spruious data race in __flush_work()<br /> <br /> When flushing a work item for cancellation, __flush_work() knows that it<br /> exclusively owns the work item through its PENDING bit. 134874e2eee9<br /> ("workqueue: Allow cancel_work_sync() and disable_work() from atomic<br /> contexts on BH work items") added a read of @work-&gt;data to determine whether<br /> to use busy wait for BH work items that are being canceled. While the read<br /> is safe when @from_cancel, @work-&gt;data was read before testing @from_cancel<br /> to simplify code structure:<br /> <br /> data = *work_data_bits(work);<br /> if (from_cancel &amp;&amp;<br /> !WARN_ON_ONCE(data &amp; WORK_STRUCT_PWQ) &amp;&amp; (data &amp; WORK_OFFQ_BH)) {<br /> <br /> While the read data was never used if !@from_cancel, this could trigger<br /> KCSAN data race detection spuriously:<br /> <br /> ==================================================================<br /> BUG: KCSAN: data-race in __flush_work / __flush_work<br /> <br /> write to 0xffff8881223aa3e8 of 8 bytes by task 3998 on cpu 0:<br /> instrument_write include/linux/instrumented.h:41 [inline]<br /> ___set_bit include/asm-generic/bitops/instrumented-non-atomic.h:28 [inline]<br /> insert_wq_barrier kernel/workqueue.c:3790 [inline]<br /> start_flush_work kernel/workqueue.c:4142 [inline]<br /> __flush_work+0x30b/0x570 kernel/workqueue.c:4178<br /> flush_work kernel/workqueue.c:4229 [inline]<br /> ...<br /> <br /> read to 0xffff8881223aa3e8 of 8 bytes by task 50 on cpu 1:<br /> __flush_work+0x42a/0x570 kernel/workqueue.c:4188<br /> flush_work kernel/workqueue.c:4229 [inline]<br /> flush_delayed_work+0x66/0x70 kernel/workqueue.c:4251<br /> ...<br /> <br /> value changed: 0x0000000000400000 -&gt; 0xffff88810006c00d<br /> <br /> Reorganize the code so that @from_cancel is tested before @work-&gt;data is<br /> accessed. The only problem is triggering KCSAN detection spuriously. This<br /> shouldn&amp;#39;t need READ_ONCE() or other access qualifiers.<br /> <br /> No functional changes.