Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: zswap: corrección del bloqueo de crypto_free_acomp() en zswap_cpu_comp_dead(). Actualmente, zswap_cpu_comp_dead() llama a crypto_free_acomp() mientras mantiene el mutex acomp_ctx por CPU. A continuación, crypto_free_acomp() mantiene scomp_lock (mediante crypto_exit_scomp_ops_async()). Por otro lado, crypto_alloc_acomp_node() mantiene scomp_lock (mediante crypto_scomp_init_tfm()) y luego asigna memoria. Si la asignación resulta en una recuperación, podemos intentar mantener el mutex acomp_ctx por CPU. Las dependencias anteriores pueden causar un bloqueo de ABBA. Por ejemplo, en el siguiente escenario: (1) Tarea A ejecutándose en la CPU n.º 1: crypto_alloc_acomp_node() Retiene scomp_lock Ingresa a recuperación Lee per_cpu_ptr(pool->acomp_ctx, 1) (2) La tarea A se desprograma (3) La CPU n.º 1 se desconecta zswap_cpu_comp_dead(CPU n.º 1) Retiene per_cpu_ptr(pool->acomp_ctx, 1)) Llama a crypto_free_acomp() Espera a scomp_lock (4) Tarea A ejecutándose en la CPU n.º 2: Espera a per_cpu_ptr(pool->acomp_ctx, 1) // Lee en la CPU n.º 1 BLOQUEO INTERMEDIO Dado que no es necesario llamar a crypto_free_acomp() con el mutex acomp_ctx por CPU retenido en zswap_cpu_comp_dead(), muévalo después de que se desbloquee el mutex. También se desplazan las llamadas acomp_request_free() y kfree() para mantener la coherencia y evitar posibles dependencias de bloqueo sutil en el futuro. Con esto, solo se establece el valor NULL de los campos acomp_ctx con el mutex retenido. Esto es similar a cómo zswap_cpu_comp_prepare() solo inicializa los campos acomp_ctx con el mutex retenido, después de realizar todas las asignaciones antes de retener el mutex. Oportunistamente, se desplaza la comprobación de valores NULL en acomp_ctx para que se realice antes de la desreferencia del mutex.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrección de la gestión de los transportes de escucha Actualmente, cuando no se están ejecutando subprocesos activos, un usuario root que usa el comando nfsdctl puede intentar eliminar un oyente en particular de la lista de los agregados previamente y luego iniciar el servidor aumentando el número de subprocesos, lo que conduce al siguiente problema: [ 158.835354] refcount_t: adición en 0; use-after-free. [ 158.835603] WARNING: CPU: 2 PID: 9145 at lib/refcount.c:25 refcount_warn_saturate+0x160/0x1a0 [ 158.836017] Modules linked in: rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd auth_rpcgss nfs_acl lockd grace overlay isofs uinput snd_seq_dummy snd_hrtimer nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables qrtr sunrpc vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common snd_hda_codec_generic mc e1000e snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore sg loop dm_multipath dm_mod nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs libcrc32c crct10dif_ce ghash_ce vmwgfx sha2_ce sha256_arm64 sr_mod sha1_ce cdrom nvme drm_client_lib drm_ttm_helper ttm nvme_core drm_kms_helper nvme_auth drm fuse [ 158.840093] CPU: 2 UID: 0 PID: 9145 Comm: nfsd Kdump: loaded Tainted: G B W 6.13.0-rc6+ #7 [ 158.840624] Tainted: [B]=BAD_PAGE, [W]=WARN [ 158.840802] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 158.841220] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 158.841563] pc : refcount_warn_saturate+0x160/0x1a0 [ 158.841780] lr : refcount_warn_saturate+0x160/0x1a0 [ 158.842000] sp : ffff800089be7d80 [ 158.842147] x29: ffff800089be7d80 x28: ffff00008e68c148 x27: ffff00008e68c148 [ 158.842492] x26: ffff0002e3b5c000 x25: ffff600011cd1829 x24: ffff00008653c010 [ 158.842832] x23: ffff00008653c000 x22: 1fffe00011cd1829 x21: ffff00008653c028 [ 158.843175] x20: 0000000000000002 x19: ffff00008653c010 x18: 0000000000000000 [ 158.843505] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 158.843836] x14: 0000000000000000 x13: 0000000000000001 x12: ffff600050a26493 [ 158.844143] x11: 1fffe00050a26492 x10: ffff600050a26492 x9 : dfff800000000000 [ 158.844475] x8 : 00009fffaf5d9b6e x7 : ffff000285132493 x6 : 0000000000000001 [ 158.844823] x5 : ffff000285132490 x4 : ffff600050a26493 x3 : ffff8000805e72bc [ 158.845174] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000098588000 [ 158.845528] Call trace: [ 158.845658] refcount_warn_saturate+0x160/0x1a0 (P) [ 158.845894] svc_recv+0x58c/0x680 [sunrpc] [ 158.846183] nfsd+0x1fc/0x348 [nfsd] [ 158.846390] kthread+0x274/0x2f8 [ 158.846546] ret_from_fork+0x10/0x20 [ 158.846714] ---[ end trace 0000000000000000 ]--- nfsd_nl_listener_set_doit() manipularía la lista de transportes de sv_permsocks del servidor y cerraría el oyente especificado pero la otra lista de transportes La lista sp_xprts del servidor no se modificaría, lo que causaría el problema mencionado. En su lugar, se determinaría si nfsdctl intenta eliminar un receptor. En ese caso, se eliminarían todos los transportes de receptores existentes y se volverían a crear todos excepto los eliminados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exec: se corrige el uso excesivo de fs_struct->in_exec. check_unsafe_exec() establece fs->in_exec bajo cred_guard_mutex, y luego las rutas execve() limpian fs->in_exec sin bloqueo. Esto funciona correctamente si exec tiene éxito, pero si falla, tenemos la siguiente ejecución: T1 establece fs->in_exec = 1, falla y elimina cred_guard_mutex. T2 establece fs->in_exec = 1. T1 limpia fs->in_exec. T2 continúa con fs->in_exec == 0. Modifique fs/exec.c para limpiar fs->in_exec con cred_guard_mutex retenido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI/bwctrl: Corrección de la desreferencia de puntero nulo al agotar el número de bus. Cuando la BIOS no asigna números de bus a los puentes PCI, el kernel intenta corregirlo durante la enumeración de dispositivos PCI. Si se agotan los números de bus, no se asigna ningún pci_bus y el puntero "subordinado" en el pci_dev del puente permanece nulo. El controlador de ancho de banda PCIe no busca erróneamente un puntero subordinado nulo y lo desreferencia al sondear. El control del ancho de banda de los dispositivos inutilizables debajo del puente es de dudosa utilidad, por lo que simplemente se genera un error. Esto refleja lo que hace PCIe hotplug desde el commit 62e4492c3063 ("PCI: Evitar la desreferencia de puntero nulo durante el sondeo pciehp"). El núcleo PCI emite un mensaje con severidad KERN_INFO si se agotan los números de bus. PCIe hotplug emite un mensaje adicional con severidad KERN_ERR para informar al usuario que la función hotplug está deshabilitada en el puente. Un mensaje similar para el control del ancho de banda no parece justificado, dado que su único propósito hasta ahora es mostrar una velocidad de enlace actualizada en sysfs y limitarla en ciertas computadoras portátiles con potencia de diseño térmico limitada. Por lo tanto, el error se emite silenciosamente. Mensajes visibles para el usuario: pci 0000:16:02.0: configuración de puente no válida ([bus 00-00]), reconfigurando [...] pci_bus 0000:45: busn_res: el extremo [bus 45-74] se actualiza a 74 pci 0000:16:02.0: los dispositivos detrás del puente no se pueden usar porque no se puede asignar [bus 45-74] para ellos [...] pcieport 0000:16:02.0: pciehp: Puente hot-plug sin bus secundario, ignorando [...] ERROR: desreferencia de puntero NULL del kernel RIP: pcie_update_link_speed pcie_bwnotif_enable pcie_bwnotif_probe pcie_port_probe_service really_probe

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7921: corrección de pánico del kernel debido a la desreferencia de puntero nulo. Se solucionó un pánico del kernel causado por una desreferencia de puntero nulo en la función `mt792x_rx_get_wcid`. El problema surge porque la estructura `deflink` no se inicializa correctamente con el contexto `sta`. Este parche garantiza que la estructura `deflink` esté correctamente vinculada al contexto `sta`, lo que evita la desreferencia de puntero nulo. ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000400 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 UID: 0 PID: 470 Comm: mt76-usb-rx phy No contaminado 6.12.13-gentoo-dist #1 Nombre del hardware: /AMD HUDSON-M1, BIOS 4.6.4 15/11/2011 RIP: 0010:mt792x_rx_get_wcid+0x48/0x140 [mt792x_lib] RSP: 0018:ffffa147c055fd98 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff8e9ecb652000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e9ecb652000 RBP: 0000000000000685 R08: ffff8e9ec6570000 R09: 000000000000000 R10: ffff8e9ecd2ca000 R11: ffff8e9f22a217c0 R12: 0000000038010119 R13: 0000000080843801 R14: ffff8e9ec6570000 R15: ffff8e9ecb652000 FS: 0000000000000000(0000) GS:ffff8e9f22a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000400 CR3: 000000000d2ea000 CR4: 00000000000006f0 Seguimiento de llamadas: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? mt792x_rx_get_wcid+0x48/0x140 [mt792x_lib] mt7921_queue_rx_skb+0x1c6/0xaa0 [mt7921_common] mt76u_alloc_queues+0x784/0x810 [mt76_usb] ? __pfx___mt76_worker_fn+0x10/0x10 [mt76] __mt76_worker_fn+0x4f/0x80 [mt76] kthread+0xd2/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: poner dl_stid si no se puede poner en cola dl_recall. Antes de llamar a nfsd4_run_cb para poner en cola dl_recall en callback_wq, incrementamos el recuento de referencia de dl_stid. Esperamos que, tras procesar el work_struct correspondiente, el recuento de referencia de dl_stid se reduzca mediante la función de devolución de llamada nfsd4_cb_recall_release. Sin embargo, si falla la llamada a nfsd4_run_cb, el recuento de referencia incrementado de dl_stid no se reducirá correspondientemente, lo que provocará la siguiente pérdida de nfs4_stid: objeto sin referencia 0xffff88812067b578 (tamaño 344): comm "nfsd", pid 2761, jiffies 4295044002 (edad 5541.241s) volcado hexadecimal (primeros 32 bytes): 01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........ 00 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N.. seguimiento inverso: kmem_cache_alloc+0x4b9/0x700 nfsd4_process_open1+0x34/0x300 nfsd4_open+0x2d1/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 objeto sin referencia 0xffff8881499f4d28 (tamaño 368): comm "nfsd", pid 2761, jiffies 4295044005 (edad 5541.239s) volcado hexadecimal (primeros 32 bytes): 01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I.... 30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... ....... seguimiento inverso: kmem_cache_alloc+0x4b9/0x700 nfs4_alloc_stid+0x29/0x210 alloc_init_deleg+0x92/0x2e0 nfs4_set_delegation+0x284/0xc00 nfs4_open_delegation+0x216/0x3f0 nfsd4_process_open2+0x2b3/0xee0 nfsd4_open+0x770/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 Solucione el problema comprobando el resultado de nfsd4_run_cb y llama a nfs4_put_stid si no se puede poner en cola dl_recall.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: streamzap: fix race between device disconnection and urb callback Syzkaller ha informado de un fallo de protección general en la función ir_raw_event_store_with_filter(). Este fallo se debe a una desreferencia del puntero NULL del puntero dev->raw, aunque se comprueba si es NULL en la misma función, lo que significa que hay una condición de ejecución. Se produce debido al orden incorrecto de acciones en la función streamzap_disconnect(): se llama a rc_unregister_device() antes de usb_kill_urb(). El puntero dev->raw se libera y se establece en NULL en rc_unregister_device(), y solo después de eso, usb_kill_urb() espera a que finalicen las solicitudes en curso. Si se llama a rc_unregister_device() mientras el controlador streamzap_callback() no ha finalizado, esto puede provocar el acceso a los recursos liberados. Por lo tanto, rc_unregister_device() debe llamarse después de usb_kill_urb(). Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: No llamar a NULL en do_compat_alignment_fixup(). do_alignment_t32_to_handler() solo corrige errores de alineación para instrucciones específicas; devuelve NULL en caso contrario (por ejemplo, LDREX). En ese caso, se indica al emisor que debe continuar con la gestión normal de errores de alineación (por ejemplo, SIGBUS). Sin este parche, el kernel entra en pánico: No se puede gestionar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 Información de aborto de memoria: ESR = 0x0000000086000006 EC = 0x21: IABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: error de traducción de nivel 2 usuario pgtable: 4k páginas, VAs de 48 bits, pgdp=00000800164aa000 [000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000 Error interno: Ups: 0000000086000006 [#1] Módulos SMP vinculados en: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa> libcrc32c crc32c_generic raid0 multipath lineal dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c> CPU: 2 PID: 3932954 Comm: WPEWebProcess No contaminado 6.1.0-31-arm64 #1 Debian 6.1.128-1 Nombre del hardware: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr: corregir la alineación de compatibilidad+0xd8/0x3dc sp: ffff80000f973dd0 x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001 x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 000000000000000 x9: ffffaebc949bc488 x8: 000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 00000000000400000 x4 : 0000ffffffffffffe x3 : 0000000000000000 x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001 Rastreo de llamadas: 0x0 do_alignment_fault+0x40/0x50 do_mem_abort+0x4c/0xa0 el0_da+0x48/0xf0 el0t_32_sync_handler+0x110/0x140 el0t_32_sync+0x190/0x194 Código: valor de PC incorrecto ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: no ignore el código de retorno de svc_proc_register() Actualmente, nfsd_proc_stat_init() ignora el valor de retorno de svc_proc_register(). Si la creación de procfile falla, el kernel emitirá una ADVERTENCIA cuando intente eliminar la entrada posteriormente. Corrija nfsd_proc_stat_init() para que devuelva el mismo tipo de puntero que svc_proc_register() y corrija nfsd_net_init() para que lo compruebe y falle la construcción de nfsd_net si ocurre. svc_proc_register() puede fallar si no se puede asignar la dentry o si ya existe una dentry idéntica. El segundo caso es bastante improbable en la ruta de código de construcción de nfsd_net, por lo que si esto sucede, devuelva -ENOMEM.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI/ASPM: Corrección de la salida del estado del enlace durante la eliminación de la función ascendente del conmutador. Antes de la versión 456d8aa37d0f ("PCI/ASPM: Deshabilitar ASPM al eliminar la función MFD para evitar el use-after-free"), liberábamos el enlace ASPM solo después de eliminar la última función del bus correspondiente al enlace en cuestión. Era demasiado tarde. Si la función 0 se elimina antes que la función hermana, enlace->descendente apuntaría a la memoria liberada después. Tras el cambio mencionado, liberábamos el estado del enlace principal ASPM al eliminar cualquier función del bus correspondiente a un enlace determinado. Era demasiado pronto. Si el enlace es a un conmutador PCIe con MFD en el puerto ascendente, eliminar primero las funciones distintas de la 0 liberaría un enlace que aún permanece como parent_link para los puertos descendentes restantes. Los GPF resultantes son especialmente frecuentes durante la desconexión en caliente, ya que pciehp elimina los dispositivos del bus de enlace en orden inverso. En ese conmutador, la función 0 es el puente P2P virtual al bus interno. Se libera exactamente cuando se elimina la función 0: antes de que el enlace principal quede obsoleto, pero después de que todos los enlaces subordinados desaparezcan. [kwilczynski: registro de confirmaciones]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: añadir comprobación de solo lectura antes del truncamiento en jfs_truncate_nolock(). Se añadió una comprobación para el modo de "solo lectura" en la función `jfs_truncate_nolock` para evitar errores relacionados con la escritura en un sistema de archivos de solo lectura. Pila de llamadas: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) Si se activa la condición `isReadOnly(ip)` en `jfs_truncate_nolock`, la ejecución de la función se detendrá y no se realizarán más modificaciones de datos. En su lugar, se llamará a la función `xtTruncate` con el indicador "COMMIT_WMAP", lo que impide las modificaciones en modo de "solo lectura".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: añadir comprobación de solo lectura antes de llamar a txBeginAnon(). Se añadió una comprobación de solo lectura antes de llamar a `txBeginAnon` en `extAlloc` y `extRecord`. Esto impide intentos de modificación en un sistema de archivos montado de solo lectura, lo que evita posibles errores o bloqueos. Rastreo de llamadas: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [en línea] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299