Vulnerabilidades

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

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: Se corrige la ruta de gestión de errores en idxd_cdev_register(). Si falla una llamada a alloc_chrdev_region(), se pierden los recursos ya asignados. Agregue la ruta de manejo de errores necesaria para corregir la pérdida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtla: Evitar la desreferenciación del puntero NULL del registro Corrija los siguientes errores null/deref_null.cocci errors: ./tools/tracing/rtla/src/osnoise_hist.c:870:31-36: ERROR: record is NULL but dereferenced. ./tools/tracing/rtla/src/osnoise_top.c:650:31-36: ERROR: record is NULL but dereferenced. ./tools/tracing/rtla/src/timerlat_hist.c:905:31-36: ERROR: record is NULL but dereferenced. ./tools/tracing/rtla/src/timerlat_top.c:700:31-36: ERROR: record is NULL but dereferenced. "record" is NULL before calling osnoise_init_trace_tool. Add a tag "out_free" to avoid dereferring a NULL pointer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/mediatek: Arreglar la desreferencia del puntero NULL al imprimir dev_name Cuando larbdev es NULL (en el caso que encontré, el nodo está configurado incorrectamente iommus = <&iommu NUM>), provocará un error en device_link_add() y el kernel se bloquea cuando intentamos imprimir dev_name(larbdev). Hagamos que falle la sonda si un larbdev es NULL para evitar entradas no válidas de dts. Debería funcionar para una configuración correcta normal y evitar el bloqueo causado por mi configuración incorrecta. Registro de errores: [18.189042][T301] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000050 ... [ 18.344519][ T301] pstate: a0400005 (NzCv daif +PAN -UAO) [ 18.345213][ T301] pc : mtk_iommu_probe_device+0xf8/0x118 [mtk_iommu] [ 18.346050][ T301] lr : mtk_iommu_probe_device+0xd0/0x118 [mtk_iommu] [ 18.346884][ T301] sp : ffffffc00a5635e0 [ 18.347392][ T301] x29: ffffffc00a5635e0 x28: ffffffd44a46c1d8 [ 18.348156][ T301] x27: ffffff80c39a8000 x26: ffffffd44a80cc38 [ 18.348917][ T301] x25: 0000000000000000 x24: ffffffd44a80cc38 [ 18.349677][ T301] x23: ffffffd44e4da4c6 x22: ffffffd44a80cc38 [ 18.350438][ T301] x21: ffffff80cecd1880 x20: 0000000000000000 [ 18.351198][ T301] x19: ffffff80c439f010 x18: ffffffc00a50d0c0 [ 18.351959][ T301] x17: ffffffffffffffff x16: 0000000000000004 [ 18.352719][ T301] x15: 0000000000000004 x14: ffffffd44eb5d420 [ 18.353480][ T301] x13: 0000000000000ad2 x12: 0000000000000003 [ 18.354241][ T301] x11: 00000000fffffad2 x10: c0000000fffffad2 [ 18.355003][ T301] x9 : a0d288d8d7142d00 x8 : a0d288d8d7142d00 [ 18.355763][ T301] x7 : ffffffd44c2bc640 x6 : 0000000000000000 [ 18.356524][ T301] x5 : 0000000000000080 x4 : 0000000000000001 [ 18.357284][ T301] x3 : 0000000000000000 x2 : 0000000000000005 [ 18.358045][ T301] x1 : 0000000000000000 x0 : 0000000000000000 [ 18.360208][ T301] Hardware name: MT6873 (DT) [ 18.360771][ T301] Call trace: [ 18.361168][ T301] dump_backtrace+0xf8/0x1f0 [ 18.361737][ T301] dump_stack_lvl+0xa8/0x11c [ 18.362305][ T301] dump_stack+0x1c/0x2c [ 18.362816][ T301] mrdump_common_die+0x184/0x40c [mrdump] [ 18.363575][ T301] ipanic_die+0x24/0x38 [mrdump] [ 18.364230][ T301] atomic_notifier_call_chain+0x128/0x2b8 [ 18.364937][ T301] die+0x16c/0x568 [ 18.365394][ T301] __do_kernel_fault+0x1e8/0x214 [ 18.365402][ T301] do_page_fault+0xb8/0x678 [ 18.366934][ T301] do_translation_fault+0x48/0x64 [ 18.368645][ T301] do_mem_abort+0x68/0x148 [ 18.368652][ T301] el1_abort+0x40/0x64 [ 18.368660][ T301] el1h_64_sync_handler+0x54/0x88 [ 18.368668][ T301] el1h_64_sync+0x68/0x6c [ 18.368673][ T301] mtk_iommu_probe_device+0xf8/0x118 [mtk_iommu] ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: se corrige la desreferencia del iterador de lista obsoleto después del cuerpo del bucle La variable del iterador de lista será un puntero falso si no se alcanzó ninguna interrupción. Desreferenciarlo (cur->page en este caso) podría cargar un valor fuera de los límites/indefinido, lo que hace que no sea seguro usarlo en la comparación para determinar si se encontró el elemento específico. Dado que 'cur->page' *puede* estar fuera de los límites, no se puede garantizar que por casualidad (o intención de un atacante) coincida con el valor de 'page' aunque no se haya encontrado el elemento correcto. Esto se soluciona utilizando una variable de iterador de lista separada para el bucle y solo configurando la variable original si se encontró un elemento adecuado. Luego, determinar si se encontró el elemento es simplemente verificar si la variable está configurada.