Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nbd: llamar a genl_unregister_family() primero en nbd_cleanup() De lo contrario, puede haber una ejecución entre la eliminación del módulo y la gestión del comando netlink, lo que puede provocar los errores que se muestran a continuación: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000098 Error: 0002 [#1] SMP PTI CPU: 1 PID: 31299 Comm: nbd-client Contaminado: GE 5.14.0-rc4 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:down_write+0x1a/0x50 Rastreo de llamadas: start_creating+0x89/0x130 debugfs_create_dir+0x1b/0x130 nbd_start_device+0x13d/0x390 [nbd] nbd_genl_connect+0x42f/0x748 [nbd] genl_family_rcv_msg_doit.isra.0+0xec/0x150 genl_rcv_msg+0xe5/0x1e0 netlink_rcv_skb+0x55/0x100 genl_rcv+0x29/0x40 netlink_unicast+0x1a8/0x250 netlink_sendmsg+0x21b/0x430 ____sys_sendmsg+0x2a4/0x2d0 ___sys_sendmsg+0x81/0xc0 __sys_sendmsg+0x62/0xb0 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Módulos vinculados en: nbd(E-)

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: rtl8712: se corrige un valor no inicializado en usb_read8() y similares. Cuando r8712_usbctrl_vendorreq() devuelve un valor negativo, no se inicializarán los 'datos' en usb_read{8,16,32}. ERROR: KMSAN: valor no inicializado en string_nocheck lib/vsprintf.c:643 [en línea] ERROR: KMSAN: valor no inicializado en string+0x4ec/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:643 [en línea] string+0x4ec/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 va_format lib/vsprintf.c:1704 [en línea] pointer+0x18e6/0x1f70 lib/vsprintf.c:2443 vsnprintf+0x1a9b/0x3650 lib/vsprintf.c:2810 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 dev_vprintk_emit+0x5ef/0x6d0 drivers/base/core.c:4604 dev_printk_emit+0x1dd/0x21f drivers/base/core.c:4615 __dev_printk+0x3be/0x440 drivers/base/core.c:4627 _dev_info+0x1ea/0x22f drivers/base/core.c:4673 r871xu_drv_init+0x1929/0x3070 drivers/staging/rtl8712/usb_intf.c:401 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x6c7/0x1350 drivers/base/dd.c:621 __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+0x6c7/0x1350 drivers/base/dd.c:621 __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+0x1b91/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5363 [en línea] hub_port_connect_change drivers/usb/core/hub.c:5507 [en línea] port_event drivers/usb/core/hub.c:5665 [en línea] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5747 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2289 worker_thread+0x10d0/0x2240 kernel/workqueue.c:2436 kthread+0x3c7/0x500 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 Datos de la variable local creados en: usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33 r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29 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: f2fs: cuota: se corrige la condición de bucle en f2fs_quota_sync(). cnt debe pasarse a sb_has_quota_active() en lugar de type para verificar la cuota activa correctamente. Además, cuando el tipo es -1, el compilador con suficiente conocimiento en línea puede descartar por completo la comprobación sb_has_quota_active(), lo que provoca una desreferencia de puntero NULL en el siguiente inode_lock(dqopt->files[cnt]): [ 2.796010] No se puede manejar la desreferencia de puntero NULL del núcleo en la dirección virtual 00000000000000a0 [ 2.796024] Información de aborto de memoria: [ 2.796025] ESR = 0x96000005 [ 2.796028] EC = 0x25: DABT (EL actual), IL = 32 bits [ 2.796029] SET = 0, FnV = 0 [ 2.796031] EA = 0, S1PTW = 0 [ 2.796032] Aborto de datos información: [ 2.796034] ISV = 0, ISS = 0x00000005 [ 2.796035] CM = 0, WnR = 0 [ 2.796046] usuario pgtable: 4k páginas, VA de 39 bits, pgdp=00000003370d1000 [ 2.796048] [00000000000000a0] pgd=000000000000000, pud=0000000000000000 [ 2.796051] Error interno: Oops: 96000005 [#1] PREEMPT SMP [ 2.796056] CPU: 7 PID: 640 Comm: f2fs_ckpt-259:7 Contaminado: GS 5.4.179-arter97-r8-64666-g2f16e087f9d8 #1 [ 2.796057] Nombre del hardware: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT) [ 2.796059] pstate: 80c00005 (Nzcv daif +PAN +UAO) [ 2.796065] pc : down_write+0x28/0x70 [ 2.796070] lr : f2fs_quota_sync+0x100/0x294 [ 2.796071] sp : ffffffa3f48ffc30 [ 2.796073] x29: ffffffa3f48ffc30 x28: 0000000000000000 [ 2.796075] x27: ffffffa3f6d718b8 x26: ffffffa415fe9d80 [ 2.796077] x25: ffffffa3f7290048 x24: 0000000000000001 [ 2.796078] x23: 0000000000000000 x22: ffffffa3f7290000 [ 2.796080] x21: ffffffa3f72904a0 x20: ffffffa3f7290110 [ 2.796081] x19: fffffa3f77a9800 x18: ffffffc020aae038 [ 2.796083] x17: ffffffa40e38e040 x16: ffffffa40e38e6d0 [ 2.796085] x15: ffffffa40e38e6cc x14: ffffffa40e38e6d0 [ 2.796086] x13: 00000000000004f6 x12: 00162c44ff493000 [ 2.796088] x11: 0000000000000400 x10: ffffffa40e38c948 [ 2.796090] x9 : 0000000000000000 x8 : 000000000000000a0 [ 2.796091] x7 : 0000000000000000 x6 : 0000d1060f00002a [ 2.796093] x5 : ffffffa3f48ff718 x4 : 000000000000000d [ 2.796094] x3 : 00000000060c0000 x2 : 0000000000000001 [ 2.796096] x1 : 000000000000000 x0 : 000000000000000a0 [ 2.796098] Rastreo de llamadas: [ 2.796100] down_write+0x28/0x70 [ 2.796102] f2fs_quota_sync+0x100/0x294 [ 2.796104] block_operations+0x120/0x204 [ 2.796106] f2fs_write_checkpoint+0x11c/0x520 [ 2.796107] __checkpoint_and_complete_reqs+0x7c/0xd34 [ 2.796109] issue_checkpoint_thread+0x6c/0xb8 [ 2.796112] kthread+0x138/0x414 [ 2.796114] ret_from_fork+0x10/0x18 [ 2.796117] Código: aa0803e0 aa1f03e1 52800022 aa0103e9 (c8e97d02) [ 2.796120] ---[ fin del seguimiento 96e942e8eb6a0b53 ]--- [ 2.800116] Pánico del núcleo: no se sincroniza: excepción fatal [ 2.800120] SMP: detención de CPU secundarias

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: sysfb: se corrige la fuga del dispositivo de plataforma en la ruta de error. Asegúrese de liberar el dispositivo de plataforma también en el improbable caso de que falle el registro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: coresight: syscfg: Se corrige la fuga de memoria en caso de error de registro en cscfg_create_device device_register() llama a device_initialize(), según la documentación de device_initialize: Use put_device() para entregar su referencia en lugar de liberar * @dev directamente una vez que haya llamado a esta función. Para evitar una posible fuga de memoria, use put_device() para la gestión de errores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: accel: mma8452: usa la lógica correcta para obtener mma8452_data La lógica original para obtener mma8452_data es incorrecta, el punto *dev al dispositivo pertenece a iio_dev. No podemos usar este dev para encontrar el i2c_client correcto. La lógica original funcionó porque finalmente usó dev->driver_data para obtener iio_dev. Aquí, usar la API to_i2c_client() es incorrecto y confunde al lector. Para corregir la lógica, debería ser así struct mma8452_data *data = iio_priv(dev_get_drvdata(dev)); Pero después de el commit 8b7651f25962 ("iio: iio_device_alloc(): eliminar drvdata propios innecesarios"), la lógica superior tampoco puede funcionar. Cuando se intenta mostrar la escala disponible en el espacio de usuario, se produce un volcado del kernel y una desreferencia del puntero NULL del manejador del kernel. Por lo tanto, se utiliza dev_to_iio_dev() para corregir la lógica. Dual corrige las etiquetas, ya que la segunda refleja cuándo se expuso el error, mientras que la primera refleja cuándo se introdujo el error original.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tpm: uso try_get_ops() en tpm-space.c Como parte de la conversión en serie para eliminar las operaciones TPM anidadas: https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/ se eliminó la exposición del chip->tpm_mutex de gran parte del código de nivel superior. En esta conversión, se pasó por alto tpm2_del_space(). Esto no importó mucho porque generalmente se llama poco después de una operación convertida, por lo que solo hay una ventana de ejecución muy pequeña donde se puede quitar el chip antes de que se realice el vaciado de espacio, lo que provoca una desreferencia NULL en el mutex. Sin embargo, hay informes de que esta ventana se alcanza en la práctica, así que solucione esto convirtiendo tpm2_del_space() para usar tpm_try_get_ops(), que realiza todas las comprobaciones de desmontaje antes de adquirir el mutex.