Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().<br /> <br /> As syzbot reported [0], mpls_route_input_rcu() can be called<br /> from mpls_getroute(), where is under RTNL.<br /> <br /> net-&gt;mpls.platform_label is only updated under RTNL.<br /> <br /> Let&amp;#39;s use rcu_dereference_rtnl() in mpls_route_input_rcu() to<br /> silence the splat.<br /> <br /> [0]:<br /> WARNING: suspicious RCU usage<br /> 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted<br /> ----------------------------<br /> net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by syz.2.4451/17730:<br /> #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]<br /> #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961<br /> <br /> stack backtrace:<br /> CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120<br /> lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865<br /> mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84<br /> mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381<br /> rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964<br /> netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]<br /> netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339<br /> netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg net/socket.c:727 [inline]<br /> ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566<br /> ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620<br /> __sys_sendmmsg+0x200/0x420 net/socket.c:2709<br /> __do_sys_sendmmsg net/socket.c:2736 [inline]<br /> __se_sys_sendmmsg net/socket.c:2733 [inline]<br /> __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f0a2818e969<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133<br /> RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969<br /> RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003<br /> RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: add free_transport ops in ksmbd connection<br /> <br /> free_transport function for tcp connection can be called from smbdirect.<br /> It will cause kernel oops. This patch add free_transport ops in ksmbd<br /> connection, and add each free_transports for tcp and smbdirect.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> aoe: clean device rq_list in aoedev_downdev()<br /> <br /> An aoe device&amp;#39;s rq_list contains accepted block requests that are<br /> waiting to be transmitted to the aoe target. This queue was added as<br /> part of the conversion to blk_mq. However, the queue was not cleaned out<br /> when an aoe device is downed which caused blk_mq_freeze_queue() to sleep<br /> indefinitely waiting for those requests to complete, causing a hang. This<br /> fix cleans out the queue before calling blk_mq_freeze_queue().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fgraph: Do not enable function_graph tracer when setting funcgraph-args<br /> <br /> When setting the funcgraph-args option when function graph tracer is net<br /> enabled, it incorrectly enables it. Worse, it unregisters itself when it<br /> was never registered. Then when it gets enabled again, it will register<br /> itself a second time causing a WARNing.<br /> <br /> ~# echo 1 &gt; /sys/kernel/tracing/options/funcgraph-args<br /> ~# head -20 /sys/kernel/tracing/trace<br /> # tracer: nop<br /> #<br /> # entries-in-buffer/entries-written: 813/26317372 #P:8<br /> #<br /> # _-----=&gt; irqs-off/BH-disabled<br /> # / _----=&gt; need-resched<br /> # | / _---=&gt; hardirq/softirq<br /> # || / _--=&gt; preempt-depth<br /> # ||| / _-=&gt; migrate-disable<br /> # |||| / delay<br /> # TASK-PID CPU# ||||| TIMESTAMP FUNCTION<br /> # | | | ||||| | |<br /> -0 [007] d..4. 358.966010: 7) 1.692 us | fetch_next_timer_interrupt(basej=4294981640, basem=357956000000, base_local=0xffff88823c3ae040, base_global=0xffff88823c3af300, tevt=0xffff888100e47cb8);<br /> -0 [007] d..4. 358.966012: 7) | tmigr_cpu_deactivate(nextexp=357988000000) {<br /> -0 [007] d..4. 358.966013: 7) | _raw_spin_lock(lock=0xffff88823c3b2320) {<br /> -0 [007] d..4. 358.966014: 7) 0.981 us | preempt_count_add(val=1);<br /> -0 [007] d..5. 358.966017: 7) 1.058 us | do_raw_spin_lock(lock=0xffff88823c3b2320);<br /> -0 [007] d..4. 358.966019: 7) 5.824 us | }<br /> -0 [007] d..5. 358.966021: 7) | tmigr_inactive_up(group=0xffff888100cb9000, child=0x0, data=0xffff888100e47bc0) {<br /> -0 [007] d..5. 358.966022: 7) | tmigr_update_events(group=0xffff888100cb9000, child=0x0, data=0xffff888100e47bc0) {<br /> <br /> Notice the "tracer: nop" at the top there. The current tracer is the "nop"<br /> tracer, but the content is obviously the function graph tracer.<br /> <br /> Enabling function graph tracing will cause it to register again and<br /> trigger a warning in the accounting:<br /> <br /> ~# echo function_graph &gt; /sys/kernel/tracing/current_tracer<br /> -bash: echo: write error: Device or resource busy<br /> <br /> With the dmesg of:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 7 PID: 1095 at kernel/trace/ftrace.c:3509 ftrace_startup_subops+0xc1e/0x1000<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 7 UID: 0 PID: 1095 Comm: bash Not tainted 6.16.0-rc2-test-00006-gea03de4105d3 #24 PREEMPT<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:ftrace_startup_subops+0xc1e/0x1000<br /> Code: 48 b8 22 01 00 00 00 00 ad de 49 89 84 24 88 01 00 00 8b 44 24 08 89 04 24 e9 c3 f7 ff ff c7 04 24 ed ff ff ff e9 b7 f7 ff ff 0b c7 04 24 f0 ff ff ff e9 a9 f7 ff ff c7 04 24 f4 ff ff ff e9<br /> RSP: 0018:ffff888133cff948 EFLAGS: 00010202<br /> RAX: 0000000000000001 RBX: 1ffff1102679ff31 RCX: 0000000000000000<br /> RDX: 1ffffffff0b27a60 RSI: ffffffff8593d2f0 RDI: ffffffff85941140<br /> RBP: 00000000000c2041 R08: ffffffffffffffff R09: ffffed1020240221<br /> R10: ffff88810120110f R11: ffffed1020240214 R12: ffffffff8593d2f0<br /> R13: ffffffff8593d300 R14: ffffffff85941140 R15: ffffffff85631100<br /> FS: 00007f7ec6f28740(0000) GS:ffff8882b5251000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f7ec6f181c0 CR3: 000000012f1d0005 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> ? __pfx_ftrace_startup_subops+0x10/0x10<br /> ? find_held_lock+0x2b/0x80<br /> ? ftrace_stub_direct_tramp+0x10/0x10<br /> ? ftrace_stub_direct_tramp+0x10/0x10<br /> ? trace_preempt_on+0xd0/0x110<br /> ? __pfx_trace_graph_entry_args+0x10/<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()<br /> <br /> KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().<br /> <br /> Call Trace:<br /> [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8<br /> [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550<br /> [ 97.285732]<br /> [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11<br /> [ 97.287032] Hardware name: linux,dummy-virt (DT)<br /> [ 97.287815] Call trace:<br /> [ 97.288279] dump_backtrace+0xa0/0x128<br /> [ 97.288946] show_stack+0x20/0x38<br /> [ 97.289551] dump_stack_lvl+0x78/0xc8<br /> [ 97.290203] print_address_description.constprop.0+0x84/0x3c8<br /> [ 97.291159] print_report+0xb0/0x280<br /> [ 97.291792] kasan_report+0x84/0xd0<br /> [ 97.292421] __asan_load8+0x9c/0xc0<br /> [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8<br /> [ 97.293835] process_fetch_insn+0x770/0xa30<br /> [ 97.294562] kprobe_trace_func+0x254/0x3b0<br /> [ 97.295271] kprobe_dispatcher+0x98/0xe0<br /> [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210<br /> [ 97.296774] call_break_hook+0xc4/0x100<br /> [ 97.297451] brk_handler+0x24/0x78<br /> [ 97.298073] do_debug_exception+0xac/0x178<br /> [ 97.298785] el1_dbg+0x70/0x90<br /> [ 97.299344] el1h_64_sync_handler+0xcc/0xe8<br /> [ 97.300066] el1h_64_sync+0x78/0x80<br /> [ 97.300699] kernel_clone+0x0/0x500<br /> [ 97.301331] __arm64_sys_clone+0x70/0x90<br /> [ 97.302084] invoke_syscall+0x68/0x198<br /> [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150<br /> [ 97.303569] do_el0_svc+0x38/0x50<br /> [ 97.304164] el0_svc+0x44/0x1d8<br /> [ 97.304749] el0t_64_sync_handler+0x100/0x130<br /> [ 97.305500] el0t_64_sync+0x188/0x190<br /> [ 97.306151]<br /> [ 97.306475] The buggy address belongs to stack of task 1.sh/2550<br /> [ 97.307461] and is located at offset 0 in frame:<br /> [ 97.308257] __se_sys_clone+0x0/0x138<br /> [ 97.308910]<br /> [ 97.309241] This frame has 1 object:<br /> [ 97.309873] [48, 184) &amp;#39;args&amp;#39;<br /> [ 97.309876]<br /> [ 97.310749] The buggy address belongs to the virtual mapping at<br /> [ 97.310749] [ffff800089270000, ffff800089279000) created by:<br /> [ 97.310749] dup_task_struct+0xc0/0x2e8<br /> [ 97.313347]<br /> [ 97.313674] The buggy address belongs to the physical page:<br /> [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a<br /> [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff)<br /> [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000<br /> [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000<br /> [ 97.319445] page dumped because: kasan: bad access detected<br /> [ 97.320371]<br /> [ 97.320694] Memory state around the buggy address:<br /> [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 97.323846] &gt;ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00<br /> [ 97.325023] ^<br /> [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3<br /> [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> <br /> This issue seems to be related to the behavior of some gcc compilers and<br /> was also fixed on the s390 architecture before:<br /> <br /> commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")<br /> <br /> As described in that commit, regs_get_kernel_stack_nth() has confirmed that<br /> `addr` is on the stack, so reading the value at `*addr` should be allowed.<br /> Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case.<br /> <br /> [will: Use &amp;#39;*addr&amp;#39; as the argument to READ_ONCE_NOCHECK()]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iavf: eliminar el bloqueo crítico. Eliminar el bloqueo crítico. Esto nos libera de la lógica propensa a errores de try_locks. Gracias a netdev_lock() de Jakub, ahora es fácil, y en la mayoría de los casos ya estábamos protegidos por él: reemplazar el bloqueo crítico por el bloqueo netdev cuando no era el caso. Lockdep informa que debemos cancelar el trabajo bajo crit_lock [splat1], y ese fue el esquema que hemos seguido principalmente desde [1] de Slawomir. Pero una vez hecho esto, seguimos teniendo interbloqueos [splat2]. Así que, en lugar de eso, deberíamos analizar el problema más grave, es decir, el "bloqueo/programación extraño" de iavf. El primer paso para solucionarlo es eliminar el bloqueo crítico. Seguiré con una serie de -next que simplifica la programación/tareas. Cancelar el trabajo sin el bloqueo de netdev (un esquema extraño de desbloqueo y bloqueo) para corregir el [splat2] (que sería un desastre si hubiéramos mantenido el bloqueo crítico). Extender la parte protegida de iavf_watchdog_task() para incluir la programación de más trabajo. Tenga en cuenta que el comentario eliminado en iavf_reset_task() estaba mal ubicado; pertenecía a la condición if eliminada, por lo que ya no está. [splat1] - sin este parche - El bloqueo durante la eliminación de VF: ADVERTENCIA: se detectó una posible dependencia de bloqueo circular sh/3825 está intentando adquirir el bloqueo: ((work_completion)(&amp;amp;(&amp;amp;adapter-&amp;gt;watchdog_task)-&amp;gt;work)){+.+.}-{0:0}, en: start_flush_work+0x1a1/0x470 pero la tarea ya tiene el bloqueo: (&amp;amp;adapter-&amp;gt;crit_lock){+.+.}-{4:4}, en: iavf_remove+0xd1/0x690 [iavf] cuyo bloqueo ya depende del nuevo bloqueo. [splat2] - al cancelar trabajo bajo bloqueo crítico, sin esta serie, vea [2] para el intento de curita ADVERTENCIA: posible dependencia de bloqueo circular detectada sh/3550 está intentando adquirir el bloqueo: ((wq_completion)iavf){+.+.}-{0:0}, en: touch_wq_lockdep_map+0x26/0x90 pero la tarea ya tiene el bloqueo: (&amp;amp;dev-&amp;gt;lock){+.+.}-{4:4}, en: iavf_remove+0xa6/0x6e0 [iavf] cuyo bloqueo ya depende del nuevo bloqueo. [1] fc2e6b3b132a ("iavf: Rehacer mutexes para mejor sincronización") [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: core: fbcvt: evitar la división por 0 en fb_cvt_hperiod(). En fb_find_mode_cvt(), si mode-&amp;gt;refresh resulta ser 0x80000000, cvt.f_refresh se convertirá en 0 al multiplicarlo por 2 debido a un desbordamiento. Luego se pasa a fb_cvt_hperiod(), donde se usa como divisor; la división por 0 provocará un error en el kernel. Añada una comprobación de seguridad para cvt.f_refresh para evitar dicho desbordamiento. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con la herramienta de análisis estático Svace.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: fsl-mc: corrección de doble liberación en mc_dev La confirmación criticada intentó simplificar cómo se realizan las desasignaciones pero, en el proceso, introdujo una doble liberación en la variable mc_dev. En caso de que el dispositivo MC sea un DPRC, se asigna un nuevo mc_bus y la variable mc_dev es solo una referencia a uno de sus campos. En esta circunstancia, en la ruta de error solo se debe liberar mc_bus. Esta confirmación introduce de nuevo la siguiente advertencia checkpatch que es un falso positivo. ADVERTENCIA: kfree(NULL) es seguro y esta comprobación probablemente no sea necesaria + if (mc_bus) + kfree(mc_bus);

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-pci: Se corrige el tamaño del resultado devuelto para la finalización del comando admin El tamaño del resultado devuelto por virtio_pci_admin_dev_parts_get() es 8 bytes más grande que el tamaño real de los datos del resultado. Esto ocurre porque el campo result_sg_size del comando se llena con la longitud del resultado de virtqueue_get_buf(), que incluye tanto el tamaño de los datos como 8 bytes adicionales de estado. Este tamaño de resultado sobredimensionado causa dos problemas: 1. El estado transferido al destino incluye 8 bytes de datos adicionales al final. 2. El búfer asignado en el kernel puede ser más pequeño que el tamaño devuelto, lo que provoca fallas al leer más allá del tamaño asignado. La confirmación corrige esto restando el tamaño del estado del resultado de virtqueue_get_buf(). Esta corrección se ha probado a través de migraciones en vivo con dispositivos virtio-net, virtio-net-transitional y virtio-blk.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btintel: Verificar el tamaño de dsbr desde la variable EFI. Dado que el tamaño de struct btintel_dsbr ya se conoce, podemos empezar por ahí en lugar de consultar el tamaño de la variable EFI. Si el resultado final no coincide con lo esperado, también falla. Esto corrige un desbordamiento del búfer de pila cuando la variable EFI es mayor que struct btintel_dsbr.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7996: evitar la desreferencia de punteros nulos en mt7996_set_monitor(). La función mt7996_set_monitor() desreferencia phy antes de la comprobación de validez de punteros nulos. Corrija esto para evitar la desreferencia de punteros nulos moviendo la desreferencia después de la comprobación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Se corrige el desbordamiento de búfer en debugfs. Si el usuario intenta escribir más de 32 bytes, se produce una corrupción de memoria. Afortunadamente, esto es debugfs, por lo que está limitado a usuarios root.