Vulnerabilidades

Motivo del rechazo: este ID CVE ha sido rechazado o retirado por su autoridad de numeración CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: core: Hacer que do_proc_control() y do_proc_bulk() se puedan eliminar. Los ioctls USBDEVFS_CONTROL y USBDEVFS_BULK invocan usb_start_wait_urb(), que contiene una espera ininterrumpida con un valor de tiempo de espera especificado por el usuario. Si el valor del tiempo de espera es muy grande y el dispositivo al que se accede no responde en un período de tiempo razonable, el kernel se quejará de "Tarea X bloqueada durante más de N segundos", como se encontró en las pruebas realizadas por syzbot: INFORMACIÓN: tarea syz-executor .0:8700 bloqueado durante más de 143 segundos. Not tainted 5.14.0-rc7-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:syz-executor.0 estado:D pila:23192 pid: 8700 ppid: 8455 banderas:0x00004004 Seguimiento de llamadas: context_switch kernel/sched/core.c:4681 [en línea] __schedule+0xc07/0x11f0 kernel/sched/core.c :5938 programación+0x14b/0x210 kernel/sched/core.c:6017 Schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857 do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85 __wait_for_common kernel/sched/completion .c:106 [en línea] wait_for_common kernel/sched/completion.c:117 [en línea] wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157 usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63 do_proc_bulk+0x978/0x1080 controladores/usb/core/devio.c:1236 controladores proc_bulk/usb/core/devio.c:1273 [en línea] usbdev_do_ioctl controladores/usb/core/devio.c:2547 [en línea] usbdev_ioctl+0x3441/ 0x6b10 drivers/usb/core/devio.c:2713 ... Para solucionar este problema, este parche reemplaza las llamadas de usbfs a usb_control_msg() y usb_bulk_msg() con código de propósito especial que hace esencialmente lo mismo (como se recomienda en el comentario para usb_start_wait_urb()), excepto que siempre usa una espera eliminable y usa GFP_KERNEL en lugar de GFP_NOIO.

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: 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: openrisc: trampas: no envía señales a subprocesos en modo kernel. El manejo de excepciones de OpenRISC envía señales a los procesos del usuario sobre excepciones de punto flotante e instrucciones de captura (para depuración), entre otros. Hay un error en el que la lógica de manejo de trampas puede enviar señales a los subprocesos del kernel. No debemos enviar estas señales a los subprocesos del kernel; si eso sucede, lo tratamos como un error. Este parche agrega condiciones para morir si el kernel recibe estas excepciones en el código del modo kernel.

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 resolvió la siguiente vulnerabilidad: ipv6: sr: corrige la ruta de error de cancelación de registro no válida La ruta de error de seg6_init() es incorrecta en caso de que CONFIG_IPV6_SEG6_LWTUNNEL no esté definido. En ese caso, si seg6_hmac_init() falla, no se llama a genl_unregister_family(). Este problema existe desde que el commit 46738b1317e1 ("ipv6: sr: agregar opción para controlar la compatibilidad con lwtunnel") y el commit 5559cea2d5aa ("ipv6: sr: corregir posible use-after-free y null-ptr-deref") reemplazó unregister_pernet_subsys() con genl_unregister_family() en esta ruta de error.