Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/iwcm: Corrección del use-after-free de objetos de trabajo después de la destrucción de cm_id El commit 59c68ac31e15 ("iw_cm: liberar recursos de cm_id en la última desreferencia") simplificó la gestión de recursos de cm_id al liberar cm_id una vez que se eliminaron todas las referencias a cm_id. Las referencias se eliminan al completarse los controladores de eventos iw_cm o cuando la aplicación destruye cm_id. Este commit introdujo la condición de use-after-free donde el objeto cm_id_private aún podría estar en uso por los controladores de eventos durante la destrucción de cm_id. El commit aee2424246f9 ("RDMA/iwcm: Corrección de un use-after-free relacionado con la destrucción de los ID de CM") abordó este use-after-free al vaciar todos los trabajos pendientes en la destrucción de cm_id. Sin embargo, aún quedaba otra posibilidad de use-after-free. Esto sucede con los objetos de trabajo asignados para cada cm_id_priv dentro de alloc_work_entries() durante la creación de cm_id, y posteriormente se liberan en dealloc_work_entries() una vez que se eliminan todas las referencias a cm_id. Si la última referencia de cm_id se decrementa en el manejador de eventos work, el objeto de trabajo para el trabajo en sí se elimina y causa el siguiente ERROR de use-after-free: ERROR: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Este error se puede reproducir repitiendo el caso de prueba blktests nvme/061 para el transporte rdma y el controlador siw. Para evitar el uso posterior a la liberación de objetos de trabajo cm_id_private, asegúrese de que la última referencia a cm_id se decremente no en los trabajos del controlador de eventos, sino en el contexto de destrucción de cm_id. Para ello, mo ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipc: corrección para proteger las búsquedas IPCS mediante RCU. syzbot informó del descubrimiento de una vulnerabilidad de use-after-free, [0] [0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/ idr_for_each() está protegido por rwsem, pero esto no es suficiente. Si no está protegido por la región crítica de lectura de RCU, cuando idr_for_each() llama a radix_tree_node_free() mediante call_rcu() para liberar la estructura radix_tree_node, el nodo se liberará inmediatamente y, al leer el siguiente nodo en radix_tree_for_each_slot(), se podrá leer la memoria ya liberada. Por lo tanto, necesitamos agregar código para asegurarnos de que idr_for_each() esté protegido dentro de la región crítica de lectura de RCU cuando lo llamamos en shm_destroy_orphaned().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: La comprobación de rcu_read_lock_trace_held() en bpf_map_lookup_percpu_elem() también está disponible para programas bpf en suspensión. Cuando BPF JIT está deshabilitado o en un host de 32 bits, bpf_map_lookup_percpu_elem() no se incluirá en línea. Su uso en un programa bpf en suspensión activará la advertencia en bpf_map_lookup_percpu_elem(), ya que el programa bpf solo mantiene el bloqueo rcu_read_lock_trace. Por lo tanto, se debe agregar la comprobación omitida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: Fix null-ptr-deref in jfs_ioc_trim [Informe de Syzkaller] Oops: fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000087: 0000 [#1 KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f] CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted 6.13.0-rc6-gfbfd64d25c7a-dirty #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Sched_ext: serialise (enabled+all), task: runnable_at=-30ms RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body+0x61/0xb0 ? die_addr+0xb1/0xe0 ? exc_general_protection+0x333/0x510 ? asm_exc_general_protection+0x26/0x30 ? jfs_ioc_trim+0x34b/0x8f0 jfs_ioctl+0x3c8/0x4f0 ? __pfx_jfs_ioctl+0x10/0x10 ? __pfx_jfs_ioctl+0x10/0x10 __se_sys_ioctl+0x269/0x350 ? __pfx___se_sys_ioctl+0x10/0x10 ? do_syscall_64+0xfb/0x210 do_syscall_64+0xee/0x210 ? syscall_exit_to_user_mode+0x1e0/0x330 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe51f4903ad Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d RSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903ad RDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640 R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Kernel panic - not syncing: Fatal exception [ Analysis ] Creemos que hemos encontrado un error de concurrencia en el módulo `fs/jfs` que da como resultado una desreferencia de puntero nulo. Existe un problema estrechamente relacionado que ya se ha corregido: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234... pero, lamentablemente, el parche aceptado parece seguir siendo susceptible a una desreferencia de puntero nulo en algunas intercalaciones. Creemos que para desencadenar el error, `JFS_SBI(ipbmap->i_sb)->bmap` se establece en NULL en `dbFreeBits` y luego se desreferencia en `jfs_ioc_trim`. Este error es poco frecuente en circunstancias normales, pero se puede desencadenar desde un programa syz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Evite la división por cero inicializando el paso ficticio en 1 [Por qué] Si los valores ficticios en `populate_dummy_dml_surface_cfg()` no se actualizan, pueden provocar una división por cero en los llamadores posteriores como CalculateVMAndRowBytes() [Cómo] Inicialice el valor ficticio en un valor para evitar la división por cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: se corrige la sobrescritura del archivo uprobe al expandir vma. Serie de parches "Corregir la sobrescritura del archivo uprobe al expandir vma". Este parche (de 4): Se detectó una alerta de error generada por Syzkaller: Error: Estado incorrecto del contador RSS mm:00000000b4a60fca tipo:MM_ANONPAGES val:1. Se puede reproducir con los siguientes pasos: 1. Registrar uprobe en el archivo con desplazamiento cero. 2. Asignar el archivo con mmap en el desplazamiento cero: addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0); 3. Asignar con mremap parte de vma1 al nuevo vma2: addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE); 4. mremap de vuelta a la dirección original 1: mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1); En el paso 3, el rango vma1 [addr1, addr1 + 4096] se reasignará a la nueva vma2 con rango [addr2, addr2 + 8192] y se reasignará la página uprobe anon de vma1 a vma2, luego desasignará el rango vma1 [addr1, addr1 + 4096]. En el paso 4, el rango vma2 [addr2, addr2 + 4096] se reasignará de nuevo al rango addr [addr1, addr1 + 4096]. Dado que el rango de direcciones [addr1 + 4096, addr1 + 8192] aún asigna el archivo, se requerirá vma_merge_new_range para expandir el rango y luego ejecutar uprobe_mmap en vma_complete. Dado que el desplazamiento de la página de la vma fusionada también tiene desplazamiento cero, se instalará uprobe anon page en la vma fusionada. Sin embargo, el siguiente paso `move_page_tables`, que usa `set_pte_at` para reasignar la pte de uprobe vma2 a la vma fusionada, sobrescribirá la nueva pte de uprobe en la vma fusionada y la dejará huérfana. Dado que la pte de uprobe se reasignará a la vma fusionada, podemos eliminar uprobe_mmap innecesario al fusionar la vma. Este problema se encontró por primera vez en linux-6.6.y y también existe en la comunidad syzkaller: https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: Se comprueba si la comprobación de añadir NULL en la página automount_fullpath contiene valores nulos en __build_path_from_dentry_optional_prefix cuando tcon->origin_fullpath no está configurado. Sin embargo, la comprobación no se encuentra disponible cuando sí lo está. Se ha añadido una comprobación para evitar una posible desreferencia de punteros NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_set_pipapo: fijar el tamaño máximo del contenedor de mapas a INT_MAX. De lo contrario, es posible que se active WARN_ON_ONCE en __kvmalloc_node_noprof() al redimensionar la tabla hash porque __GFP_NOWARN no está configurado. Similar a: b541ba7d1f5a ("netfilter: conntrack: fijar el tamaño máximo de la tabla hash a INT_MAX")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: se corrige la lectura de array-index-out-of-bounds en add_missing_indices. El stbl es s8, pero debe contener desplazamientos en la ranura, que pueden ir de 0 a 127. Se añadió una comprobación de límite para ese error y se devuelve -EIO si la comprobación falla. También se hace que jfs_readdir devuelva un error si add_missing_indices devuelve un error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: corrige la doble liberación en delayed_free La doble liberación podría ocurrir en la siguiente ruta. exfat_create_upcase_table() exfat_create_upcase_table() : devolver error exfat_free_upcase_table() : liberar ->vol_utbl exfat_load_default_upcase_table : devolver error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- doble liberación Este parche establece ->vol_util como NULL después de liberarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbcon: Asegúrese de que modelist no esté configurado en una consola no registrada Parece que intentar escribir en el nodo sysfs "store_modes" entrará en conflicto con las consolas no registradas: UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28 index -1 is out of range for type 'fb_info *[32]' ... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439 static struct fb_info *fbcon_registered_fb[FB_MAX]; ... static signed char con2fb_map[MAX_NR_CONSOLES]; ... static struct fb_info *fbcon_info_from_console(int console) ... return fbcon_registered_fb[con2fb_map[console]]; Si con2fb_map contiene un valor de -1, la situación podría fallar. En su lugar, se devuelve NULL, ya que quienes llaman a fbcon_info_from_console() intentan comparar con punteros "info" existentes, por lo que la gestión de errores debería funcionar correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Se solucionó una fuga de memoria debido a la asignación múltiple de rx_stats. rx_stats para cada arsta se asigna al añadir una estación. arsta->rx_stats se liberará al eliminar una estación. Se producen asignaciones redundantes cuando se añade la misma estación varias veces. Esto provoca que ath12k_mac_station_add() se invoque varias veces y que rx_stats se asigne cada vez. Como resultado, se producen fugas de memoria. Evite las asignaciones múltiples de rx_stats cuando ath12k_mac_station_add() se invoque repetidamente comprobando si rx_stats ya está asignado antes de volver a asignarlo. Asigne arsta->rx_stats si arsta->rx_stats es NULL, respectivamente. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3