CVE-2026-72420 in Linux
Zusammenfassung
von VulDB • 15.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
md/raid5: Vermeidung von R5_Overlap-Racebedingungen beim Auflösen von Stripe-Batches
Ein KCSAN-Bericht meldet eine Racebedingung in break_stripe_batch_list() im Vergleich zu raid5_make_request(), die sh->dev[i].flags betrifft (einfacher Wort-Schreibzugriff vs. atomarer Bit-Operation)..
und .. ein mögliches Szenario ist:
CPU1 CPU2 break_stripe_batch_list(sh1) -> handle sh2 -> lock(sh2) -> sh2->batch_head = NULL -> unlock(sh2) -> test_and_clear_bit(R5_Overlap, sh2->dev[i].flags)
-> wake_up_bit(sh2->dev[i].flags)
raid5_make_request() -> add_all_stripe_bios(sh2) -> lock(sh2) -> stripe_bio_overlaps(sh2) gibt true zurück batch_head ist NULL, daher existiert neuer Bio-Überlapp auf sh2 -> wahr (true) -> set_bit(R5_Overlap, sh2->dev[i].flags)
-> unlock(sh2) -> wait_on_bit(sh2->dev[i].flags)
-> sh2->dev[i].flags = sh1->dev[i].flags & ~R5_Overlap
Kein wake_up_bit(), CPU2 könnte ewig in wait_on_bit() warten...
Behoben durch: - Erweiterung der Schutzzone. - Verwendung eines Snapshots des Geräte-Flags von batch_head, wenn keine held head_sh->stripe_lock vorliegt. - Verschieben von sh/head_sh->batch_head = NULL ans Ende der geschützten Zone, und jede gleichzeitige add_all_stripe_bios()-Operation ruft nun entweder: - sieht batch_head != null und wird durch stripe_bio_overlaps() unter dem Lock abgelehnt (kein R5_Overlap-Warten), oder - sieht batch_head == NULL erst nachdem dev[i].flags bereits gesetzt wurde und die vorherigen Warteoperationen auf R5_Overlap abgeschlossen sind.
KCSAN-Bericht: ================================================ BUG: KCSAN: data-race in break_stripe_batch_list / raid5_make_request
write (markiert) zu 0xffff8e89c8117548 von 8 Bytes durch Task 4042 auf CPU 0: raid5_make_request+0xea0/0x2930 md_handle_request+0x4a2/0xa40 md_submit_bio+0x109/0x1a0 __submit_bio+0x2ec/0x390 submit_bio_noacct_nocheck+0x457/0x710 submit_bio_noacct+0x2a7/0xc20 submit_bio+0x56/0x250 blkdev_direct_IO+0x54c/0xda0 blkdev_write_iter+0x38f/0x570 aio_write+0x22b/0x490 io_submit_one+0xa51/0xf70 __x
If you want to get best quality of vulnerability data, you may have to visit VulDB.