Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/region: corrige la desreferencia del puntero null para restablecer el decodificador. No todos los decodificadores tienen una devolución de llamada de reinicio. La especificación CXL permite que un puente de host con un único puerto raíz no tenga decodificadores HDM explícitos. Actualmente, el controlador de región supone que no hay ninguno. Como tal, el núcleo CXL crea una instancia de decodificador de paso especial sin una devolución de llamada de confirmación/restablecimiento. Antes de este parche, la devolución de llamada ->reset() se llamaba incondicionalmente al llamar a cxl_region_decode_reset. Por lo tanto, una configuración con 1 puente de host, 1 puerto raíz y un dispositivo CXL tipo 3 conectado directamente o varios dispositivos CXL tipo 3 conectados a puertos descendentes de un conmutador puede provocar una desreferencia de puntero null. Antes de la solución, se observaba un fallo del kernel cuando destruíamos la región y se restablecía un decodificador de paso. El problema se puede reproducir como se muestra a continuación: 1) cree una región con una configuración CXL que incluya un HB con un único puerto raíz bajo el cual se conecta directamente un memdev. 2) destruir la región con cxl destroy-region regionX -f.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: single: corrige una posible desreferencia NULL. Se agregó la verificación de la "función" del puntero en pcs_set_mux(). pinmux_generic_get_function() puede devolver NULL y se eliminó la referencia al puntero "función" sin compararlo con NULL. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: switch: soluciona una posible fuga de memoria en ice_add_adv_recipe(). Cuando ice_add_special_words() falla, el 'rm' no se libera, lo que provocará una pérdida de memoria. Solucione este problema yendo a la etiqueta 'err_unroll'. Compilación probada únicamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/radeon: corrige una posible desreferencia del puntero null. En radeon_fp_native_mode(), el valor de retorno de drm_mode_duplicate() se asigna al modo, lo que conducirá a una desreferencia del puntero NULL en caso de falla de drm_mode_duplicate(). Agregue una marca para evitar npd. También se verifica el estado de falla de drm_cvt_mode() en la otra ruta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: corrige la advertencia del kernel al enviar un mensaje SYN Al enviar un mensaje SYN, se observa este seguimiento de la pila del kernel: ... [ 13.396352] RIP: 0010:_copy_from_iter+0xb4/0x550 . .. [ 13.398494] Seguimiento de llamadas: [ 13.398630] [ 13.398630] ? __alloc_skb+0xed/0x1a0 [13.398630] tipc_msg_build+0x12c/0x670 [tipc] [13.398630]? shmem_add_to_page_cache.isra.71+0x151/0x290 [13.398630] __tipc_sendmsg+0x2d1/0x710 [tipc] [13.398630] ? tipc_connect+0x1d9/0x230 [tipc] [13.398630]? __local_bh_enable_ip+0x37/0x80 [13.398630] tipc_connect+0x1d9/0x230 [tipc] [13.398630]? __sys_connect+0x9f/0xd0 [ 13.398630] __sys_connect+0x9f/0xd0 [ 13.398630] ? preempt_count_add+0x4d/0xa0 [13.398630]? fpregs_assert_state_consistent+0x22/0x50 [ 13.398630] __x64_sys_connect+0x16/0x20 [ 13.398630] do_syscall_64+0x42/0x90 [ 13.398630] Entry_SYSCALL_64_after_hwframe+0x63/0xcd Es porque la confirmación 41dad905e5a ("iov_iter: comprobaciones más sensatas para intentar copiar hacia/desde el iterador") ha introducido una verificación de cordura para copiar desde/hacia el iterador iov. La falta de dirección de copia desde el punto de vista del iterador conduciría a un seguimiento de la pila del kernel como se muestra arriba. Esta confirmación soluciona este problema al inicializar el iterador iov con la dirección de copia correcta al enviar SYN o ACK sin datos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: use un búfer de rebote para copiar skb->mark syzbot encontró que las compilaciones arm64 fallarían en sock_recv_mark() cuando CONFIG_HARDENED_USERCOPY=y x86 y powerpc no detectan el problema porque definen user_access_begin . Esto se manejará en un parche diferente, porque falta check_object_size(). Solo los datos de skb->cb[] se pueden copiar directamente hacia/desde el espacio de usuario, como se explica en la confirmación 79a8a642bf05 ("net: Lista blanca del campo skbuff_head_cache "cb") El informe de syzbot fue: copia de usuario: intento de exposición de la memoria del kernel detectado desde SLUB objeto 'skbuff_head_cache' (desplazamiento 168, tamaño 4)! ------------[ cortar aquí ]------------ ¡ERROR del kernel en mm/usercopy.c:102! Error interno: Ups - ERROR: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 4410 Comm: syz-executor533 No contaminado 6.2.0-rc7-syzkaller-17907-g2d3827b3f393 #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 21/01/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: usercopy_abort+0x90/0x94 mm/usercopy.c:90 lr: usercopy_abort+0x90/0x94 mm/usercopy.c:90 sp: ffff80000fb9b9a0 x29: ffff80000fb9b9b0 x28: ffff0000c6073400 x27: 0000000020001a00 x26: 0000000000000014 5: ffff80000cf52000 x24: ffffc0000000000 x23: 05ffc00000000200 x22: ffffc000324bf80 x21: ffff0000c92fe1a8 x20: 0000000000000001 x19: 00000004 x18: 0000000000000000 x17: 656a626f2042554c x16: ffff0000c6073dd0 x15: ffff80000dbd2118 x14: ffff0000c6073400 x13: 00000000ffffffff x12: 073400 x11: ff808000081bbb4c x10: 0000000000000000 x9: 7b0572d7cc0ccf00 x8: 7b0572d7cc0ccf00 x7: ffff80000bf650d4 x6: 0000000000000000 x5: 0000000000000001 x4: 0000000000000001 x3: 0000000000000000 x2: ffff0001fefbff08 x1 : 0000000100000000 x0 : 000000000000006c Rastreo de llamadas: usercopy_abort+0x90/0x94 mm/usercopy.c:90 __check_heap_object+0xa8/0x100 mm/slub.c:4761 check_heap_object mm/usercopy.c:196 __check_object _tamaño+0x208/0x6b8 mm/ usercopy.c:251 check_object_size include/linux/thread_info.h:199 [en línea] __copy_to_user include/linux/uaccess.h:115 [en línea] put_cmsg+0x408/0x464 net/core/scm.c:238 sock_recv_mark net/socket. c:975 [en línea] __sock_recv_cmsgs+0x1fc/0x248 net/socket.c:984 sock_recv_cmsgs include/net/sock.h:2728 [en línea] paquete_recvmsg+0x2d8/0x678 net/packet/af_packet.c:3482 ____sys_recvmsg+0x1 10/0x3a0 ___sys_recvmsg net/socket.c:2737 [en línea] __sys_recvmsg+0x194/0x210 net/socket.c:2767 __do_sys_recvmsg net/socket.c:2777 [en línea] __se_sys_recvmsg net/socket.c:2774 [en línea] 64_sys_recvmsg+0x2c/0x3c net/socket.c:2774 __invoke_syscall arch/arm64/kernel/syscall.c:38 [en línea] invoke_syscall+0x64/0x178 arch/arm64/kernel/syscall.c:52 el0_svc_common+0xbc/0x180 arch/arm64/kernel/syscall .c:142 do_el0_svc+0x48/0x110 arch/arm64/kernel/syscall.c:193 el0_svc+0x58/0x14c arch/arm64/kernel/entry-common.c:637 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry -common.c:655 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591 Código: 91388800 aa0903e1 f90003e8 94e6d752 (d4210000)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: openvswitch: corrige una posible pérdida de memoria en ovs_meter_cmd_set() old_meter debe estar libre después de desconectarlo, independientemente de si el nuevo medidor se conectó correctamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/usb: kalmia: No pasar act_len en la ruta de error usb_bulk_msg syzbot informó que act_len en kalmia_send_init_packet() no está inicializado al pasarlo a la primera ruta de error usb_bulk_msg. Jiri Pirko señaló que no tiene sentido pasarlo en la ruta de error y que el valor que se imprimiría en la segunda ruta de error sería el valor de act_len de la primera llamada a usb_bulk_msg.[1] Con esto en mente, simplemente no pasemos act_len a las rutas de error usb_bulk_msg. 1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: freezer,umh: Fix call_usermode_helper_exec() vs SIGKILL .Tetsuo-San notó que la confirmación f5d39b020809 ("freezer,sched: Rewrite core freezer logic") rompió call_usermodehelper_exec() para el caso KILLABLE. Específicamente, se pasó por alto que el segundo wait_for_completion() incondicional no era opcional y garantiza que la finalización en la pila no se utilice antes de salir del alcance.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige el desbordamiento en los cálculos de la posición del segundo superbloque. La macro NILFS_SB2_OFFSET_BYTES, que calcula la posición del segundo superbloque, sufre un desbordamiento cuando el tamaño del dispositivo del argumento es inferior a 4096 bytes. Por lo tanto, al utilizar esta macro, es necesario comprobar de antemano que el tamaño del dispositivo no sea inferior a un límite inferior, o al menos que no se produzca un desbordamiento insuficiente. La implementación actual de nilfs2 carece de esta verificación, lo que provoca un acceso a bloques fuera de los límites al montar dispositivos de menos de 4096 bytes: error de E/S, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0 ): no se puede leer el superbloque secundario (tamaño de bloque = 1024) Además, al intentar cambiar el tamaño del sistema de archivos a un tamaño inferior a 4096 bytes, este desbordamiento se produce en nilfs_resize_fs(), pasando una gran cantidad de segmentos a nilfs_sufile_resize(), corrompiendo parámetros como como el número de segmentos en supermanzanas. Esto provoca iteraciones de bucle excesivas en nilfs_sufile_resize() durante un cambio de tamaño de ioctl posterior, lo que provoca que el semáforo ns_segctor_sem se bloquee durante mucho tiempo y cuelgue el hilo de escritura: INFORMACIÓN: tarea segctord:5067 bloqueada durante más de 143 segundos. No contaminado 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:segctord estado:D pila:23456 pid:5067 ppid:2 banderas:0x00004000 Seguimiento de llamadas: context_switch kernel/sched/core.c:5293 [en línea] __schedule+0x1409/0x43f0 kernel/sched/core.c: 6606 programación+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs /nilfs2/segmento. c:2486 [en línea] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 ... Seguimiento de llamadas: folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [en línea] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 _get_segment_usage_block fs/nilfs2/sufile.c :92 [en línea] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [en línea] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize f s/nilfs2 /ioctl.c:1033 [en línea] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ... Esto soluciona estos problemas insertando comprobaciones de tamaño mínimo de dispositivo adecuadas o comprobaciones anti-desbordamiento, dependiendo de dónde se utilice la macro .

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: sim: corrige una pérdida de memoria. Se corrige un error de lógica invertida en gpio_sim_remove_hogs() que hace que las estructuras GPIO hog nunca se liberen.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched/psi: corrige el use after free en ep_remove_wait_queue() si se elimina un cgroup no raíz cuando hay un subproceso que registró un activador y está sondeando un archivo de presión dentro en cgroup, la cola de espera de sondeo se libera en la siguiente ruta: do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pression_release psi_trigger_destroy Sin embargo, el hilo de sondeo aún tiene una referencia al archivo de presión y accederá a la cola de espera liberada cuando el archivo se cierre o al salir: fput ep_eventpoll_release ep_free ep_remove_wait_queue remove_wait_queue Esto da como resultado un use after free como se pega a continuación. El problema fundamental aquí es que cgroup_file_release() (y en consecuencia la vida útil de la cola de espera) no está ligada a la vida real del archivo. Usar wake_up_pollfree() aquí puede no ser ideal, pero está en línea con el comentario en la confirmación 42288cb44c4b ("espera: agregar wake_up_pollfree()") ya que la vida útil de la cola de espera no está ligada a la del archivo y puede considerarse como otro caso especial. . Si bien esto se podría solucionar haciendo que cgroup_file_release() esté vinculado de alguna manera a fput(), requeriría una refactorización considerable en cgroups o en una capa superior, lo que podría ser más justificable si identificamos más casos como este. ERROR: KASAN: use-after-free en _raw_spin_lock_irqsave+0x60/0xc0 Escritura de tamaño 4 en la dirección ffff88810e625328 por tarea a.out/4404 CPU: 19 PID: 4404 Comm: a.out No contaminado 6.2.0-rc6 #38 Hardware nombre: Amazon EC2 c5a.8xlarge/, BIOS 1.0 16/10/2017 Seguimiento de llamadas: dump_stack_lvl+0x73/0xa0 print_report+0x16c/0x4e0 kasan_report+0xc3/0xf0 kasan_check_range+0x2d2/0x310 _raw_spin_lock_irqsave+0x60/0x c0 remove_wait_queue+0x1a /0xa0 ep_free+0x12c/0x170 ep_eventpoll_release+0x26/0x30 __fput+0x202/0x400 task_work_run+0x11d/0x170 do_exit+0x495/0x1130 do_group_exit+0x100/0x100 get_signal+0xd67/0xde0 arch _do_signal_or_restart+0x2a/0x2b0 exit_to_user_mode_prepare+0x94/0x100 syscall_exit_to_user_mode+0x20 /0x40 do_syscall_64+0x52/0x90 Entry_SYSCALL_64_after_hwframe+0x63/0xcd Asignado por tarea 4404: kasan_set_track+0x3d/0x60 __kasan_kmalloc+0x85/0x90 psi_trigger_create+0x113/0x3e0 Pressure_write+0x1 46/0x2e0 cgroup_file_write+0x11c/0x250 kernfs_fop_write_iter+0x186/ 0x220 vfs_write+0x3d8/0x5c0 ksys_write+0x90/0x110 do_syscall_64+0x43/0x90 Entry_SYSCALL_64_after_hwframe+0x63/0xcd Liberado por la tarea 4407: kasan_set_track+0x3d/0x60 kasan_save_free_info+0x27/ 0x40 ____kasan_slab_free+0x11d/0x170 slab_free_freelist_hook+0x87/0x150 __kmem_cache_free+0xcb/ 0x180 psi_trigger_destroy+0x2e8/0x310 cgroup_file_release+0x4f/0xb0 kernfs_drain_open_files+0x165/0x1f0 kernfs_drain+0x162/0x1a0 __kernfs_remove+0x1fb/0x310 ns+0x95/0xe0 cgroup_addrm_files+0x67f/0x700 cgroup_destroy_locked+0x283/0x3c0 cgroup_rmdir+0x29/0x100 kernfs_iop_rmdir+0xd1/ 0x140 vfs_rmdir+0xfe/0x240 do_rmdir+0x13d/0x280 __x64_sys_rmdir+0x2c/0x30 do_syscall_64+0x43/0x90 Entry_SYSCALL_64_after_hwframe+0x63/0xcd