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: 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: 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: wifi: mac80211: corrección de use-after-free en el código chanctx En ieee80211_vif_use_reserved_context(), cuando tenemos un contexto antiguo y el replace_state del nuevo contexto está configurado en IEEE80211_CHANCTX_REPLACE_NONE, liberamos el contexto antiguo en ieee80211_vif_use_reserved_reassign(). Por lo tanto, ya no podemos verificar el old_ctx, por lo que deberíamos configurarlo en NULL después de este punto. Sin embargo, dado que el estado de reemplazo de new_ctx claramente no es IEEE80211_CHANCTX_REPLACES_OTHER, no vamos a hacer nada más en esta función y podemos simplemente regresar para evitar acceder al old_ctx liberado.

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: NFSv4: Se corrige el error nfs4_label no inicializado en la búsqueda de referencias. Se envía el fattr ya asignado junto con nfs4_fs_locations y se elimina el memcpy de fattr. Terminamos aumentando dos asignaciones más, pero esto soluciona un fallo como: PID: 790 TAREA: ffff88811b43c000 CPU: 0 COMANDO: "ls" #0 [ffffc90000857920] panic en ffffffff81b9bfde #1 [ffffc900008579c0] do_trap en ffffffff81023a9b #2 [ffffc90000857a10] do_error_trap en ffffffff81023b78 #3 [ffffc90000857a58] exc_stack_segment en ffffffff81be1f45 #4 [ffffc90000857a80] asm_exc_stack_segment en ffffffff81c009de #5 [ffffc90000857b08] nfs_lookup en ffffffffa0302322 [nfs] #6 [ffffc90000857b70] __lookup_slow en ffffffff813a4a5f #7 [ffffc90000857c60] walk_component en ffffffff813a86c4 #8 [ffffc90000857cb8] path_lookupat en ffffffff813a9553 #9 [ffffc90000857cf0] filename_lookup en ffffffff813ab86b

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