Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/cpumf: Se corrige la doble liberación en caso de error en cpumf_pmu_event_init(). En las funciones de inicialización de eventos de PMU (cpumsf_pmu_event_init(), cpumf_pmu_event_init() y cfdiag_event_init()), el evento parcialmente creado debía eliminarse al detectarse un error. La función miembro event::event_init() debía liberar todos los recursos asignados en caso de error. Event::destroy() debía llamarse al liberar un evento después de su creación exitosa y event::event_init() devolvía la operación correcta. Con la confirmación c70ca298036c ("perf/core: Simplificar la ruta de error de perf_event_alloc()"), esto ya no es necesario. El código común del subsistema de rendimiento ahora siempre llama a event::destroy() para limpiar los recursos asignados creados durante la inicialización del evento. Elimine la invocación de event::destroy() en la inicialización de eventos de PMU, ya que dicha función se llama dos veces por cada evento que presenta una condición de error durante su creación. Esta es la entrada del registro del kernel que aparece sin la corrección: ------------[ cortar aquí ]------------ refcount_t: underflow; use-after-free. ADVERTENCIA: CPU: 0 PID: 43388 en lib/refcount.c:87 refcount_dec_not_one+0x74/0x90 CPU: 0 UID: 0 PID: 43388 Comm: perf No contaminado 6.15.0-20250407.rc1.git0.300.fc41.s390x+git #1 NINGUNO Nombre del hardware: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704c00180000000 00000209cb2c1b88 (refcount_dec_not_one+0x78/0x90) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 0000020900000027 0000020900000023 0000000000000026 0000018900000000 00000004a2200a00 0000000000000000 0000000000000057 ffffffffffffffea 00000002b386c600 00000002b3f5b3e0 00000209cc51f140 00000209cc7fc550 0000000001449d38 ffffffffffffffff 00000209cb2c1b84 00000189d67dfb80 Krnl Code: 00000209cb2c1b78: c02000506727 larl %r2,00000209cbcce9c6 00000209cb2c1b7e: c0e5ffbd4431 brasl %r14,00000209caa6a3e0 #00000209cb2c1b84: af000000 mc 0,0 >00000209cb2c1b88: a7480001 lhi %r4,1 00000209cb2c1b8c: ebeff0a00004 lmg %r14,%r15,160(%r15) 00000209cb2c1b92: ec243fbf0055 risbg %r2,%r4,63,191,0 00000209cb2c1b98: 07fe bcr 15,%r14 00000209cb2c1b9a: 47000700 bc 0,1792 Call Trace: [<00000209cb2c1b88>] refcount_dec_not_one+0x78/0x90 [<00000209cb2c1dc4>] refcount_dec_and_mutex_lock+0x24/0x90 [<00000209caa3c29e>] hw_perf_event_destroy+0x2e/0x80 [<00000209cacaf8b4>] __free_event+0x74/0x270 [<00000209cacb47c4>] perf_event_alloc.part.0+0x4a4/0x730 [<00000209cacbf3e8>] __do_sys_perf_event_open+0x248/0xc20 [<00000209cacc14a4>] __s390x_sys_perf_event_open+0x44/0x50 [<00000209cb8114de>] __do_syscall+0x12e/0x260 [<00000209cb81ce34>] system_call+0x74/0x98 Last Breaking-Event-Address: [<00000209caa6a4d2>] __warn_printk+0xf2/0x100 ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: pata_pxa: Se corrige la posible desreferencia de punteros nulos en pxa_ata_probe(). Devm_ioremap() devuelve NULL en caso de error. Actualmente, pxa_ata_probe() no verifica este caso, lo que puede provocar una desreferencia de punteros nulos. Agregue la comprobación de NULL después de devm_ioremap() para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: se corrige una fuga de memoria en tipc_link_xmit. Si la cola de transmisión de mensajes importantes del sistema está sobrecargada, tipc_link_xmit() devuelve -ENOBUFS, pero la lista de skb no se purga. Esto provoca una fuga de memoria y un fallo al asignar un skb. Esta confirmación corrige este problema purgando la lista de skb antes del retorno de tipc_link_xmit().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tls: explícitamente deshabilitar la desconexión. syzbot descubrió que puede desconectar un socket TLS y luego encontrarse con todo tipo de casos inesperados. Recuerdo vagamente que Eric nos lo señaló hace mucho tiempo. Admitir la desconexión es muy difícil; por ejemplo, si la descarga está habilitada, tendríamos que esperar a que se ackearan todos los paquetes. La desconexión no se usa comúnmente; deshabilitarla. El problema inmediato con el que se encuentra syzbot es la advertencia en el strp, pero ese es simplemente el error más fácil de activar: ADVERTENCIA: CPU: 0 PID: 5834 en net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Rastreo de llamada: tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [en línea] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: libwx: error en el controlador page_pool_dev_alloc_pages. page_pool_dev_alloc_pages podría devolver NULL. Se ejecutó un WARN_ON(!page), pero seguía usando el puntero NULL y se bloqueaba. Esto es similar a la confirmación 001ba0902046 ("net: fec: error en el controlador page_pool_dev_alloc_pages"). Esta vulnerabilidad fue detectada por nuestra herramienta de análisis estático Knighter.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/huc: corrección de la valla no liberada en errores de sondeo tempranos La valla de carga retrasada de HuC, introducida con la confirmación 27536e03271da ("drm/i915/huc: rastrear la carga retrasada de HuC con una valla"), se registra con el rastreador de objetos en las primeras etapas del sondeo del controlador, pero se desregistra solo desde la eliminación del controlador, que no se llama en errores de sondeo tempranos. Dado que su memoria se asigna en devres y luego se libera de todos modos, puede suceder que se asigne nuevamente a la valla y se reutilice en futuras sondas del controlador, lo que genera advertencias del kernel que contaminan el kernel: <4> [309.731371] ------------[ cortar aquí ]------------ <3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915] <4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0 ... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1 ... <4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0 ... <4> [309.731728] Call Trace: <4> [309.731730] ... <4> [309.731949] __debug_object_init+0x17b/0x1c0 <4> [309.731957] debug_object_init+0x34/0x50 <4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915] <4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915] <4> [309.732468] intel_uc_init_early+0x61/0x680 [i915] <4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915] <4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915] <4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915] <4> [309.733075] i915_pci_probe+0xe6/0x220 [i915] <4> [309.733198] local_pci_probe+0x44/0xb0 <4> [309.733203] pci_device_probe+0xf4/0x270 <4> [309.733209] really_probe+0xee/0x3c0 <4> [309.733215] __driver_probe_device+0x8c/0x180 <4> [309.733219] driver_probe_device+0x24/0xd0 <4> [309.733223] __driver_attach+0x10f/0x220 <4> [309.733230] bus_for_each_dev+0x7d/0xe0 <4> [309.733236] driver_attach+0x1e/0x30 <4> [309.733239] bus_add_driver+0x151/0x290 <4> [309.733244] driver_register+0x5e/0x130 <4> [309.733247] __pci_register_driver+0x7d/0x90 <4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915] <4> [309.733413] i915_init+0x34/0x120 [i915] <4> [309.733655] do_one_initcall+0x62/0x3f0 <4> [309.733667] do_init_module+0x97/0x2a0 <4> [309.733671] load_module+0x25ff/0x2890 <4> [309.733688] init_module_from_file+0x97/0xe0 <4> [309.733701] idempotent_init_module+0x118/0x330 <4> [309.733711] __x64_sys_finit_module+0x77/0x100 <4> [309.733715] x64_sys_call+0x1f37/0x2650 <4> [309.733719] do_syscall_64+0x91/0x180 <4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e <4> [309.733792] ... <4> [309.733806] ---[ fin de seguimiento 000000000000000 ]--- Este escenario se reproduce con mayor facilidad con igt@i915_module_load@reload-with-fault-injection. Solucione el problema trasladando el paso de limpieza a la ruta de la versión del controlador. (Seleccionado de la confirmación 795dbde92fe5c6996a02a5b579481de73035e7bf)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ublk: corrección del manejo de la recuperación y la reemisión en ublk_abort_queue(). La confirmación 8284066946e6 ("ublk: toma la referencia de la solicitud cuando la solicitud es manejada por el espacio de usuario") no toma la referencia de la solicitud en caso de reemisión de recuperación. En ese caso, la solicitud se puede volver a poner en cola y reenviar, y falla al cancelar el comando "uring". Si es una solicitud zc, la solicitud se puede liberar antes de que io_uring devuelva el buffer zc, y luego cause pánico en el kernel: [ 126.773061] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000c8 [ 126.773657] #PF: acceso de lectura del supervisor en modo kernel [ 126.774052] #PF: error_code(0x0000) - página no presente [ 126.774455] PGD 0 P4D 0 [ 126.774698] Oops: Oops: 0000 [#1] SMP NOPTI [ 126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 No contaminado 6.14.0_blk+ #182 PREEMPT(full) [ 126.775676] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 01/04/2014 [ 126.776275] Cola de trabajo: iou_exit io_ring_exit_work [ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv] Lo corrige tomando siempre la referencia de la solicitud para abortar la solicitud.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: sch_sfq: mover la validación del límite No es suficiente validar directamente el límite en los datos que pasa el usuario, ya que se puede actualizar en función de cómo se modifiquen los demás parámetros. Mueva la comprobación al final del proceso de actualización de configuración para que también detecte los escenarios en los que el límite se actualiza indirectamente, por ejemplo, con las siguientes configuraciones: tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 Depth 1 tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1 Esto corrige el siguiente fallo informado por syzkaller: ------------[ cortar aquí ]------------ UBSAN: array-index-out-of-bounds en net/sched/sch_sfq.c:203:6 el índice 65535 está fuera de rango para el tipo 'struct sfq_head[128]' CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 No contaminado 6.14.0-rc2-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/12/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [en línea] __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429 sfq_link net/sched/sch_sfq.c:203 [en línea] sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231 sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493 sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311 netdev_for_each_tx_queue include/linux/netdevice.h:2590 [en línea] dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ppp: Se ha añadido la comprobación de los límites para datos de skb en ppp_sync_txmung. Se garantiza que haya suficientes datos en el búfer lineal de skb antes de acceder a los bytes iniciales. Esto evita posibles accesos fuera de los límites al procesar paquetes cortos. Cuando ppp_sync_txmung recibe un paquete entrante con un payload vacía: (remoto) gef? p *(struct pppoe_hdr *) (skb->head + skb->network_header) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 } de la estructura skb (recortada) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0, no es seguro acceder a los datos[2]. [pabeni@redhat.com: error tipográfico corregido]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/mediatek: Se ha corregido la deferencia de puntero nulo en mtk_iommu_device_group. Actualmente, mtk_iommu invoca durante el sondeo de iommu_device_register antes de que se inicialice hw_list de los datos del controlador. Desde la corrección del problema de sondeo de iommu, este provoca la desreferencia de puntero nulo en mtk_iommu_device_group cuando se accede a hw_list con list_first_entry (no es seguro para nulos). Por lo tanto, se debe modificar el orden de las llamadas para garantizar que iommu_device_register se invoque después de inicializar los datos del controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Evitar fugas de memoria al habilitar las estadísticas. El controlador utiliza anillos de destino del monitor para el modo de estadísticas extendidas y el modo de monitor independiente. En el modo de estadísticas extendidas, los TLV se analizan desde el búfer recibido del anillo de destino del monitor y se asignan a la estructura ppdu_info para actualizar las estadísticas por paquete. En el modo de monitor independiente, junto con las estadísticas por paquete, se capturan los datos del paquete (carga útil) y el controlador actualiza por MSDU a mac80211. Cuando la interfaz AP está habilitada, solo se activa el modo de estadísticas extendidas. Como parte de la habilitación de los anillos de monitor para recopilar estadísticas, el controlador se suscribe al TLV HAL_RX_MPDU_START en la configuración del filtro. Este TLV se recibe del anillo de destino del monitor y se produce kzalloc para el objeto mon_mpdu, que no se libera, lo que provoca una fuga de memoria. El kzalloc para el objeto mon_mpdu solo es necesario mientras se habilita la interfaz de monitor independiente. Esto causa una fuga de memoria al habilitar el modo de estadísticas extendidas en el controlador. Solucione esta fuga de memoria eliminando el kzalloc del objeto mon_mpdu en la gestión de la TLV HAL_RX_MPDU_START. Además, elimine la gestión del modo de monitor independiente en las TLV HAL_MON_BUF_ADDR y HAL_RX_MSDU_END. Estas etiquetas TLV se gestionarán correctamente al habilitar el modo de monitor independiente en el futuro. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1. Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: se corrige la pérdida de memoria en ath12k_pci_remove() Kmemleak informó este error: objeto sin referencia 0xffff1c165cec3060 (tamaño 32): comm "insmod", pid 560, jiffies 4296964570 (edad 235.596s) backtrace: [<000000005434db68>] __kmem_cache_alloc_node+0x1f4/0x2c0 [<000000001203b155>] kmalloc_trace+0x40/0x88 [<0000000028adc9c8>] _request_firmware+0xb8/0x608 [<00000000cad1aef7>] firmware_request_nowarn+0x50/0x80 [<000000005011a682>] local_pci_probe+0x48/0xd0 [<00000000077cd295>] pci_device_probe+0xb4/0x200 [<0000000087184c94>] really_probe+0x150/0x2c0 La memoria del firmware se asignó en ath12k_pci_probe(), pero no se liberó en ath12k_pci_remove() si el bit ATH12K_FLAG_QMI_FAIL está activado. Por lo tanto, se llama ath12k_fw_unmap() para liberar la memoria. Probado en: WCN7850 hw2.0 PCI WLAN.HMT.2.0-02280-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1