Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/core: Solución del problema "KASAN: slab-use-after-free Read in ib_register_device" Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Este problema es Similar al problema corregido en el commit 1d6a9e7449e2 ("RDMA/core: Corrección del problema de use-after-free al cambiar el nombre del dispositivo"). La causa principal es que la función ib_device_rename() cambia el nombre con bloqueo. Sin embargo, en la función kobject_uevent(), se accede a este nombre sin protección de bloqueo. La solución es añadir la protección de bloqueo al acceder a este nombre en la función kobject_uevent().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Deshabilitar la descarga de MACsec para el perfil de representante de enlace ascendente. La descarga de MACsec no es compatible con el modo switchdev para los representantes de enlace ascendente. Al cambiar al perfil de representante de enlace ascendente, se debe desactivar la función de descarga de MACsec de las características del dispositivo de red. Si se deja activada, los intentos de agregar descargas resultan en una desreferencia de puntero nulo, ya que el representante de enlace ascendente no admite la descarga de MACsec, aunque el bit de característica permanezca activado. Desactive NETIF_F_HW_MACSEC en mlx5e_fix_uplink_rep_features(). Registro del núcleo: Ups: fallo de protección general, probablemente para dirección no canónica 0xdffffc000000000f: 0000 [#1] SMP KASAN KASAN: null-ptr-deref en el rango [0x000000000000078-0x000000000000007f] CPU: 29 UID: 0 PID: 4714 Comm: ip No contaminado 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x128/0x1dd0 Código: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff RSP: 0018:ffff888147a4f160 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 000000000000000f RSI: 000000000000000000 RDI: 0000000000000078 RBP: ffff888147a4f2e0 R08: fffffffffa05d2c19 R09: 0000000000000000 R10: 0000000000000001 R11: 00000000000000000 R12: 00000000000000000 R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000 FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0 DR0: 000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Rastreo de llamadas: ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? __copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/tls: corrección del pánico del kernel cuando alloc_page falla. No se puede establecer frag_list como un puntero nulo cuando alloc_page falla. Se usará en tls_strp_check_queue_ok la próxima vez que se invoque tls_strp_read_sock. Esto se debe a que no se restablece full_len en tls_strp_flush_anchor_copy(), por lo que la ruta de recepción intentará continuar gestionando el registro parcial en la siguiente llamada, pero se ha desvinculado el rcvq de la lista de fragmentos. Una solución alternativa sería restablecer full_len. No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000028 Rastreo de llamadas: tls_strp_check_rcv+0x128/0x27c tls_strp_data_ready+0x34/0x44 tls_data_ready+0x3c/0x1f0 tcp_data_ready+0x9c/0xe4 tcp_data_queue+0xf6c/0x12d0 tcp_rcv_established+0x52c/0x798

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: se corrige una fuga de memoria en la ruta de gestión de errores de idxd_alloc. La memoria asignada a idxd no se libera si se produce un error durante idxd_alloc(). Para solucionarlo, libere la memoria asignada en orden inverso a la asignación antes de salir de la función en caso de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: Refactorizar la llamada de eliminación con el asistente idxd_cleanup(). Este asistente limpia el monitor de rendimiento, las interrupciones, los componentes internos, etc. Refactorizar la llamada de eliminación con el asistente idxd_cleanup() para evitar la duplicación de código. Cabe destacar que esto también corrige la función put_device() que faltaba para los grupos, motores y máquinas virtuales idxd.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: Establecer n_channels tras asignar la estructura cfg80211_scan_request. Asegúrese de que n_channels esté establecido tras asignar el miembro de la estructura cfg80211_registered_device::int_scan_req. Observada con syzkaller: UBSAN: array-index-out-of-bounds en net/mac80211/scan.c:1208:5. El índice 0 está fuera de rango para el tipo 'struct ieee80211_channel *[] __counted_by(n_channels)' (también conocido como 'struct ieee80211_channel *[]'). Esto no se detectó en las conversiones iniciales porque no se localizó la asignación, probablemente debido a que "sizeof(void *)" no coincide con el tipo de matriz "channels".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched_ext: bpf_iter_scx_dsq_new() siempre debe inicializar el iterador. Los programas BPF pueden llamar a next() y destroy() en iteradores BPF incluso después de que new() devuelva un valor de error (p. ej., la macro bpf_for_each() ignora los errores devueltos por new()). bpf_iter_scx_dsq_new() podría dejar el iterador sin inicializar después de un error, lo que provoca que bpf_iter_scx_dsq_next() desreferencia datos innecesarios. Asegúrese de que bpf_iter_scx_dsq_new() siempre borre $kit->dsq para que next() y destroy() se conviertan en noops.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: tegra: xusb: utilizar una máscara de bits para el seguimiento del estado de energía del panel UTMI. La implementación actual utiliza bias_pad_enable como un recuento de referencia para administrar el panel de polarización compartido para todos los PHY UTMI. Sin embargo, durante la suspensión del sistema con dispositivos USB conectados, varias solicitudes de apagado del panel UTMI resultan en una discrepancia en el recuento de referencia, lo que a su vez produce advertencias como: [ 237.762967] ADVERTENCIA: CPU: 10 PID: 1618 en tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763103] Rastreo de llamadas: [ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30 [ 237.763110] phy_power_off+0x48/0x100 [ 237.763113] tegra_xusb_enter_elpg+0x204/0x500 [ 237.763119] tegra_xusb_suspend+0x48/0x140 [ 237.763122] platform_pm_suspend+0x2c/0xb0 [ 237.763125] dpm_run_callback.isra.0+0x20/0xa0 [ 237.763127] __device_suspend+0x118/0x330 [ 237.763129] dpm_suspend+0x10c/0x1f0 [ 237.763130] dpm_suspend_start+0x88/0xb0 [ 237.763132] suspend_devices_and_enter+0x120/0x500 [ 237.763135] pm_suspend+0x1ec/0x270 La causa raíz se remonta a los cambios de apagado dinámico introducidos en el commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"), donde el pad UTMI se apagaba sin verificar su estado actual. Este comportamiento desequilibrado provocó discrepancias en el recuento de referencias. Para rectificar este problema, este parche reemplaza el contador de referencia único con una máscara de bits, renombrada como utmi_pad_enabled. Cada bit en la máscara corresponde a uno de los cuatro PHY USB2, lo que nos permite rastrear el estado de habilitación de cada pad individualmente. Con este cambio: - El pad de polarización se enciende solo cuando la máscara está despejada. - Cada pad UTMI se enciende o apaga según su bit correspondiente en la máscara, lo que evita operaciones redundantes. El estado general de energía del pad de polarización compartido se mantiene correctamente durante los ciclos de suspensión/reinicio. El mutex utilizado para evitar condiciones de ejecución durante las operaciones de activación/desactivación del pad UTMI se ha trasladado de las funciones tegra186_utmi_bias_pad_power_on/off a las funciones principales tegra186_utmi_pad_power_on/down. Este cambio garantiza que no se produzcan condiciones de ejecución al actualizar la máscara de bits.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/page_alloc: arregla la condición de ejecución en el manejo de memoria no aceptada El asignador de páginas rastrea el número de zonas que tienen memoria no aceptada usando static_branch_enc/dec() y usa esa rama estática en rutas activas para determinar si necesita lidiar con memoria no aceptada. Borislav y Thomas señalaron que el rastreo es acelerado: las operaciones en static_branch no se serializan contra la adición/eliminación de páginas no aceptadas a/desde la zona. Las comprobaciones de cordura dentro de la maquinaria static_branch lo detectan: ADVERTENCIA: CPU: 0 PID: 10 en kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0 El comentario alrededor de WARN() explica el problema: /* * Sin embargo, advierte sobre el caso '-1'; ya que eso significa que un * decremento es concurrente con un primer incremento (0->1). Es decir, * se está intentando deshabilitar algo que aún no estaba completamente habilitado. Esto sugiere un problema de ordenamiento del usuario. */ El efecto de esta optimización de static_branch solo es visible en microbenchmark. En lugar de añadir más complejidad, elimínenla por completo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: deshabilitar NAPI al eliminar el controlador. Una advertencia al eliminar el controlador comenzó a aparecer después de el commit 9dd05df8403b ("net: advertir si la instancia de NAPI no se apagó"). Desactive la transacción NAPI antes de eliminarla en mt76_dma_cleanup(). ADVERTENCIA: CPU: 4 PID: 18828 en net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe No contaminado 6.15.0-rc4 #4 PREEMPT(lazy) Nombre del hardware: Nombre del producto del sistema ASUS/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Rastreo de llamadas: mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Se probó con mt7921e, pero el mismo patrón se puede aplicar a otros controladores mt76 que invoquen mt76_dma_cleanup() durante la eliminación. Tx napi está habilitado en sus funciones *_dma_init() y solo se activa y desactiva dentro de sus rutas de suspensión/reinicio/reinicio. Por lo tanto, debería ser aceptable deshabilitar tx napi de forma genérica. Encontrado por el Centro de Verificación de Linux (linuxtesting.org).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: csa unmap usa un bloqueo ininterrumpible. Tras salir del proceso para desasignar csa y liberar la máquina virtual de la GPU, si se acepta la señal y se interrumpe la espera para obtener el bloqueo de la máquina virtual y se retorna, se produce una fuga de memoria y un seguimiento inverso inferior a la advertencia. Cambiar al uso de un bloqueo de espera ininterrumpible soluciona el problema. ADVERTENCIA: CPU: 69 PID: 167800 en amd/amdgpu/amdgpu_kms.c:1525 amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu] Seguimiento de llamadas: drm_file_free.part.0+0x1da/0x230 [drm] drm_close_helper.isra.0+0x65/0x70 [drm] drm_release+0x6a/0x120 [drm] amdgpu_drm_release+0x51/0x60 [amdgpu] __fput+0x9f/0x280 ____fput+0xe/0x20 task_work_run+0x67/0xa0 do_exit+0x217/0x3c0 do_group_exit+0x3b/0xb0 get_signal+0x14a/0x8d0 arch_do_signal_or_restart+0xde/0x100 exit_to_user_mode_loop+0xc1/0x1a0 exit_to_user_mode_prepare+0xf4/0x100 syscall_exit_to_user_mode+0x17/0x40 do_syscall_64+0x69/0xc0 (seleccionado de el commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mctp: No acceder a ifa_index si falta. En mctp_dump_addrinfo, ifa_index puede usarse para filtrar interfaces, pero solo cuando se proporciona la estructura ifaddrmsg. De lo contrario, se comparará con memoria no inicializada, lo cual es reproducible en el caso de syzkaller desde dhcpd o "ip addr show" de busybox. La implementación de MCTP del kernel siempre ha filtrado por ifa_index, por lo que los programas de espacio de usuario que esperan volcar direcciones MCTP ya deben estar pasando un valor válido de ifa_index (0 o un índice real). ERROR: KMSAN: valor no inicializado en mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128 rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824 netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309