Vulnerabilidades

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 ha resuelto la siguiente vulnerabilidad: scsi: scsi_debug: no llamar a kcalloc() si el tamaño arg es cero. Si el tamaño arg de kcalloc() es cero, devuelve ZERO_SIZE_PTR. Por eso, para que una siguiente verificación de puntero NULL funcione en el puntero devuelto, no se debe llamar a kcalloc() con el tamaño arg igual a cero. Regrese temprano sin errores antes de la llamada a kcalloc() si el tamaño arg es cero. ERROR: KASAN: null-ptr-deref en memcpy include/linux/fortify-string.h:191 [en línea] ERROR: KASAN: null-ptr-deref en sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974 Escritura de tamaño 4 en la dirección 0000000000000010 por tarea syz-executor.1/22789 CPU: 1 PID: 22789 Comm: syz-executor.1 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 __kasan_report mm/kasan/report.c:446 [en línea] kasan_report.cold.14+0x112/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+0x3b/0x60 mm/kasan/shadow.c:66 memcpy include/linux /fortify-string.h:191 [en línea] sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974 controladores do_dout_fetch/scsi/scsi_debug.c:2954 [en línea] controladores do_dout_fetch/scsi/scsi_debug.c:2946 [en línea] resp_verify +0x49e/0x930 controladores/scsi/scsi_debug.c:4276 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] scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __blk_mq_sched_dispatch_requests+0x28f/0x590 lk-mq-sched.c:325 blk_mq_sched_dispatch_requests+ 0x105/0x190 block/blk-mq-sched.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 cola+0x18d/0x350 bloque/negro -mq.c: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 blk_execute_rq+0xdb/0x360 block/blk-exec.c:102 sg_scsi_ioctl controladores/scsi/scsi_ioctl.c:621 [en línea] scsi_ioctl+0x8bb/0x15c0 controladores/scsi/scsi_ioctl.c:930 sg_ioctl_common+0x172d/0x2710 controladores/scsi/sg.c:1112 sg_ioctl+0xa2/0 controladores x180/scsi/ SG.C: 1165 VFS_IOCTL FS/IOCTL.C: 51 [INLINE] __DO_SYS_IOCTL FS/IOCTL.C: 874 [INLINE] __SE_SYS_IOCTL FS/IOCTL.C: 860 [Inline] __X64_SY 60 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_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: ovl: corregir advertencia en ovl_create_real() Syzbot activó la siguiente advertencia en ovl_workdir_create() -> ovl_create_real(): if (!err && WARN_ON(!newdentry->d_inode)) { La razón es que el sistema de archivos cgroup2 regresa desde mkdir sin crear una instancia del nuevo dentry. Los sistemas de archivos extraños como este serán rechazados por overlayfs en una etapa posterior durante la instalación, pero para evitar dicha advertencia, llame a ovl_mkdir_real() directamente desde ovl_workdir_create() y rechace este caso anticipadamente.

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

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).