CVE-2023-54157

Linux kernel-də aşağıdakı zəiflik aradan qaldırılmışdır: binder: munmap() ilə yarış vəziyyətində (race condition) alloc->vma-nın UAF xətasının düzəldilməsi [ cmllamas: 5.10 stable versiyasındakı 015ac18be7de ("binder: fix UAF of alloc->vma in race with munmap()") commit-indən təmiz ön yönləndirmə. Liam tərəfindən qeyd edildiyi kimi, a43cfc87caaf ("android: binder: stop saving a pointer to the VMA") commit-inin geri qaytarılmasından sonra bu, mainline-də tələb olunur. Commit loqu və teqləri bunu əks etdirəcək şəkildə dəyişdirilmişdir. ] 720c24192404 ("ANDROID: binder: change down_write to down_read") commit-ində binder, binder_update_page_range() daxilində alloc->vma-nı qorumaq üçün mmap oxuma kilidinin (read lock) kifayət etdiyini fərz etmişdi. Bu, dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") commit-inə qədər doğru idi; həmin commit artıq munmap()-də vma-nı rbtree-dən ayırdıqdan sonra mmap_lock-u aşağı dərəcəyə endirir. Daha sonra yalnız oxuma kilidi saxlanıldığı halda vma-nın sökülməsi və azad edilməsi prosesi davam edir. Bu o deməkdir ki, binder_update_page_range()-də alloc->vma-ya girişlər indi munmap()-dəki vm_area_free() ilə yarış vəziyyətinə düşəcək və aşağıdakı KASAN izində göstərildiyi kimi UAF-a səbəb ola bilər: ================================================================== BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0 Read of size 8 at addr ffff16204ad00600 by task server/558 CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x2a0 show_stack+0x18/0x2c dump_stack+0xf8/0x164 print_address_description.constprop.0+0x9c/0x538 kasan_report+0x120/0x200 __asan_load8+0xa0/0xc4 vm_insert_page+0x7c/0x1f0 binder_update_page_range+0x278/0x50c binder_alloc_new_buf+0x3f0/0xba0 binder_transaction+0x64c/0x3040 binder_thread_write+0x924/0x2020 binder_ioctl+0x1610/0x2e5c __arm64_sys_ioctl+0xd4/0x120 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 Allocated by task 559: kasan_save_stack+0x38/0x6c __kasan_kmalloc.constprop.0+0xe4/0xf0 kasan_slab_alloc+0x18/0x2c kmem_cache_alloc+0x1b0/0x2d0 vm_area_alloc+0x28/0x94 mmap_region+0x378/0x920 do_mmap+0x3f0/0x600 vm_mmap_pgoff+0x150/0x17c ksys_mmap_pgoff+0x284/0x2dc __arm64_sys_mmap+0x84/0xa4 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 Freed by task 560: kasan_save_stack+0x38/0x6c kasan_set_track+0x28/0x40 kasan_set_free_info+0x24/0x4c __kasan_slab_free+0x100/0x164 kasan_slab_free+0x14/0x20 kmem_cache_free+0xc4/0x34c vm_area_free+0x1c/0x2c remove_vma+0x7c/0x94 __do_munmap+0x358/0x710 __vm_munmap+0xbc/0x130 __arm64_sys_munmap+0x4c/0x64 el0_svc_common.constprop.0+0xac/0x270 do_el0_svc+0x38/0xa0 el0_svc+0x1c/0x2c el0_sync_handler+0xe8/0x114 el0_sync+0x180/0x1c0 [...] ================================================================== Yuxarıdakı yarış vəziyyətinin qarşısını almaq üçün binder_update_page_range() daxilində yenidən mmap yazma kilidindən (write lock) istifadəyə qayıdılır. Mmap kilidi mübahisələrinin (contention) artacağı gözlənilə bilər. Lakin binder onsuz da bu çağırışları yuxarı səviyyəli alloc->mutex vasitəsilə ardıcıl edir. Həmçinin, binder benchmark testləri zamanı heç bir performans təsiri müşahidə edilməmişdir.