CVE-2026-90264

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: btrfs: OE yarışmalarını önlemek için her zaman sıralı extent'lerin beklenmesi [HATA] Syzbot, aynı aralık için çakışan OE'lerin olabileceğine dair bir hata bildirmiştir: BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object alrea[ 179.162726][ T6897] BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object already exists) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ordered-data.c:264! Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026 RIP: 0010:btrfs_alloc_ordered_extent+0x943/0xad0 Call Trace: <TASK> cow_file_range+0x744/0x12a0 fallback_to_cow+0x5ea/0xa00 run_delalloc_nocow+0x110c/0x17a0 btrfs_run_delalloc_range+0xbe4/0x1c20 writepage_delalloc+0x104d/0x1ba0 btrfs_writepages+0x1667/0x28b0 do_writepages+0x338/0x560 filemap_fdatawrite_range+0x1f2/0x300 btrfs_fdatawrite_range+0x54/0xf0 btrfs_direct_write+0x6a0/0xc30 btrfs_do_write_iter+0x329/0x790 do_iter_readv_writev+0x624/0x8d0 vfs_writev+0x34c/0x990 __se_sys_pwritev2+0x17a/0x2a0 do_syscall_64+0x174/0x580 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> ---[ end trace 0000000000000000 ]--- [NEDEN] ff66fe666233 ("btrfs: fix incorrect buffered IO fallback for append direct writes") commit'inden itibaren, eğer doğrudan IO kısa sürede tamamlanırsa, tamponlu geri dönüş sırasında ekleme yazımlarına uyulabilmesi için isize değerini orijinal haline döndürüyoruz. Normalde, mevcut herhangi bir sıralı extent'yi beklemek için tamponlu geri yazma sırasında lock_and_cleanup_extent_if_need() fonksiyonuna güveniyoruz. Ancak bu sıralı extent bekleme işlemi yalnızca start_pos değeri isize içerisindeyse gerçekleşir. Başarısız olan doğrudan IO sırasında isize değerini geri döndürdüğümüz için herhangi bir sıralı extent beklenmeyecektir. Bu durum, doğrudan IO OE'sinin hala ağaçta olduğu, tamamlandığı ancak henüz kaldırılmadığı ve ardından tamponlu yazım için OE eklediğimiz bir yarış durumuna yol açarak yukarıdaki çökmeye neden olabilir. [ÇÖZÜM] Geri döndürülen isize durumunu yönetmek için OE bekleme işlemini koşulsuz hale getirin. Ayrıca lock_and_cleanup_extent_if_need() artık ya extent'leri kilitliyor ya da -EAGAIN döndürdüğü için, extent kilitleme yapılmayan durumları yöneten dalları kaldırın ve "_if_need" son ekini kaldırmak için yeniden adlandırın. Aşağıdaki mikro karşılaştırma, `xfs_io -f -c "pwrite 0 1m"` iş yükü ile btrfs_buffered_write() için çalışma süresi farkını göstermektedir; tüm değerler nanosaniye cinsinden ortalama çalışma süreleridir. function runtime | before | after -----------------------------------+-------------+--------------- lock_and_cleanup_extent_if_need() | 58.2 | 183.0 btrfs_buffered_write() | 2115.6 | 2973.3 btrfs_buffered_write()'ın genel çalışma süresi hala oldukça düşüktür (hala 3 mikrosaniyenin altında), ek maliyetin kabul edilebilir olduğunu söyleyebilirim. Bu sorunu çözmenin alternatif bir yolu, isize geri döndürme işleminin yapıldığı iomap_end() sırasında sıralı extent'leri beklemektir. Ancak bu çözüm, nowait gereksinimini bozacaktır; çünkü eğer bir nowait doğrudan IO kısa sürede tamamlanırsa, OE'leri koşulsuz olarak beklemek zorundayız, aksi takdirde bir sonraki ekleme tamponlu IO yine aynı sorunla karşılaşabilir. Bu nedenle bekleme maliyetini tamponlu yazmaya taşımamız gerekiyor, ancak en azından kod biraz daha düzenli hale gelmiş oldu.