CVE-2024-56592

Linux çekirdeğinde aşağıdaki güvenlik açığı giderilmiştir: bpf: htab_unlock_bucket() işleminden sonra free_htab_elem() çağrılsın Haritaların htab yapısında, harita htab üzerinden kaldırıldığında, haritanın son referansını tutuyor olabilir. bpf_map_fd_put_ptr(), kaldırılan harita öğesinin kimliğini serbest bırakmak için bpf_map_free_id() fonksiyonunu çağıracaktır. Ancak, bpf_map_fd_put_ptr() bir bucket kilidi (raw_spin_lock_t) tutulurken çağrılır ve bpf_map_free_id() ise map_idr_lock (spinlock_t) kilidini almaya çalışır; bu durum aşağıdaki lockdep uyarısını tetikler: ============================= [ BUG: Invalid wait context ] 6.11.0-rc4+ #49 Not tainted ----------------------------- test_maps/4881 is trying to lock: ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70 other info that might help us debug this: context-{5:5} 2 locks held by test_maps/4881: #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270 #1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80 stack backtrace: CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... Call Trace: <TASK> dump_stack_lvl+0x6e/0xb0 dump_stack+0x10/0x20 __lock_acquire+0x73e/0x36c0 lock_acquire+0x182/0x450 _raw_spin_lock_irqsave+0x43/0x70 bpf_map_free_id.part.0+0x21/0x70 bpf_map_put+0xcf/0x110 bpf_map_fd_put_ptr+0x9a/0xb0 free_htab_elem+0x69/0xe0 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 bpf_map_update_value+0x266/0x380 __sys_bpf+0x21bb/0x36b0 __x64_sys_bpf+0x45/0x60 x64_sys_call+0x1b2a/0x20d0 do_syscall_64+0x5d/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Lockdep uyarısını düzeltmenin bir yolu, map_idr_lock için de raw_spinlock_t kullanmaktır. Ancak, bpf_map_alloc_id() fonksiyonu map_idr_lock kilidini aldıktan sonra idr_alloc_cyclic() fonksiyonunu çağırdığından, slab kilidi (s->cpu_slab->lock) hala bir spinlock olduğu için benzer bir lockdep uyarısı tetiklenecektir. map_idr_lock türünü değiştirmek yerine, sorun htab_put_fd_value() fonksiyonunun htab_unlock_bucket() işleminden sonra çağrılmasıyla çözülmüştür. Bununla birlikte, sadece htab_put_fd_value() çağrısının ertelenmesi yeterli değildir çünkü toplu silme işlemi sırasında haritaların htab yapısındaki eski harita işaretçileri saklanamaz. Bu nedenle, serbest bırakılacak bu öğelerin lru haritasına benzer şekilde birbirine bağlanabilmesi için free_htab_elem() çağrısının da ertelenmesi sağlanmıştır. ->map_fd_put_ptr için dört çağırıcı bulunmaktadır: (1) alloc_htab_elem() (htab_put_fd_value() aracılığıyla) Bu fonksiyon ->map_fd_put_ptr()'ı bir raw_spinlock_t altında çağırır. htab_put_fd_value() çağrısı basitçe htab_unlock_bucket() işleminden sonraya taşınamaz, çünkü eski öğe zaten htab->extra_elems içine yerleştirilmiştir. htab_unlock_bucket() işleminden hemen sonra yeniden kullanılabilir ve htab_unlock_bucket() sonrası yapılan htab_put_fd_value() çağrısı yeni eklenen öğeyi yanlışlıkla serbest bırakabilir. Bu nedenle, kilit açılmadan önce haritaların htab yapısındaki eski öğenin harita işaretçisi kaydedilmeli ve map_ptr kilit açıldıktan sonra serbest bırakılmalıdır. Eski öğedeki harita işaretçisinin yanı sıra, aynı işlem eski öğedeki özel alanlar için de uygulanmalıdır. (2) free_htab_elem() (htab_put_fd_value() aracılığıyla) Çağırıcıları arasında __htab_map_lookup_and_delete_elem(), htab_map_delete_elem() ve __htab_map_lookup_and_delete_batch() bulunur. htab_map_delete_elem() için, free_htab_elem() basitçe htab_unlock_bucket() işleminden sonra çağrılır. __htab_map_lookup_and_delete_batch() için, tıpkı lru haritasında olduğu gibi, serbest bırakılacak öğe node_to_free listesine bağlanır ve kilit açıldıktan sonra bu öğeler için free_htab_elem() çağrılır. Bu öğeler hash llist yapısından çıkarıldığı için batch_flink'in node_to_free bağlantısı olarak yeniden kullanılması güvenlidir. Haritaların htab yapısı lookup_and_delete işlemini desteklemediği için __htab_map_lookup_and_delete_elem() bu soruna sahip değildir, dolayısıyla mevcut haliyle korunmuştur.