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: 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: 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: 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: 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: 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: 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: HID: uclogic: Añadir comprobación de valores NULL en uclogic_input_configured(). Devm_kasprintf() devuelve NULL cuando falla la asignación de memoria. Actualmente, uclogic_input_configured() no comprueba este caso, lo que provoca una desreferencia de puntero NULL. Añadir comprobación de valores NULL después de devm_kasprintf() para evitar este problema.

En Grafana, un título o nombre de panel excesivamente largo provocará que los navegadores Chromium dejen de responder debido a una vulnerabilidad de validación de entrada incorrecta. Este problema afecta a Grafana en versiones anteriores a la 11.6.2 y se ha corregido en la 11.6.2 y posteriores.

La vulnerabilidad de autorización faltante en Cloudways Breeze permite explotar niveles de seguridad de control de acceso configurados incorrectamente. Este problema afecta a Breeze: desde n/a hasta 2.2.13.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: ti: k3-udma: Agregar bloqueo faltante Los kernels recientes se quejan de un bloqueo faltante en k3-udma.c cuando el validador de bloqueo está habilitado: [ 4.128073] ADVERTENCIA: CPU: 0 PID: 746 en drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238 [ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 No contaminado 6.12.9-arm64 #28 [ 4.144867] Nombre del hardware: pp-v12 (DT) [ 4.148648] Cola de trabajo: eventos events udma_check_tx_completion [ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.160834] pc : udma_start.isra.0+0x34/0x238 [ 4.165227] lr : udma_start.isra.0+0x30/0x238 [ 4.169618] sp : ffffffc083cabcf0 [ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005 [ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000 [ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670 [ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030 [ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048 [ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001 [ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68 [ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8 [ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000 [ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000 [ 4.244986] Call trace: [ 4.247463] udma_start.isra.0+0x34/0x238 [ 4.251509] udma_check_tx_completion+0xd0/0xdc [ 4.256076] process_one_work+0x244/0x3fc [ 4.260129] process_scheduled_works+0x6c/0x74 [ 4.264610] worker_thread+0x150/0x1dc [ 4.268398] kthread+0xd8/0xe8 [ 4.271492] ret_from_fork+0x10/0x20 [ 4.275107] irq event stamp: 220 [ 4.278363] hardirqs last enabled at (219): [] _raw_spin_unlock_irq+0x38/0x50 [ 4.287183] hardirqs last disabled at (220): [] el1_dbg+0x24/0x50 [ 4.294879] softirqs last enabled at (182): [] handle_softirqs+0x1c0/0x3cc [ 4.303437] softirqs last disabled at (177): [] __do_softirq+0x1c/0x28 [ 4.311559] ---[ fin del seguimiento 0000000000000000 ]--- Esta confirmación agrega el bloqueo faltante.