Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: mxl111sf: cambiar la ubicación de mutex_init() Syzbot informó que mxl111sf_ctrl_msg() usa un mutex no inicializado. El problema estaba en la ubicación mutex_init() incorrecta. La llamada anterior a mutex_init(&state->msg_lock) estaba en la función ->init(), pero dvb_usbv2_init() tiene este orden de llamadas: dvb_usbv2_init() dvb_usbv2_adapter_init() dvb_usbv2_adapter_frontend_init() props->frontend_attach() props->init() Desde Los dispositivos mxl111sf_* llaman a mxl111sf_ctrl_msg() en ->frontend_attach() internamente, necesitamos inicializar state->msg_lock antes de frontend_attach(). Para lograrlo, se agrega la llamada ->probe() a todos los dispositivos mxl111sf_*, lo que simplemente iniciará el mutex.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iocost: corrige la división por cero en la donación de un grupo c de bajo peso. La lógica de cálculo de la donación supone que el donante tiene un peso posterior a la donación distinto de cero, por lo que el peso activo más bajo es una donación. cgroup puede tener 2 para poder donar 1 y conservar el otro para sí mismo. Anteriormente, solo donábamos de grupos comunitarios con excedentes considerables, por lo que esta condición siempre fue cierta. Sin embargo, con el algoritmo de donación preciso implementado, f1de2439ec43 ("blk-iocost: renovar la determinación del monto de la donación") hizo que el cálculo del monto de la donación fuera exacto, permitiendo que incluso los grupos de bajo peso donaran. Esto significa que, en raras ocasiones, un grupo con un peso activo de 1 puede ingresar al cálculo de la donación, lo que genera la siguiente advertencia y luego una división por cero. ADVERTENCIA: CPU: 4 PID: 0 en block/blk-iocost.c:1928 transfer_surpluses.cold+0x0/0x53 [884/94867] ... RIP: 0010:transfer_surpluses.cold+0x0/0x53 Código: 92 y siguientes 48 c7 c7 28 d1 ab b5 65 48 8b 34 25 00 ae 01 00 48 81 c6 90 06 00 00 e8 8b 3f fe ff 48 c7 c0 ea ff ff ff e9 95 ff 92 ff <0f> 0b 48 c7 c7 30 da ab b5 e8 71 3f fe ff 4c 89 e8 4d 85 ed 74 0 4 ... Seguimiento de llamadas: ioc_timer_fn+0x1043/0x1390 call_timer_fn+0xa1/0x2c0 __run_timers.part.0+0x1ec/0x2e0 run_timer_softirq+0x35/0x70 ... iocg : pesos de donación no válidos en /a/b: activo=1 donación=1 después=0 Corríjalo excluyendo cgroups con hweight activo < 2 de la donación. Excluir estas donaciones de peso extremadamente bajo no debería afectar la conservación del trabajo de ninguna manera significativa.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: scsi_debug: Verifique la longitud del descriptor del bloque en resp_mode_select() En resp_mode_select(), verifique la longitud del descriptor del bloque para evitar UAF. ERROR: KASAN: use-after-free en resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509 Lectura del tamaño 1 en la dirección ffff888026670f50 por tarea scsicmd/15032 CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0 -01d0625 #15 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), seguimiento de llamadas del BIOS: dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107 print_address_description.constprop.9+0x28/0x160 mm/kasan/ report.c:257 kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306 resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c: 2509 Schedule_resp+0x4af/0x1a10 controladores/scsi/scsi_debug.c:5483 scsi_debug_queuecommand+0x8c9/0x1e70 controladores/scsi/scsi_debug.c:7537 scsi_queue_rq+0x16b4/0x2d10 controladores/scsi/scsi_lib.c:1521 blk_mq_dispatch_rq_list+0xb9b/0x2700 bloque/ blk-mq.c:1640 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358 __blk_mq_run_hw_queue+0xe5/ 0x150 cuadra/blk-mq. c:1762 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891 blk_mq_sched_insert_request+0x3db/0x4e0 ched.c:474 blk_execute_rq_nowait+0x16b /0x1c0 block/blk-exec.c:63 sg_common_write.isra.18+0xeb3/0x2000 controladores/scsi/sg.c:837 sg_new_write.isra.19+0x570/0x8c0 controladores/scsi/sg.c:775 sg_ioctl_common+0x14d6 /0x2710 controladores/scsi/sg.c:941 sg_ioctl+0xa2/0x180 controladores/scsi/sg.c:1166 __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52 do_syscall_64+0x3a/0x80 arch/x86/entry/common. c:50 entrada_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: io-wq: comprueba la salida de wq después de agregar un nuevo trabajador task_work Comprobamos IO_WQ_BIT_EXIT antes de intentar crear un nuevo trabajador, y wq exit cancela el trabajo pendiente si tenemos alguno. Pero es posible tener una carrera entre los dos, donde las comprobaciones de creación salen y descubren que no está configurado, pero estamos en el proceso de salir. El lado de salida cancelará la creación pendiente task_work, pero hay un espacio en el que agregamos task_work después de haber cancelado las creaciones existentes en el momento de la salida. Solucione este problema marcando la publicación del bit EXIT agregando la tarea de creación_trabajo. Si está configurado, ejecute la misma cancelación que realiza la salida.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: scsi_debug: corrige el tipo min_t para evitar la pila OOB. Cambie min_t() para usar el tipo "u32" en lugar de "int" para evitar la pila fuera de los límites. Con min_t() escriba "int", los valores se extienden y el valor mayor se usa provocando que la pila esté fuera de los límites. ERROR: KASAN: pila fuera de los límites en memcpy include/linux/fortify-string.h:191 [en línea] ERROR: KASAN: pila fuera de los límites en sg_copy_buffer+0x1de/0x240 lib/scatterlist.c: 976 Lectura del tamaño 127 en la dirección ffff888072607128 mediante la tarea syz-executor.7/18707 CPU: 1 PID: 18707 Comm: syz-executor.7 No contaminado 5.15.0-syzk #1 Nombre del hardware: Red Hat KVM, BIOS 1.13.0 -2 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256 __kasan_report mm/kasan /report.c:442 [en línea] kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [en línea] kasan_check_range+0x1a3/0x210 mm/kasan/generic .c:189 memcpy+0x23/0x60 mm/kasan/shadow.c:65 memcpy include/linux/fortify-string.h:191 [en línea] sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976 sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000 fill_from_dev_buffer.part.34+0x82/0x130 controladores/scsi/scsi_debug.c:1162 fill_from_dev_buffer controladores/scsi/scsi_debug.c:1888 [en línea] resp_readcap16+0x365/0x3b0 controladores/scsi/scsi_debug.c :1887 Schedule_resp+0x4d8/0x1a70 controladores/scsi/scsi_debug.c:5478 scsi_debug_queuecommand+0x8c9/0x1ec0 controladores/scsi/scsi_debug.c:7533 controladores scsi_dispatch_cmd/scsi/scsi_lib.c:1520 [en línea] Controladores 0x16b0/0x2d40/ scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x10 5/0x190 cuadra/blk-mq-programado. c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838 blk_mq_run_hw_queue+0x18d/0x350 :1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836 sg_new_write.isra.19+0x570 /0x8c0 controladores/scsi/sg.c:774 sg_ioctl_common+0x14d6/0x2710 controladores/scsi/sg.c:939 sg_ioctl+0xa2/0x180 controladores/scsi/sg.c:1165 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:874 [en línea] __se_sys_ioctl fs/ioctl.c:860 [en línea] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] llamada al sistema_64 +0x3a/0x80 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen/blkfront: fortalece blkfront contra tormentas de canales de eventos El controlador Xen blkfront aún es vulnerable a un ataque mediante un número excesivo de eventos enviados por el backend. Solucione eso usando canales de eventos de lateeoi. Esto es parte de XSA-391

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen/netfront: fortalece netfront contra tormentas de canales de eventos El controlador Xen netfront aún es vulnerable a un ataque mediante un número excesivo de eventos enviados por el backend. Solucione eso usando canales de eventos de lateeoi. Para poder detectar el caso de que no se agreguen respuestas rx mientras el operador está inactivo, se necesita un nuevo bloqueo para actualizar y probar rsp_cons y la cantidad de respuestas no consumidas vistas de forma atómica. Esto es parte de XSA-391 --- V2: - no haga eoi irq en caso de que la interfaz esté rota (Jan Beulich) - maneje el operador apagado + no se agregaron nuevas respuestas (Jan Beulich) V3: - agregue el prefijo rx_ a rsp_unconsumed ( Jan Beulich) - ortografía correcta de xennet_set_rx_rsp_cons() (Jan Beulich)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: m68k: corrige la ejecución de bloqueo de giro en la creación de subprocesos del kernel. El cambio de contexto se encarga de retener el propietario del bloqueo correcto durante el cambio de las tareas 'anteriores' a las 'siguientes'. Esto depende de que las interrupciones permanezcan deshabilitadas durante toda la duración del cambio. Esta condición está garantizada para la creación normal de procesos y el cambio de contexto entre procesos que ya se están ejecutando, porque tanto 'anterior' como 'siguiente' ya tienen las interrupciones deshabilitadas en sus copias guardadas del registro de estado. La situación es diferente para los subprocesos del kernel recién creados. El registro de estado se establece en PS_S en copy_thread(), lo que deja la IPL en 0. Al restaurar el registro de estado del 'siguiente' subproceso en switch_to() también conocido como resume(), las interrupciones se habilitan prematuramente. resume() luego regresa a través de ret_from_kernel_thread() y Schedule_tail() donde se libera el bloqueo de la cola de ejecución (consulte Finish_task_switch() y Finish_lock_switch()). Una interrupción del temporizador que llama a Scheduler_tick() antes de que se libere el bloqueo en Finish_task_switch() encontrará el bloqueo ya tomado, con la tarea actual como propietario del bloqueo. Esto provoca una advertencia de recursividad de spinlock según lo informado por Guenter Roeck. Hasta donde puedo determinar, esta ejecución se abrió en el commit 533e6903bea0 ("m68k: split ret_from_fork(), simplifica kernel_thread()") pero no he realizado un estudio detallado de la historia del kernel, por lo que es posible que sea anterior a esa confirmación. Las interrupciones no se pueden deshabilitar en la copia del registro de estado guardado para los subprocesos del kernel (init se quejará de las interrupciones deshabilitadas cuando finalmente inicie el espacio de usuario). Deshabilite las interrupciones temporalmente al cambiar los conjuntos de registros de tareas en resume(). Tenga en cuenta que un simple oriw 0x700,%sr después de restaurar sr no es suficiente aquí; esto deja suficiente ejecución para que aún se observe la advertencia de 'recursión de spinlock'. Probado en ARAnyM y qemu (emulación Quadra 800).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: la devolución de llamada exit() es opcional La devolución de llamada exit() es opcional y no debe llamarse sin verificar primero un puntero válido. Además, debemos borrar el puntero freq_table incluso si la devolución de llamada exit() no está presente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: carl9170: volver a corregir la advertencia de memset fortificado La función carl9170_tx_release() a veces activa una advertencia de memset fortificado en mis compilaciones de randconfig: en el archivo incluido en include/linux/string. h:254, de drivers/net/wireless/ath/carl9170/tx.c:40: en la función 'fortify_memset_chk', insertado desde 'carl9170_tx_release' en drivers/net/wireless/ath/carl9170/tx.c:283:2 , incluido desde 'kref_put' en include/linux/kref.h:65:3, incluido desde 'carl9170_tx_put_skb' en drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string .h:493:25: error: llamada a '__write_overflow_field' declarada con advertencia de atributo: escritura detectada más allá del tamaño del campo (primer parámetro); ¿Quizás usar struct_group()? [-Werror=advertencia-atributo] 493 | __write_overflow_field(p_size_field, tamaño); Kees anteriormente intentó evitar esto usando memset_after(), pero parece que esto no soluciona completamente el problema. Me di cuenta de que memset_after() aquí se realiza en una parte diferente de la unión (estado) de la que provenía la conversión original (rate_driver_data), lo que puede confundir al compilador. Desafortunadamente, el truco memset_after() no funciona en driver_rates[] porque es parte de una estructura anónima y tampoco pude lograr que struct_group() hiciera esto. Sin embargo, el uso de dos llamadas memset() separadas en los dos miembros soluciona la advertencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kunit/fortify: corrige el uso no coincidente de kvalloc()/vfree() La familia de pruebas kv*() se liberaba accidentalmente con vfree() en lugar de kvfree(). Utilice kvfree() en su lugar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: temporizador: establece el límite inferior del tiempo de inicio. Actualmente, el temporizador ALSA no tiene el límite inferior del tiempo de inicio y permite un tamaño muy pequeño, por ejemplo, 1 tic. con resolución de 1ns para hrtimer. Tal situación puede provocar una parada inesperada de la RCU, donde la devolución de llamada pone en cola repetidamente la actualización caducada, según lo informado por fuzzer. Este parche introduce una verificación de cordura del tiempo de inicio del temporizador, de modo que el sistema devuelve un error cuando se establece un tamaño de inicio demasiado pequeño. A partir de este parche, el límite inferior está codificado en 100us, que es bastante pequeño pero aún puede funcionar de alguna manera.