CVE-2024-26727

Linux kernel'de aşağıdaki güvenlik açığı giderilmiştir: btrfs: yeni oluşturulan alt birim (subvolume) zaten okunduysa ASSERT() yapmayın [HATA] Alt birim oluşturma sırasında ASSERT() tarafından tetiklenen bir syzbot çökmesi mevcuttur: assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319 ------------[ cut here ]------------ kernel BUG at fs/btrfs/disk-io.c:1319! invalid opcode: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60 <TASK> btrfs_get_new_fs_root+0xd3/0xf0 create_subvol+0xd02/0x1650 btrfs_mksubvol+0xe95/0x12b0 __btrfs_ioctl_snap_create+0x2f9/0x4f0 btrfs_ioctl_snap_create+0x16b/0x200 btrfs_ioctl+0x35f0/0x5cf0 __x64_sys_ioctl+0x19d/0x210 do_syscall_64+0x3f/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace 0000000000000000 ]--- [NEDEN] create_subvol() sırasında, yeni oluşturulan alt birim için kök öğesi eklendikten sonra, bu alt birimin btrfs_root bilgisini almak için btrfs_get_new_fs_root() fonksiyonunu tetikleriz. Buradaki fikir, alt birim için önceden tahsis edilmiş anonim bir aygıt numarasına sahip olduğumuzdur; böylece bunu yeni alt birime atayabiliriz. Ancak, backref yürütme gibi işlemlerin yeni alt birimi okumasını engelleyen hiçbir şey yoktur. Eğer bu durum btrfs_get_new_fs_root() çağrılmadan önce gerçekleşirse, alt birim okunmuş olur ve halihazırda yeni bir anonim aygıt numarası atanmış olur. Bu durumda, söz konusu alt birimin (henüz dosya sisteminden erişilebilir değilken) hiç kimse tarafından okunmamasını beklediğimiz için ASSERT() tetiklenir. Fakat backref yürütme gibi işlemlerin alt birim üzerinde okumayı tetiklemesi hala mümkündür. Dolayısıyla, ASSERT() üzerindeki varsayımımız başlangıçta yanlıştır. [ÇÖZÜM] ASSERT() kaldırılarak, sadece @anon_dev serbest bırakılıp 0'a sıfırlanarak işleme devam edilmesiyle sorun giderilmiştir. Eğer alt birim ağacı başka bir işlem tarafından okunursa, zaten yeni bir anon_dev atanmış olması gerekir; bu nedenle yalnızca önceden tahsis edilen numaranın serbest bırakılması yeterlidir.