CVE-2024-41067

Linux çekirdeğinde aşağıdaki güvenlik açığı giderilmiştir: btrfs: scrub: RST arama hatasını doğru şekilde işle [HATA] Zorunlu RST özelliği ile btrfs/060 çalıştırıldığında, scrub_read_endio() içerisindeki şu ASSERT() ifadesi çökmeye neden oluyordu: ASSERT(sector_nr < stripe->nr_sectors); Bundan önce, ilgili aralık için RST girdisi bulunamadığından btrfs_get_raid_extent_offset() kaynaklı bir ağaç dökümü (tree dump) oluşmaktaydı. [NEDEN] scrub_submit_extent_sector_read() içerisinde, her yeni bbio tahsis edildiğinde, scrub hedefini kapsayan bir RST aralığı olduğundan emin olmak için hemen btrfs_map_block() çağrılıyordu. Ancak btrfs_map_block() başarısız olursa, bbio için hemen endio çağrılıyordu; bbio yeni tahsis edilmiş olduğu için tamamen boştu. Ardından scrub_read_endio() içerisinde, sektör numarasını bulmak için bvec'ler taranıyordu (çünkü bio alt katmanlara gönderildiyse bi_sector artık güvenilir değildir). Bio boş olduğu için bu tür bir bvec yinelemesi sektöre uygun herhangi bir sektör bulamıyor ve sector_nr == stripe->nr_sectors değerini döndürerek ASSERT() ifadesini tetikliyor. [ÇÖZÜM] Yeni bir bbio tahsis ettikten sonra btrfs_map_block() çağırmak yerine, önce btrfs_map_block() çağrılır. btrfs_map_block() çağırmadaki tek amacımız yalnızca stripe_len değerini güncellemek olduğundan, bunu btrfs_alloc_bio() işleminden sonra yapmaya gerçekten gerek yoktur. Bu yeni zamanlama, boş bbio işleme sorununu tamamen ortadan kaldırır ve aslında eski koddaki olası bir yarış durumunu (race window) düzeltir; eğer gönderim iş parçacığı pending_io'nun tek sahibiyse, scrub asla tamamlanmıyordu (çünkü pending_io sayacı azaltılmamıştı). Yine de RST arama hatasının temel nedeni hala ele alınmalıdır.