Vulnerabilidades

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---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/dax: Corrección del problema "no omitir entradas bloqueadas al escanear entradas". El commit 6be3e21d25ca ("fs/dax: no omitir entradas bloqueadas al escanear entradas") introdujo una nueva función, wait_entry_unlocked_exclusive(), que espera a que la entrada actual se desbloquee sin avanzar el estado del iterador de XArray. Esperar a que la entrada se desbloquee requiere liberar el bloqueo de XArray. Esto requiere llamar a xas_pause() antes de liberar el bloqueo, lo que deja el xas en un estado adecuado para la siguiente iteración. Sin embargo, esto tiene el efecto secundario de avanzar el estado de xas al siguiente índice. Normalmente, esto no supone un problema, ya que xas_for_each() contiene código para detectar este estado y, por lo tanto, evitar avanzar el índice una segunda vez en la siguiente iteración del bucle. No obstante, tanto los que llaman a wait_entry_unlocked_exclusive() como la propia función wait_entry_unlocked_exclusive() utilizan posteriormente el estado de xas para recargar la entrada. Como xas_pause() actualiza el estado al próximo índice, esto provocará que se omita la entrada actual que se está esperando. Esto provocó que la siguiente advertencia se disparara de forma intermitente al ejecutar xftest generic/068 en un sistema de archivos XFS con FS DAX habilitado: [ 35.067397] ------------[ cortar aquí ]------------ [ 35.068229] ADVERTENCIA: CPU: 21 PID: 1640 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0xd8/0x1e0 [ 35.069717] Modules linked in: nd_pmem dax_pmem nd_btt nd_e820 libnvdimm [ 35.071006] CPU: 21 UID: 0 PID: 1640 Comm: fstest Not tainted 6.15.0-rc7+ #77 PREEMPT(voluntary) [ 35.072613] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/204 [ 35.074845] RIP: 0010:truncate_folio_batch_exceptionals+0xd8/0x1e0 [ 35.075962] Code: a1 00 00 00 f6 47 0d 20 0f 84 97 00 00 00 4c 63 e8 41 39 c4 7f 0b eb 61 49 83 c5 01 45 39 ec 7e 58 42 f68 [ 35.079522] RSP: 0018:ffffb04e426c7850 EFLAGS: 00010202 [ 35.080359] RAX: 0000000000000000 RBX: ffff9d21e3481908 RCX: ffffb04e426c77f4 [ 35.081477] RDX: ffffb04e426c79e8 RSI: ffffb04e426c79e0 RDI: ffff9d21e34816e8 [ 35.082590] RBP: ffffb04e426c79e0 R08: 0000000000000001 R09: 0000000000000003 [ 35.083733] R10: 0000000000000000 R11: 822b53c0f7a49868 R12: 000000000000001f [ 35.084850] R13: 0000000000000000 R14: ffffb04e426c78e8 R15: fffffffffffffffe [ 35.085953] FS: 00007f9134c87740(0000) GS:ffff9d22abba0000(0000) knlGS:0000000000000000 [ 35.087346] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 35.088244] CR2: 00007f9134c86000 CR3: 000000040afff000 CR4: 00000000000006f0 [ 35.089354] Call Trace: [ 35.089749] [ 35.090168] truncate_inode_pages_range+0xfc/0x4d0 [ 35.091078] truncate_pagecache+0x47/0x60 [ 35.091735] xfs_setattr_size+0xc7/0x3e0 [ 35.092648] xfs_vn_setattr+0x1ea/0x270 [ 35.093437] notify_change+0x1f4/0x510 [ 35.094219] ? do_truncate+0x97/0xe0 [ 35.094879] do_truncate+0x97/0xe0 [ 35.095640] path_openat+0xabd/0xca0 [ 35.096278] do_filp_open+0xd7/0x190 [ 35.096860] do_sys_openat2+0x8a/0xe0 [ 35.097459] __x64_sys_openat+0x6d/0xa0 [ 35.098076] do_syscall_64+0xbb/0x1d0 [ 35.098647] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 35.099444] RIP: 0033:0x7f9134d81fc1 [ 35.100033] Code: 75 57 89 f0 25 00 00 41 00 3d 00 00 41 00 74 49 80 3d 2a 26 0e 00 00 74 6d 89 da 48 89 ee bf 9c ff ff ff5 [ 35.102993] RSP: 002b:00007ffcd41e0d10 EFLAGS: 00000202 ORIG_RAX: 0000000000000101 [ 35.104263] RAX: ffffffffffffffda RBX: 0000000000000242 RCX: 00007f9134d81fc1 [ 35.105452] RDX: 0000000000000242 RSI: 00007ffcd41e1200 RDI: 00000000ffffff9c [ 35.106663] RBP: 00007ffcd41e1200 R08: 0000000000000000 R09: 0000000000000064 [ 35.107923] R10: 00000000000001a4 R11: 0000000000000202 R12: 0000000000000066 [ 35.109112] R13: 0000000000100000 R14: 0000000000100000 R15: 0000000000000400 [ 35.110357] [ 35.110769] irq event stamp: 8415587 [ 35.111486] hardirqs last enabled at (8415599): [] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: salida tras fallo de inserción de estado en btrfs_convert_extent_bit(). Si el estado insert_state() falla, devuelve un puntero de error y se llama a extent_io_tree_panic(), lo que activa una llamada a BUG(). Sin embargo, si CONFIG_BUG está deshabilitado (un escenario inusual y exótico), se pasa a la siguiente etapa y se llama a cache_state(), lo que desreferencia el puntero de error, lo que resulta en un acceso no válido a memoria. Por lo tanto, al saltar a la etiqueta "out" después de llamar a extent_io_tree_panic(), se aclara el código, además de abordar el escenario exótico donde CONFIG_BUG está deshabilitado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: drv: netdevsim: no ejecutar napi_complete() desde netpoll. netdevsim es compatible con netpoll. Asegúrese de no ejecutar napi_complete() desde él, ya que podría no estar programado. Breno informa de una advertencia en napi_complete_done(): ADVERTENCIA: CPU: 14 PID: 104 en net/core/dev.c:6592 napi_complete_done+0x2cc/0x560 __napi_poll+0x2d8/0x3a0 handle_softirqs+0x1fe/0x710. Presumiblemente, esto se debe a que netpoll robó el bit SCHED prematuramente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: impide una desreferencia NULL en rtnl_create_link(). Mientras rtnl_create_link() se ejecuta, dev->netdev_ops es NULL. No debemos usar netdev_lock_ops() o corremos el riesgo de una desreferencia NULL si CONFIG_NET_SHAPER está definido. Use netif_set_group() en lugar de dev_set_group(). RIP: 0010:netdev_need_ops_lock include/net/netdev_lock.h:33 [en línea] RIP: 0010:netdev_lock_ops include/net/netdev_lock.h:41 [en línea] RIP: 0010:dev_set_group+0xc0/0x230 net/core/dev_api.c:82 Rastreo de llamadas: rtnl_create_link+0x748/0xd10 net/core/rtnetlink.c:3674 rtnl_newlink_create+0x25c/0xb00 net/core/rtnetlink.c:3813 __rtnl_newlink net/core/rtnetlink.c:3940 [en línea] rtnl_newlink+0x16d6/0x1c70 net/core/rtnetlink.c:4055 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6944 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [en línea] netlink_unicast+0x75b/0x8d0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [en línea]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: b53: no habilitar EEE en bcm63xx. Los conmutadores internos BCM63xx no admiten EEE, pero proporcionan múltiples puertos RGMII donde se pueden conectar PHY externos. Si uno de estos PHY admite EEE, podemos intentar habilitar EEE para las MAC, lo que bloquea el sistema al acceder a los registros EEE (inexistentes). Para solucionar esto, verifique si el conmutador admite EEE antes de configurarlo.