Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath11k: corrección de corrupción de nodos en la lista ar->arvifs. En el flujo de código de recuperación de WLAN actual, ath11k_core_halt() solo reinicializa la cabecera de lista "arvifs". Esto provocará que el nodo de lista inmediatamente posterior a la cabecera de lista se convierta en un nodo de lista inválido. Esto se debe a que el nodo anterior de ese nodo aún apunta a la cabecera de lista "arvifs", pero el siguiente ya no apunta a ese nodo. Cuando se produce una recuperación de WLAN durante la ejecución de una eliminación de vif, y esto ocurre antes de spin_lock_bh(&ar->data_lock) en ath11k_mac_op_remove_interface(), list_del() detectará la situación mencionada anteriormente, lo que activará un pánico del kernel. La solución consiste en eliminar y reinicializar todos los nodos de lista vif de la cabecera de lista "arvifs" durante la detención de WLAN. La reinicialización sirve para hacer que los nodos de la lista sean válidos, garantizando que list_del() en ath11k_mac_op_remove_interface() pueda ejecutarse normalmente. Rastreo de llamadas: __list_del_entry_valid_or_report+0xb8/0xd0 ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k] drv_remove_interface+0x48/0x194 [mac80211] ieee80211_do_stop+0x6e0/0x844 [mac80211] ieee80211_stop+0x44/0x17c [mac80211] __dev_close_many+0xac/0x150 __dev_change_flags+0x194/0x234 dev_change_flags+0x24/0x6c devinet_ioctl+0x3a0/0x670 inet_ioctl+0x200/0x248 sock_do_ioctl+0x60/0x118 sock_ioctl+0x274/0x35c __arm64_sys_ioctl+0xac/0xf0 invoke_syscall+0x48/0x114 ... Probado en: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: at91: Se corrige un posible acceso fuera de los límites. at91_gpio_probe() no comprueba si el alias OF dado no está disponible o si algo salió mal al intentar obtenerlo. Esto podría tener consecuencias al acceder a la matriz gpio_chips con ese valor como índice. Tenga en cuenta que BUG() se puede compilar y, por lo tanto, no realizará las comprobaciones necesarias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: smartpqi: Corregir el seguimiento de llamadas smp_processor_id() para kernels preemptibles Corrija el seguimiento de llamadas al kernel cuando se llama a smp_processor_id() cuando se llama en kernels preemptibles mediante raw_smp_processor_id(). smp_processor_id() verifica si la preempción está deshabilitada y, si no lo está, emite un mensaje de error seguido de una llamada a dump_stack(). Breve ejemplo de seguimiento de llamada: kernel: check_preemption_disabled: 436 devoluciones de llamada suprimidas kernel: ERROR: uso de smp_processor_id() en código preemptible [00000000]: kworker/u1025:0/2354 kernel: el llamador es pqi_scsi_queue_command+0x183/0x310 [smartpqi] kernel: CPU: 129 PID: 2354 Comm: kworker/u1025:0 kernel: ... kernel: Workqueue: escritura diferida wb_workfn (flush-253:0) kernel: Seguimiento de llamada: kernel: kernel: dump_stack_lvl+0x34/0x48 kernel: check_preemption_disabled+0xdd/0xe0 kernel: pqi_scsi_queue_command+0x183/0x310 [smartpqi] núcleo: ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: QOS: Refactorizar la devolución de llamada TC_HTB_LEAF_DEL_LAST Este parche soluciona los siguientes problemas: 1. El tráfico activo en el nodo hoja debe detenerse antes de que su cola de envío se reasigne al padre. Este parche resuelve el problema marcando el nodo como "interno". 2. Durante un reinicio del sistema, la interfaz recibe las devoluciones de llamada TC_HTB_LEAF_DEL y TC_HTB_LEAF_DEL_LAST para eliminar sus colas HTB. En el caso de TC_HTB_LEAF_DEL_LAST, aunque la misma cola de envío se reasigne al padre, la lógica actual aún intenta actualizar el número real de colas, lo que genera las siguientes advertencias No se pueden registrar nuevas colas después de anular el registro del dispositivo. ADVERTENCIA: CPU: 0 PID: 6475 en net/core/net-sysfs.c:1714 netdev_queue_update_kobjects+0x1e4/0x200

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: pci: configurar el modo DAC manual solo mediante la API de configuración PCI. Para admitir DMA de 36 bits, configure el bit propietario del chip mediante la API de configuración PCI o la interfaz DBI del chip. Sin embargo, el mmap del dispositivo PCI aún no está configurado y el DBI tampoco es accesible mediante mmap. Por lo tanto, solo si se puede acceder al bit mediante la API de configuración PCI, el chip admite DMA de 36 bits. De lo contrario, se recurre al DMA de 32 bits. Con una dirección mmap NULL, el núcleo genera el siguiente seguimiento: ERROR: no se puede controlar el error de página para la dirección: 0000000000001090 #PF: acceso de escritura del supervisor en modo núcleo #PF: error_code(0x0002) - página no presente PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 71 Comm: irq/26-pciehp Tainted: G OE 6.14.2-061402-generic #202504101348 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE RIP: 0010:rtw89_pci_ops_write16+0x12/0x30 [rtw89_pci] RSP: 0018:ffffb0ffc0acf9d8 EFLAGS: 00010206 RAX: ffffffffc158f9c0 RBX: ffff94865e702020 RCX: 0000000000000000 RDX: 0000000000000718 RSI: 0000000000001090 RDI: ffff94865e702020 RBP: ffffb0ffc0acf9d8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000015 R13: 0000000000000719 R14: ffffb0ffc0acfa1f R15: ffffffffc1813060 FS: 0000000000000000(0000) GS:ffff9486f3480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001090 CR3: 0000000090440001 CR4: 00000000000626f0 Call Trace: rtw89_pci_read_config_byte+0x6d/0x120 [rtw89_pci] rtw89_pci_cfg_dac+0x5b/0xb0 [rtw89_pci] rtw89_pci_probe+0xa96/0xbd0 [rtw89_pci] ? __pfx___device_attach_driver+0x10/0x10 ? __pfx___device_attach_driver+0x10/0x10 local_pci_probe+0x47/0xa0 pci_call_probe+0x5d/0x190 pci_device_probe+0xa7/0x160 really_probe+0xf9/0x370 ? pm_runtime_barrier+0x55/0xa0 __driver_probe_device+0x8c/0x140 driver_probe_device+0x24/0xd0 __device_attach_driver+0xcd/0x170 bus_for_each_drv+0x99/0x100 __device_attach+0xb4/0x1d0 device_attach+0x10/0x20 pci_bus_add_device+0x59/0x90 pci_bus_add_devices+0x31/0x80 pciehp_configure_device+0xaa/0x170 pciehp_enable_slot+0xd6/0x240 pciehp_handle_presence_or_link_change+0xf1/0x180 pciehp_ist+0x162/0x1c0 irq_thread_fn+0x24/0x70 irq_thread+0xef/0x1c0 ? __pfx_irq_thread_fn+0x10/0x10 ? __pfx_irq_thread_dtor+0x10/0x10 ? __pfx_irq_thread+0x10/0x10 kthread+0xfc/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x47/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hisi_acc_vfio_pci: corrección de errores en la función de migración en vivo sin controlador de dispositivo VF. Si el controlador de dispositivo VF no está cargado en el sistema operativo invitado e intentamos migrar los datos del dispositivo, la dirección de los datos migrados será nula. La operación de recuperación de la migración en vivo en el destino accederá a una dirección nula, lo que provocará errores de acceso. Por lo tanto, la migración en vivo de máquinas virtuales sin controladores de dispositivo VF añadidos no requiere la migración de datos del dispositivo. Además, si los datos de dirección de la cola obtenidos por el destino están vacíos, no se realizará el procesamiento de recuperación de la cola del dispositivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7996: Se ha añadido una comprobación de NULL en mt7996_thermal_init. Devm_kasprintf() puede devolver un puntero NULL en caso de error, pero este valor devuelto en mt7996_thermal_init() no se comprueba. Se ha añadido una comprobación de NULL en mt7996_thermal_init() para gestionar el error de desreferencia de puntero NULL del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Fix WARN() en get_bpf_raw_tp_regs syzkaller informó de un problema: ADVERTENCIA: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 Un punto de seguimiento como trace_mmap_lock_acquire_returned puede causar una llamada anidada, como se muestra en el caso anterior, que se resolverá con un método más general en el futuro. Como resultado, se activará WARN_ON_ONCE. Como sugirió Alexei, elimine primero WARN_ON_ONCE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kernfs: relajar restricción en el drenaje de la protección El ciclo de vida de la referencia activa proporciona el mecanismo de interrupción/desconexión, pero la referencia activa no está verdaderamente activa después de la conexión; los llamadores no la usan después, pero es importante para el emparejamiento adecuado del conteo kn->activo. Suponiendo que este mecanismo está en su lugar, la comprobación WARN en kernfs_should_drain_open_files() es demasiado sensible - puede atrapar transitoriamente a aquellos llamadores (legítimos) entre kernfs_unbreak_active_protection() y kernfs_put_active() como descubrió Chen Ridong: kernfs_remove_by_name_ns kernfs_get_active // active=1 __kernfs_remove // active=0x80000002 kernfs_drain ... wait_event //waiting (active == 0x80000001) kernfs_break_active_protection // active = 0x80000001 // continuar kernfs_unbreak_active_protection // active = 0x80000002 ... kernfs_should_drain_open_files // ocurre una advertencia kernfs_put_active Para evitar los falsos positivos (tenga en cuenta "panic_on_warn"), elimine la comprobación por completo. (Esto es una solución rápida; creo que la interrupción/desconexión de referencias activas se puede simplificar con una revisión más exhaustiva).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: evitar __bpf_prog_ret0_warn cuando falla jit syzkaller informó un problema: ADVERTENCIA: CPU: 3 PID: 217 en kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357 Módulos vinculados: CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 No contaminado 6.15.0-rc4-syzkaller-00040-g8bac8898fe39 RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357 Rastreo de llamadas: bpf_dispatcher_nop_func include/linux/bpf.h:1316 [en línea] __bpf_prog_run include/linux/filter.h:718 [en línea] bpf_prog_run include/linux/filter.h:725 [en línea] cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105 ... Al crear un programa bpf, 'fp->jit_requested' depende de bpf_jit_enable. Este problema se produce porque CONFIG_BPF_JIT_ALWAYS_ON no está configurado y bpf_jit_enable está configurado en 1, lo que provoca que la arquitectura intente ejecutar el programa JIT, pero el JIT falla debido a FAULT_INJECTION. Como resultado, trata incorrectamente el programa como válido, cuando el programa se ejecuta llama a `__bpf_prog_ret0_warn` y activa WARN_ON_ONCE(1).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: nand: ecc-mxic: Se corrige el uso de la variable ret sin inicializar. Si ctx->steps es cero, se omite el procesamiento del bucle de pasos ECC y la variable ret permanece sin inicializar. Posteriormente, se verifica y se devuelve, lo que genera un comportamiento indefinido y puede causar resultados impredecibles en el espacio de usuario o fallos del kernel. Este escenario puede activarse en casos extremos, como una geometría mal configurada, un uso indebido del motor ECC o si ctx->steps no se valida tras la inicialización. Inicialice ret a cero antes del bucle para garantizar un comportamiento correcto y seguro, independientemente del valor de ctx->steps. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: No incluir el registro ptr de pila en la contabilidad de retroceso de precisión Yi Lai informó de un problema ([1]) en el que aparece la siguiente advertencia en el dmesg del kernel: [ 60.643604] error de retroceso del verificador [ 60.643635] ADVERTENCIA: CPU: 10 PID: 2315 at kernel/bpf/verifier.c:4302 __mark_chain_precision+0x3a6c/0x3e10 [ 60.648428] Modules linked in: bpf_testmod(OE) [ 60.650471] CPU: 10 UID: 0 PID: 2315 Comm: test_progs Tainted: G OE 6.15.0-rc4-gef11287f8289-dirty #327 PREEMPT(full) [ 60.654385] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 60.656682] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 60.660475] RIP: 0010:__mark_chain_precision+0x3a6c/0x3e10 [ 60.662814] Code: 5a 30 84 89 ea e8 c4 d9 01 00 80 3d 3e 7d d8 04 00 0f 85 60 fa ff ff c6 05 31 7d d8 04 01 48 c7 c7 00 58 30 84 e8 c4 06 a5 ff <0f> 0b e9 46 fa ff ff 48 ... [ 60.668720] RSP: 0018:ffff888116cc7298 EFLAGS: 00010246 [ 60.671075] RAX: 54d70e82dfd31900 RBX: ffff888115b65e20 RCX: 0000000000000000 [ 60.673659] RDX: 0000000000000001 RSI: 0000000000000004 RDI: 00000000ffffffff [ 60.676241] RBP: 0000000000000400 R08: ffff8881f6f23bd3 R09: 1ffff1103ede477a [ 60.678787] R10: dffffc0000000000 R11: ffffed103ede477b R12: ffff888115b60ae8 [ 60.681420] R13: 1ffff11022b6cbc4 R14: 00000000fffffff2 R15: 0000000000000001 [ 60.684030] FS: 00007fc2aedd80c0(0000) GS:ffff88826fa8a000(0000) knlGS:0000000000000000 [ 60.686837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 60.689027] CR2: 000056325369e000 CR3: 000000011088b002 CR4: 0000000000370ef0 [ 60.691623] Call Trace: [ 60.692821] [ 60.693960] ? __pfx_verbose+0x10/0x10 [ 60.695656] ? __pfx_disasm_kfunc_name+0x10/0x10 [ 60.697495] check_cond_jmp_op+0x16f7/0x39b0 [ 60.699237] do_check+0x58fa/0xab10 ... Further analysis shows the warning is at line 4302 as below: 4294 /* static subprog call instruction, which 4295 * means that we are exiting current subprog, 4296 * so only r1-r5 could be still requested as 4297 * precise, r0 and r6-r10 or any stack slot in 4298 * the current frame should be zero by now 4299 */ 4300 if (bt_reg_mask(bt) & ~BPF_REGMASK_ARGS) { 4301 verbose(env, "BUG regs %x\n", bt_reg_mask(bt)); 4302 WARN_ONCE(1, "verifier backtracking bug"); 4303 return -EFAULT; 4304 } With the below test (also in the next patch): __used __naked static void __bpf_jmp_r10(void) { asm volatile ( "r2 = 2314885393468386424 ll;" "goto +0;" "if r2 <= r10 goto +3;" "if r1 >= -1835016 goto +0;" "if r2 <= 8 goto +0;" "if r3 <= 0 goto +0;" "exit;" ::: __clobber_all); } SEC("?raw_tp") __naked void bpf_jmp_r10(void) { asm volatile ( "r3 = 0 ll;" "call __bpf_jmp_r10;" "r0 = 0;" "exit;" ::: __clobber_all); } The following is the verifier failure log: 0: (18) r3 = 0x0 ; R3_w=0 2: (85) call pc+2 caller: R10=fp0 callee: frame1: R1=ctx() R3_w=0 R10=fp0 5: frame1: R1=ctx() R3_w=0 R10=fp0 ; asm volatile (" \ @ verifier_precision.c:184 5: (18) r2 = 0x20202000256c6c78 ; frame1: R2_w=0x20202000256c6c78 7: (05) goto pc+0 8: (bd) if r2 <= r10 goto pc+3 ; frame1: R2_w=0x20202000256c6c78 R10=fp0 9: (35) if r1 >= 0xffe3fff8 goto pc+0 ; frame1: R1=ctx() 10: (b5) if r2 <= 0x8 goto pc+0 mark_precise: frame1: last_idx 10 first_idx 0 subseq_idx -1 mark_precise: frame1: regs=r2 stack= before 9: (35) if r1 >= 0xffe3fff8 goto pc+0 mark_precise: frame1: regs=r2 stack= before 8: (bd) if r2 <= r10 goto pc+3 mark_preci ---truncado---