Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: extcon: Modificar el dispositivo extcon para que se cree después de que se configuren los datos del controlador. Actualmente, alguien puede invocar el sysfs como state_show() de forma intermitente antes de que se realice dev_set_drvdata(). Y puede ser una causa de errores del kernel debido a que edev es Null en ese momento. Por lo tanto, se modificó el registro del controlador después de configurar los datos del controlador. - Ups, el backtrace. Rastreo inverso: [] (mostrar estado) desde [] (mostrar atributo de desarrollo) [] (mostrar atributo de desarrollo) desde [] (mostrar secuencia de sysfs_kf_seq) [] (mostrar secuencia de sysfs_kf_seq) desde [] (mostrar secuencia de kernfs) [] (mostrar secuencia de kernfs) desde [] (leer secuencia) [] (leer secuencia) desde [] (leer secuencia de kernfs_fop) [] (kernfs_fop_read) desde [] (__vfs_read) [] (__vfs_read) desde [] (vfs_read) [] (vfs_read) desde [] (ksys_read) [] (ksys_read) desde [] (sys_read) [] (sys_read) desde [] (__sys_trace_return)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: staging: rtl8723bs: Se corrige el bloqueo en rtw_surveydone_event_callback() Hay un bloqueo en rtw_surveydone_event_callback(), que se muestra a continuación: (Hilo 1) | (Hilo 2) | _set_timer() rtw_surveydone_event_callback()| mod_timer() spin_lock_bh() //(1) | (esperar un tiempo) ... | rtw_scan_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (esperar a que el temporizador se detenga) | ... Mantenemos pmlmepriv->lock en la posición (1) del hilo 1 y usamos del_timer_sync() para esperar a que el temporizador se detenga, pero el controlador del temporizador también necesita pmlmepriv->lock en la posición (2) del hilo 2. Como resultado, rtw_surveydone_event_callback() se bloqueará para siempre. Este parche extrae del_timer_sync() de la protección de spin_lock_bh(), lo que podría permitir que el controlador del temporizador obtenga el bloqueo necesario. Además, cambiamos spin_lock_bh() en rtw_scan_timeout_handler() a spin_lock_irq(). De lo contrario, spin_lock_bh() también provocará un bloqueo interno (deadlock()) en el controlador del temporizador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: char: xillybus: se corrige una pérdida de recuento de referencias en cleanup_dev(). Se llama a usb_get_dev en xillyusb_probe. Por lo tanto, es mejor llamar a usb_put_dev antes de que se publique xdev.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: staging: rtl8192bs: Corregir bloqueo en rtw_joinbss_event_prehandle() Hay un bloqueo en rtw_joinbss_event_prehandle(), que se muestra a continuación: (Hilo 1) | (Hilo 2) | _set_timer() rtw_joinbss_event_prehandle()| mod_timer() spin_lock_bh() //(1) | (esperar un tiempo) ... | _rtw_join_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (esperar a que el temporizador se detenga) | ... Mantenemos pmlmepriv->lock en la posición (1) del hilo 1 y usamos del_timer_sync() para esperar a que el temporizador se detenga, pero el controlador del temporizador también necesita pmlmepriv->lock en la posición (2) del hilo 2. Como resultado, rtw_joinbss_event_prehandle() se bloqueará para siempre. Este parche extrae del_timer_sync() de la protección de spin_lock_bh(), lo que podría permitir que el controlador del temporizador obtenga el bloqueo necesario. Además, cambiamos spin_lock_bh() por spin_lock_irq() en _rtw_join_timeout_handler() para evitar el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: rtl8712: corrige una posible pérdida de memoria en r871xu_drv_init() En r871xu_drv_init(), si r8712_init_drv_sw() falla, entonces la memoria asignada por r8712_alloc_io_queue() en r8712_usb_dvobj_init() no se libera correctamente ya que r8712_usb_dvobj_deinit() no realizará ninguna acción. Para liberarla correctamente, debemos llamar a r8712_free_io_queue() en r8712_usb_dvobj_deinit(). Además, en r871xu_dev_remove(), r8712_usb_dvobj_deinit() será llamado por r871x_dev_unload() bajo la condición `padapter->bup` y r8712_free_io_queue() será llamado por r8712_free_drv_sw(). Sin embargo, r8712_usb_dvobj_deinit() no depende de `padapter->bup` y llamar a r8712_free_io_queue() en r8712_free_drv_sw() es negativo para una mejor comprensión del código. Entonces muevo r8712_usb_dvobj_deinit() a r871xu_dev_remove() y elimino r8712_free_io_queue() de r8712_free_drv_sw().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: inicializar registros en nft_do_chain() Inicializar registros para evitar fugas de pila en el espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Comprueba si el módulo es 0 antes de dividir. [Cómo y por qué] Si se lee un valor de 0, esto provocará un pánico de división por 0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: se corrige un posible bloqueo al mantener presionado Fwb para obtener inline_data 1, montar con wsync. 2, crear un archivo con O_RDWR y la solicitud se envió a mds.0: ceph_atomic_open()--> ceph_mdsc_do_request(openc) finish_open(file, dentry, ceph_open)--> ceph_open()--> ceph_init_file()--> ceph_init_file_info()--> ceph_uninline_data()--> { ... if (inline_version == 1 || /* versión inicial, sin datos */ inline_version == CEPH_INLINE_NONE) goto out_unlock; ... } La inline_version será 1, que es la versión inicial para el nuevo archivo de creación. Y aquí, ci->i_inline_version se mantendrá con 1, es un error. 3, escribe en el búfer inmediatamente en el archivo: ceph_write_iter()--> ceph_get_caps(archivo, necesidad=Fw, deseo=Fb, ...); generic_perform_write()--> a_ops->write_begin()--> ceph_write_begin()--> netfs_write_begin()--> netfs_begin_read()--> netfs_rreq_submit_slice()--> netfs_read_from_server()--> rreq->netfs_ops->issue_read()--> ceph_netfs_issue_read()--> { ... if (ci->i_inline_version != CEPH_INLINE_NONE && ceph_netfs_issue_op_inline(subreq)) return; ... } ceph_put_cap_refs(ci, Fwb); El ceph_netfs_issue_op_inline() enviará una solicitud getattr(Fsr) a mds.1.4, luego mds.1 solicitará el bloqueo de rd para CInode::filelock desde el mds.0 de autenticación, el mds.0 realizará la transacción de estado de CInode::filelock desde excl --> sync, pero necesita revocar las capacidades Fxwb de los clientes. Mientras que el cliente del kernel ya ha retenido las capacidades Fwb y está esperando el getattr(Fsr). ¡Está en un punto muerto! URL: https://tracker.ceph.com/issues/55377

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nbd: se corrige el bloqueo de E/S al desconectar el dispositivo En nuestras pruebas, "qemu-nbd" activa un bloqueo de E/S: INFORMACIÓN: la tarea qemu-nbd:11445 estuvo bloqueada durante más de 368 segundos. No contaminada 5.18.0-rc3-next-20220422-00003-g2176915513ca #884 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. tarea:qemu-nbd estado:D pila: 0 pid:11445 ppid: 1 indicadores:0x00000000 Seguimiento de llamadas: __schedule+0x480/0x1050 ? _raw_spin_lock_irqsave+0x3e/0xb0 schedule+0x9c/0x1b0 blk_mq_freeze_queue_wait+0x9d/0xf0 ? ipi_rseq+0x70/0x70 blk_mq_freeze_queue+0x2b/0x40 nbd_add_socket+0x6b/0x270 [nbd] nbd_ioctl+0x383/0x510 [nbd] blkdev_ioctl+0x18e/0x3e0 __x64_sys_ioctl+0xac/0x120 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd8ff706577 RSP: 002b:00007fd8fcdfebf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007fd8ff706577 RDX: 000000000000000d RSI: 000000000000ab00 RDI: 00000000000000f RBP: 00000000000000f R08: 000000000000fbe8 R09: 000055fe497c62b0 R10: 00000002aff20000 R11: 0000000000000246 R12: 0000000000000006d R13: 00000000000000000 R14: 00007ffe82dc5e70 R15: 00007fd8fcdff9c0 "qemu-ndb -d" llamará primero a ioctl 'NBD_DISCONNECT', sin embargo, se encontró el siguiente mensaje: block nbd0: Send desconect failed -32 Lo que indica que algo anda mal con el servidor. Luego, "qemu-nbd -d" llamará a ioctl 'NBD_CLEAR_SOCK', sin embargo, ioctl no puede borrar las solicitudes después de el commit 2516ab1543fd("nbd: solo limpia la cola al desmantelar el dispositivo"). Mientras tanto, la solicitud no se puede completar después del tiempo de espera porque nbd_xmit_timeout() siempre devolverá 'BLK_EH_RESET_TIMER', lo que significa que dicha solicitud nunca se completará en esta situación. Ahora que el indicador 'NBD_CMD_INFLIGHT' puede garantizar que las solicitudes no se completen varias veces, vuelva a llamar a nbd_clear_sock() en nbd_clear_sock_ioctl(), de modo que las solicitudes en curso se puedan borrar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: rtl8712: se corrige uninit-value en r871xu_drv_init(). Cuando 'tmpU1b' retorna de r8712_read8(padapter, EE_9346CR) como 0, 'mac[6]' no se inicializará. ERROR: KMSAN: valor no inicializado en r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [en línea] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [en línea] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5358 [en línea] hub_port_connect_change drivers/usb/core/hub.c:5502 [en línea] port_event drivers/usb/core/hub.c:5660 [en línea] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307 worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454 kthread+0x3c7/0x500 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 Variable local mac creada en: r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 KMSAN: valor no inicializado en r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc2: gadget: no restablezca el controlador UDC del bus del gadget->controlador no debe tocar los componentes internos del controlador del gadget, especialmente no debe restablecer el controlador UDC del bus del gadget->controlador. Esto no fue dañino hasta ahora, pero desde el commit fc274c1e9973 ("USB: gadget: Agregar un nuevo bus para gadgets") el subsistema de gadget tiene su propio bus y jugar con ->bus desencadena la siguiente desreferencia de puntero NULL: dwc2 12480000.hsotg: controlador vinculado g_ether 8<--- corte aquí --- No se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 00000000 [00000000] *pgd=00000000 Error interno: Oops: 5 [#1] Módulos SMP ARM vinculados en: ... CPU: 0 PID: 620 Comm: modprobe No contaminado 5.18.0-rc5-next-20220504 #11862 Nombre del hardware: Samsung Exynos (árbol de dispositivos aplanado) La PC está en module_add_driver+0x44/0xe8 LR está en sysfs_do_create_link_sd+0x84/0xe0 ... Procesar modprobe (pid: 620, límite de pila = 0x(ptrval)) ... module_add_driver desde bus_add_driver+0xf4/0x1e4 bus_add_driver desde driver_register+0x78/0x10c driver_register desde usb_gadget_register_driver_owner+0x40/0xb4 usb_gadget_register_driver_owner desde do_one_initcall+0x44/0x1e0 do_one_initcall desde do_init_module+0x44/0x1c8 do_init_module desde load_module+0x19b8/0x1b9c load_module desde sys_finit_module+0xdc/0xfc sys_finit_module de ret_fast_syscall+0x0/0x54 Pila de excepciones (0xf1771fa8 a 0xf1771ff0) ... dwc2 12480000.hsotg: el nuevo dispositivo es de alta velocidad ---[ fin de seguimiento 000000000000000 ]--- Solucione esto eliminando el restablecimiento de la entrada del bus del controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nbd: se corrige la ejecución entre nbd_alloc_config() y la eliminación del módulo Cuando se elimina el módulo nbd, nbd_alloc_config() puede ser llamado simultáneamente por nbd_genl_connect(), aunque try_module_get() devolverá falso, pero nbd_alloc_config() no lo maneja. La ejecución puede provocar la fuga de nbd_config y sus recursos relacionados (por ejemplo, recv_workq) y oops en nbd_read_stat() debido a la descarga del módulo nbd como se muestra a continuación: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000040 Oops: 0000 [#1] SMP PTI CPU: 5 PID: 13840 Comm: kworker/u17:33 No contaminado 5.14.0+ #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996) Cola de trabajo: knbd16-recv recv_work [nbd] RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd] Rastreo de llamadas: recv_work+0x3b/0xb0 [nbd] process_one_work+0x1ed/0x390 worker_thread+0x4a/0x3d0 kthread+0x12a/0x150 ret_from_fork+0x22/0x30 Lo solucionamos comprobando el valor de retorno de try_module_get() en nbd_alloc_config(). Como nbd_alloc_config() puede devolver ERR_PTR(-ENODEV), asigne nbd->config solo cuando nbd_alloc_config() tenga éxito para garantizar que el valor de nbd->config sea binario (válido o NULL). También se agregó un mensaje de depuración para comprobar el contador de referencia de nbd_config durante la eliminación del módulo.