CVE-2024-46704 in Linux
Résumé
par VulDB • 20/06/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
workqueue : Correction d'une fausse course de données (data race) dans __flush_work()
Lors du vidage (flushing) d'un élément de travail pour annulation, __flush_work() sait qu'il possède exclusivement l'élément de travail via son bit PENDING. Le commit 134874e2eee9 (« workqueue : Autoriser cancel_work_sync() et disable_work() depuis des contextes atomiques sur les éléments de travail BH ») a ajouté une lecture de @work->data pour déterminer s'il faut utiliser un busy wait (attente active) pour les éléments de travail BH qui sont en cours d'annulation. Bien que la lecture soit sûre lorsque @from_cancel est vrai, @work->data était lu avant le test de @from_cancel afin de simplifier la structure du code :
data = *work_data_bits(work); if (from_cancel && !WARN_ON_ONCE(data & WORK_STRUCT_PWQ) && (data & WORK_OFFQ_BH)) {
Bien que les données lues n'aient jamais été utilisées si @from_cancel est faux, cela pouvait déclencher de manière erronée la détection des courses de données par KCSAN :
================================================================== BUG: KCSAN: data-race in __flush_work / __flush_work
write to 0xffff8881223aa3e8 of 8 bytes by task 3998 on cpu 0: instrument_write include/linux/instrumented.h:41 [inline]
___set_bit include/asm-generic/bitops/instrumented-non-atomic.h:28 [inline]
insert_wq_barrier kernel/workqueue.c:3790 [inline]
start_flush_work kernel/workqueue.c:4142 [inline]
__flush_work+0x30b/0x570 kernel/workqueue.c:4178 flush_work kernel/workqueue.c:4229 [inline]
...
read to 0xffff8881223aa3e8 of 8 bytes by task 50 on cpu 1: __flush_work+0x42a/0x570 kernel/workqueue.c:4188 flush_work kernel/workqueue.c:4229 [inline]
flush_delayed_work+0x66/0x70 kernel/workqueue.c:4251 ...
value changed: 0x0000000000400000 -> 0xffff88810006c00d
Réorganiser le code de sorte que @from_cancel soit testé avant l'accès à @work->data. Le seul problème est la détection erronée par KCSAN. Cela ne devrait pas nécessiter READ_ONCE() ou d'autres qualificateurs d'accès.
Aucun changement fonctionnel.
Once again VulDB remains the best source for vulnerability data.