Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mISDN: corrige posible use after free en HFC_cleanup(). La ruta de eliminación de este módulo llama a del_timer(). Sin embargo, esa función no espera hasta que finalice el controlador del temporizador. Esto significa que es posible que el controlador del temporizador aún esté ejecutándose después de que haya finalizado la función de eliminación del controlador, lo que daría como resultado un use after free. Para solucionarlo, llame a del_timer_sync(), lo que garantiza que el controlador del temporizador haya finalizado y no pueda reprogramarse.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: zr364xx: corrige la pérdida de memoria en zr364xx_start_readpipe syzbot informó una pérdida de memoria en el controlador zr364xx. El problema estaba en la urb no liberada en caso de que fallara usb_submit_urb(). seguimiento: [] kmalloc include/linux/slab.h:561 [en línea] [] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [] zr364xx_start_readpipe+0x78/ 0x130 drivers/media/usb/zr364xx/zr364xx.c:1022 [] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [en línea] [] 0x851 drivers/media/ usb/zr364xx/zr364xx.c:1516 [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 []really_probe+0x159/0x500 controladores/base/dd.c:576

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/cma: Reparar pérdida de memoria rdma_resolve_route(). Reparar una pérdida de memoria cuando se llama a "mda_resolve_route() más de una vez en el mismo "rdma_cm_id". Esto es posible si cma_query_handler() desencadena el flujo RDMA_CM_EVENT_ROUTE_ERROR que devuelve la máquina de estado y permite volver a llamar a rdma_resolve_route().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: coresight: tmc-etf: Corrección global fuera de los límites en tmc_update_etf_buffer() confirmación 6f755e85c332 ("coresight: Agregar ayuda para insertar paquetes de sincronización") eliminado el final '\0' desde la matriz barrier_pkt y actualicé los sitios de llamadas como etb_update_buffer() para realizar comprobaciones adecuadas del tamaño de la barrera_pkt antes de leer, pero no se actualizó tmc_update_etf_buffer(), que todavía lee barrier_pkt más allá del tamaño de la matriz, lo que genera un error de KASAN fuera de los límites. Solucione este problema agregando una verificación del tamaño de barrier_pkt antes de acceder, como se hace en etb_update_buffer(). bug: KASAN: global fuera de los límites en tmc_update_etf_buffer+0x4b8/0x698 Lectura de tamaño 4 en la dirección ffffffd05b7d1030 por tarea perf/2629 Rastreo de llamadas: dump_backtrace+0x0/0x27c show_stack+0x20/0x2c dump_stack+0x11c/0x188 descripción+0x3c /0x4a4 __kasan_report+0x140/0x164 kasan_report+0x10/0x18 __asan_report_load4_noabort+0x1c/0x24 tmc_update_etf_buffer+0x4b8/0x698 etm_event_stop+0x248/0x2d8 etm_event_del+0x20/0x2c event_sched_out+0x214/0x6f0 group_sched_out+0xd0/0x270 ctx_sched_out+0x2ec/0x518 __perf_event_task_sched_out+0x4fc /0xe6c __schedule+0x1094/0x16a0 preempt_schedule_irq+0x88/0x170 arm64_preempt_schedule_irq+0xf0/0x18c el1_irq+0xe8/0x180 perf_event_exec+0x4d8/0x56c setup_new_exec+0x204/0x4 00 load_elf_binary+0x72c/0x18c0 search_binary_handler+0x13c/0x420 load_script+0x500/0x6c4 search_binary_handler+0x13c /0x420 exec_binprm+0x118/0x654 __do_execve_file+0x77c/0xba4 __arm64_compat_sys_execve+0x98/0xac el0_svc_common+0x1f8/0x5e0 el0_svc_compat_handler+0x84/0xb0 x10/0x50 La dirección del buggy pertenece a la variable: barrier_pkt+0x10/0x40 Estado de la memoria alrededor del buggy dirección: ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffd05b7d1000: 0 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03 ^ ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa ====== ==================================================== ==========

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wl1251: corrige posible desbordamiento del buffer en wl1251_cmd_scan. La función wl1251_cmd_scan llama a memcpy sin comprobar la longitud. Endurecer comprobando que el largo esté dentro del tamaño máximo permitido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: evita la sobrelectura y la corrupción de HDCP. En lugar de leer los 5 bytes deseados del campo de destino real, el código leía 8. Esto podría resultar en un archivo dañado. valor si los 3 bytes finales fueran distintos de cero, por lo tanto, utilice un búfer de rebote de tamaño adecuado e inicializado en cero, y lea solo 5 bytes antes de convertir a u64.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: virtio-net: Agregar validación para la longitud utilizada. Esto agrega validación para la longitud utilizada (puede provenir de un dispositivo que no es de confianza) para evitar la corrupción o pérdida de datos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: común: usb-conn-gpio: corrige la desreferencia del puntero NULL del cargador. Cuando se enciende el sistema con un cable OTG, la interrupción de IDDIG surge antes del registro del cargador, lo que provocará un puntero NULL desreferencia, solucione el problema registrando la fuente de alimentación antes de solicitar IDDIG/VBUS irq.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usx2y: No llamar a free_pages_exact() con dirección NULL A diferencia de otras funciones, no podemos pasar un puntero NULL a free_pages_exact(). Agregue una verificación NULL adecuada para evitar posibles Oops.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: misc: alcor_pci: corrige null-ptr-deref cuando no hay un puente PCI. Hay un problema con la función de verificación de capacidad ASPM (opcional). Un dispositivo se puede conectar directamente al complejo root; en este caso, bus->self(bridge) será NULL, por lo tanto, priv->parent_pdev es NULL. Dado que alcor_pci_init_check_aspm(priv->parent_pdev) verifica la capacidad ASPM del enlace PCI y completa parent_cap_off, que será utilizado más adelante por alcor_pci_aspm_ctrl() para encender/apagar dinámicamente el dispositivo, lo que podemos hacer aquí es evitar verificar la capacidad si estamos encendidos. el complejo raíz. Esto hará que pdev_cap_off sea 0 y alcor_pci_aspm_ctrl() simplemente regrese cuando se llame a Bring, deshabilitando efectivamente ASPM para el dispositivo. [1.246492] BUG: desreferencia del puntero NULL del kernel, dirección: 00000000000000c0 [1.248731] RIP: 0010:pci_read_config_byte+0x5/0x40 [1.253998] Seguimiento de llamadas: [1.254131]? alcor_pci_find_cap_offset.isra.0+0x3a/0x100 [alcor_pci] [ 1.254476] alcor_pci_probe+0x169/0x2d5 [alcor_pci]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc/libmasm/module: corrige dos use after free en ibmasm_init_one. En ibmasm_init_one, llama a ibmasm_init_remote_input_dev(). Dentro de ibmasm_init_remote_input_dev, mouse_dev y keybd_dev son asignados por input_allocate_device() y asignados a sp->remote.mouse_dev y sp->remote.keybd_dev respectivamente. En la rama de error err_free_devices de ibmasm_init_one, mouse_dev y keybd_dev se liberan mediante input_free_device() y devuelven un error. Luego, la ejecución se ejecuta en la rama de error error_send_message de ibmasm_init_one, donde se llama a ibmasm_free_remote_input_dev(sp) para cancelar el registro de sp->remote.mouse_dev y sp->remote.keybd_dev liberados. Mi parche agrega una etiqueta "error_init_remote" para manejar el error de ibmasm_init_remote_input_dev(), para evitar los errores de uaf.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: solución para evitar ejecuciónes en fsync_entry_slab por instancias de múltiples sistemas de archivos. Como informó syzbot, hay un problema de use after free durante la recuperación de f2fs: escritura de use after free en 0xffff88823bc16040 ( en kfence-#10): kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486 f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869 f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945 _bdev+0x26c /0x3a0 fs/super.c:1367 Legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2905 [en línea] path_mount+0x196f/0x2be0 fs /namespace.c:3235 do_mount fs/namespace.c:3248 [en línea] __do_sys_mount fs/namespace.c:3456 [en línea] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433 do_syscall_64+0x3f/0xb0 arch/x86/entry /common.c:47 Entry_SYSCALL_64_after_hwframe+0x44/0xae La causa principal es que varias instancias del sistema de archivos f2fs pueden acelerarse al acceder al puntero global fsync_entry_slab, lo que resulta en un problema de use after free del caché de slab, se corrige para iniciar/destruir este caché de slab solo una vez durante procedimiento de inicio/destrucción del módulo para evitar este problema.