Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en el inodo inline_dots Como informó Wenqing en bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215765 Provocará un pánico del kernel con los pasos: - mkdir mnt - mount tmp40.img mnt - ls mnt folio_mark_dirty+0x33/0x50 f2fs_add_regular_entry+0x541/0xad0 [f2fs] f2fs_add_dentry+0x6c/0xb0 [f2fs] f2fs_do_add_link+0x182/0x230 [f2fs] __recover_dot_dentries+0x2d6/0x470 [f2fs] f2fs_lookup+0x5af/0x6a0 [f2fs] __lookup_slow+0xac/0x200 lookup_slow+0x45/0x70 walk_component+0x16c/0x250 path_lookupat+0x8b/0x1f0 filename_lookup+0xef/0x250 user_path_at_empty+0x46/0x70 vfs_statx+0x98/0x190 __do_sys_newlstat+0x41/0x90 __x64_sys_newlstat+0x1a/0x30 do_syscall_64+0x37/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae La causa raíz es un archivo especial: por ejemplo, un archivo de caracteres, bloques, FIFO o socket. f2fs no asigna una matriz de punteros de operaciones de espacio de direcciones para el campo mapping->a_ops, por lo que, en una imagen difusa, si el indicador inline_dots fue etiquetado en un archivo especial, durante lookup(), cuando f2fs se ejecuta en __recover_dot_dentries(), provocará un acceso al puntero NULL una vez que f2fs_add_regular_entry() llame a a_ops->set_dirty_page().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hfi1: Evitar pánico cuando SDMA está deshabilitado Si el módulo hfi1 se carga con HFI1_CAP_SDMA desactivado, una llamada a hfi1_write_iter() desreferenciará un puntero NULL y generará pánico. Un marco de pila típico es: sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64 La solución es probar SDMA en hfi1_write_iter() y fallar la E/S con EINVAL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: gpio-keys - cancela el trabajo retrasado solo en caso de GPIO El módulo gpio_keys puede aceptar GPIO o interrupciones. El módulo inicializa el trabajo retrasado solo en caso de GPIO y solo se usa si no se usa el temporizador antirrebote, así que asegúrese de que cancel_delayed_work_sync() se llame solo cuando esté respaldado por GPIO y debounce_use_hrtimer sea falso. Esto corrige el problema que se observa a continuación cuando se descarga el módulo gpio_keys y se usa un pin de interrupción en lugar de GPIO: [ 360.297569] ------------[ cortar aquí ]------------ [ 360.302303] WARNING: CPU: 0 PID: 237 at kernel/workqueue.c:3066 __flush_work+0x414/0x470 [ 360.310531] Modules linked in: gpio_keys(-) [ 360.314797] CPU: 0 PID: 237 Comm: rmmod Not tainted 5.18.0-rc5-arm64-renesas-00116-g73636105874d-dirty #166 [ 360.324662] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT) [ 360.331270] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 360.338318] pc : __flush_work+0x414/0x470 [ 360.342385] lr : __cancel_work_timer+0x140/0x1b0 [ 360.347065] sp : ffff80000a7fba00 [ 360.350423] x29: ffff80000a7fba00 x28: ffff000012b9c5c0 x27: 0000000000000000 [ 360.357664] x26: ffff80000a7fbb80 x25: ffff80000954d0a8 x24: 0000000000000001 [ 360.364904] x23: ffff800009757000 x22: 0000000000000000 x21: ffff80000919b000 [ 360.372143] x20: ffff00000f5974e0 x19: ffff00000f5974e0 x18: ffff8000097fcf48 [ 360.379382] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000053f40 [ 360.386622] x14: ffff800009850e88 x13: 0000000000000002 x12: 000000000000a60c [ 360.393861] x11: 000000000000a610 x10: 0000000000000000 x9 : 0000000000000008 [ 360.401100] x8 : 0101010101010101 x7 : 00000000a473c394 x6 : 0080808080808080 [ 360.408339] x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffff80000919b458 [ 360.415578] x2 : ffff8000097577f0 x1 : 0000000000000001 x0 : 0000000000000000 [ 360.422818] Call trace: [ 360.425299] __flush_work+0x414/0x470 [ 360.429012] __cancel_work_timer+0x140/0x1b0 [ 360.433340] cancel_delayed_work_sync+0x10/0x18 [ 360.437931] gpio_keys_quiesce_key+0x28/0x58 [gpio_keys] [ 360.443327] devm_action_release+0x10/0x18 [ 360.447481] release_nodes+0x8c/0x1a0 [ 360.451194] devres_release_all+0x90/0x100 [ 360.455346] device_unbind_cleanup+0x14/0x60 [ 360.459677] device_release_driver_internal+0xe8/0x168 [ 360.464883] driver_detach+0x4c/0x90 [ 360.468509] bus_remove_driver+0x54/0xb0 [ 360.472485] driver_unregister+0x2c/0x58 [ 360.476462] platform_driver_unregister+0x10/0x18 [ 360.481230] gpio_keys_exit+0x14/0x828 [gpio_keys] [ 360.486088] __arm64_sys_delete_module+0x1e0/0x270 [ 360.490945] invoke_syscall+0x40/0xf8 [ 360.494661] el0_svc_common.constprop.3+0xf0/0x110 [ 360.499515] do_el0_svc+0x20/0x78 [ 360.502877] el0_svc+0x48/0xf8 [ 360.505977] el0t_64_sync_handler+0x88/0xb0 [ 360.510216] el0t_64_sync+0x148/0x14c [ 360.513930] irq event stamp: 4306 [ 360.517288] hardirqs last enabled at (4305): [] __cancel_work_timer+0x130/0x1b0 [ 360.526359] hardirqs last disabled at (4306): [] el1_dbg+0x24/0x88 [ 360.534204] softirqs last enabled at (4278): [] _stext+0x4a0/0x5e0 [ 360.542133] softirqs last disabled at (4267): [] irq_exit_rcu+0x18c/0x1b0 [ 360.550591] ---[ end trace 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/iommu: falta of_node_put en iommu_init_early_dart El puntero device_node es devuelto por of_find_compatible_node con refcount incrementado. Deberíamos usar of_node_put() para evitar la fuga de refcount.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/xics: se corrige la pérdida de refcount en icp_opal_init(). La función of_find_compatible_node() devuelve un puntero de nodo con refcount incrementado, use of_node_put() en él cuando haya terminado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hfi1: Evitar el uso del bloqueo antes de que se inicialice Si hay un error durante el sondeo de hfi1 antes de que se inicialice sdma_map_lock, la llamada a hfi1_free_devdata() intentará usar un bloqueo que no se ha inicializado. Si el validador de corrección de bloqueo está activado, se puede ver un mensaje INFO y un seguimiento de pila similar al siguiente: INFO: intentando registrar una clave no estática. El código está bien, pero necesita la anotación lockdep, o tal vez no inicializó este objeto antes de usarlo. desactivando el validador de corrección de bloqueo. Rastreo de llamadas: register_lock_class+0x11b/0x880 __lock_acquire+0xf3/0x7930 lock_acquire+0xff/0x2d0 _raw_spin_lock_irq+0x46/0x60 sdma_clean+0x42a/0x660 [hfi1] hfi1_free_devdata+0x3a7/0x420 [hfi1] init_one+0x867/0x11a0 [hfi1] pci_device_probe+0x40e/0x8d0 El uso de sdma_map_lock en sdma_clean() es para liberar la memoria sdma_map, y sdma_map no se asigna/inicializa hasta que se haya inicializado sdma_map_lock. Este código solo necesita ejecutarse si sdma_map no es NULL, por lo que verificar esa condición evitará intentar usar el bloqueo antes de que se inicialice.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: evitar el bloqueo AB/BA de pci_dev_lock() con sriov_numvfs_store() La ruta sysfs sriov_numvfs_store() adquiere el bloqueo del dispositivo antes del bloqueo de acceso al espacio de configuración: sriov_numvfs_store device_lock # A (1) adquirir bloqueo del dispositivo sriov_configure vfio_pci_sriov_configure # (por ejemplo) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) esperar a que dev->block_cfg_access == 0 Anteriormente, pci_dev_lock() adquiría el bloqueo de acceso al espacio de configuración antes del bloqueo del dispositivo: pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) esperar a que se bloquee el dispositivo Cualquier ruta que use pci_dev_lock(), p. ej., pci_reset_function(), puede bloquearse con sriov_numvfs_store() si las operaciones ocurren en la secuencia (1) (2) (3) (4). Evite el bloqueo invirtiendo el orden en pci_dev_lock() para que adquiera el bloqueo del dispositivo antes del bloqueo de acceso al espacio de configuración, lo mismo que la ruta sriov_numvfs_store(). [bhelgaas: registro de confirmación combinado y adaptado de la publicación posterior independiente de Jay Zhou: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mfd: davinci_voicecodec: Se corrige la posible eliminación de PTR nula con davinci_vc_probe(). Esto provocará una eliminación de PTR nula al usar 'res', si platform_get_resource() devuelve NULL, por lo que se debe mover el uso de 'res' después de devm_ioremap_resource() que lo comprobará para evitar la eliminación de PTR nula. Y se usa devm_platform_get_and_ioremap_resource() para simplificar el código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iwlwifi: mei: soluciona la posible desreferencia de NULL-ptr. Si falla la asignación de SKB, continúa en lugar de usar el puntero NULL. Coverity CID: 1497650

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: vesafb: Fix a use-after-free due early fb_info cleanup Commit b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove") corrigió un error de use-after-free debido a que el controlador vesafb liberaba fb_info en el controlador .remove en lugar de hacerlo en .fb_destroy. Esto puede suceder si la devolución de llamada .fb_destroy se ejecuta después de la devolución de llamada .remove, ya que la primera intenta acceder a un puntero liberado por la segunda. Pero ese cambio no tuvo en cuenta que otro escenario posible es que se llame a .fb_destroy antes de la devolución de llamada .remove. Por ejemplo, si ningún proceso tiene abierto el fbdev chardev en el momento en que se elimina el controlador. Si ese es el caso, fb_info se liberará cuando se llame a unregister_framebuffer(), lo que hará que el puntero fb_info al que se accedió en vesafb_remove() después de eso ya no sea válido. Para evitarlo, mueva la expresión que contiene info->par para que suceda antes de la llamada a la función unregister_framebuffer().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: annotate races around sk->sk_bound_dev_if UDP sendmsg() is lockless, and reads sk->sk_bound_dev_if while this field can be changed by another thread. Añade anotaciones mínimas para evitar splats de KCSAN para UDP. Los siguientes parches añadirán más anotaciones a posibles lectores sin bloqueo. ERROR: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg write to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0: __ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221 ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1: udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2413 ___sys_sendmsg net/socket.c:2467 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00000000 -> 0xffffff9b Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G W 5.18.0-rc1-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Elegí no agregar la etiqueta Correcciones: porque la ejecución tiene consecuencias menores y los equipos estables están suficientemente ocupados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: clcdfb: Se corrige la pérdida de recuento de referencias en clcdfb_of_vram_setup of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado, deberíamos usar of_node_put() en él cuando ya no lo necesitemos. Agregue of_node_put() faltante para evitar la pérdida de recuento de referencias.