Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: ip_gre: make ipgre_header() robust<br /> <br /> Analog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")<br /> <br /> Over the years, syzbot found many ways to crash the kernel<br /> in ipgre_header() [1].<br /> <br /> This involves team or bonding drivers ability to dynamically<br /> change their dev-&gt;needed_headroom and/or dev-&gt;hard_header_len<br /> <br /> In this particular crash mld_newpack() allocated an skb<br /> with a too small reserve/headroom, and by the time mld_sendpack()<br /> was called, syzbot managed to attach an ipgre device.<br /> <br /> [1]<br /> skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0<br /> kernel BUG at net/core/skbuff.c:213 !<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Workqueue: mld mld_ifc_work<br /> RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213<br /> Call Trace:<br /> <br /> skb_under_panic net/core/skbuff.c:223 [inline]<br /> skb_push+0xc3/0xe0 net/core/skbuff.c:2641<br /> ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897<br /> dev_hard_header include/linux/netdevice.h:3436 [inline]<br /> neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618<br /> NF_HOOK_COND include/linux/netfilter.h:307 [inline]<br /> ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247<br /> NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318<br /> mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855<br /> mld_send_cr net/ipv6/mcast.c:2154 [inline]<br /> mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693<br /> process_one_work kernel/workqueue.c:3257 [inline]<br /> process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421<br /> kthread+0x711/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: fix device leaks on compat bind and unbind<br /> <br /> Make sure to drop the reference taken when looking up the idxd device as<br /> part of the compat bind and unbind sysfs interface.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Don&amp;#39;t store mlx5e_priv in mlx5e_dev devlink priv<br /> <br /> mlx5e_priv is an unstable structure that can be memset(0) if profile<br /> attaching fails, mlx5e_priv in mlx5e_dev devlink private is used to<br /> reference the netdev and mdev associated with that struct. Instead,<br /> store netdev directly into mlx5e_dev and get mdev from the containing<br /> mlx5_adev aux device structure.<br /> <br /> This fixes a kernel oops in mlx5e_remove when switchdev mode fails due<br /> to change profile failure.<br /> <br /> $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev<br /> Error: mlx5_core: Failed setting eswitch to offloads.<br /> dmesg:<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12<br /> <br /> $ devlink dev reload pci/0000:00:03.0 ==&gt; oops<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000520<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:mlx5e_remove+0x68/0x130<br /> RSP: 0018:ffffc900034838f0 EFLAGS: 00010246<br /> RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000<br /> RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10<br /> R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0<br /> R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400<br /> FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0<br /> Call Trace:<br /> <br /> device_release_driver_internal+0x19c/0x200<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x160/0x3d0<br /> ? devl_param_driverinit_value_get+0x2d/0x90<br /> mlx5_detach_device+0x89/0xe0<br /> mlx5_unload_one_devl_locked+0x3a/0x70<br /> mlx5_devlink_reload_down+0xc8/0x220<br /> devlink_reload+0x7d/0x260<br /> devlink_nl_reload_doit+0x45b/0x5a0<br /> genl_family_rcv_msg_doit+0xe8/0x140

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts<br /> <br /> Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is<br /> called only when the timer is enabled, we need to call<br /> j1939_session_deactivate_activate_next() if we cancelled the timer.<br /> Otherwise, refcount for j1939_session leaks, which will later appear as<br /> <br /> | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2.<br /> <br /> problem.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec<br /> <br /> Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")<br /> added ttag bounds checking and data_offset<br /> validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate<br /> whether the command&amp;#39;s data structures (cmd-&gt;req.sg and cmd-&gt;iov) have<br /> been properly initialized before processing H2C_DATA PDUs.<br /> <br /> The nvmet_tcp_build_pdu_iovec() function dereferences these pointers<br /> without NULL checks. This can be triggered by sending H2C_DATA PDU<br /> immediately after the ICREQ/ICRESP handshake, before<br /> sending a CONNECT command or NVMe write command.<br /> <br /> Attack vectors that trigger NULL pointer dereferences:<br /> 1. H2C_DATA PDU sent before CONNECT → both pointers NULL<br /> 2. H2C_DATA PDU for READ command → cmd-&gt;req.sg allocated, cmd-&gt;iov NULL<br /> 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL<br /> <br /> The fix validates both cmd-&gt;req.sg and cmd-&gt;iov before calling<br /> nvmet_tcp_build_pdu_iovec(). Both checks are required because:<br /> - Uninitialized commands: both NULL<br /> - READ commands: cmd-&gt;req.sg allocated, cmd-&gt;iov NULL<br /> - WRITE commands: both allocated

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_qfq: do not free existing class in qfq_change_class()<br /> <br /> Fixes qfq_change_class() error case.<br /> <br /> cl-&gt;qdisc and cl should only be freed if a new class and qdisc<br /> were allocated, or we risk various UAF.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix crash on profile change rollback failure<br /> <br /> mlx5e_netdev_change_profile can fail to attach a new profile and can<br /> fail to rollback to old profile, in such case, we could end up with a<br /> dangling netdev with a fully reset netdev_priv. A retry to change<br /> profile, e.g. another attempt to call mlx5e_netdev_change_profile via<br /> switchdev mode change, will crash trying to access the now NULL<br /> priv-&gt;mdev.<br /> <br /> This fix allows mlx5e_netdev_change_profile() to handle previous<br /> failures and an empty priv, by not assuming priv is valid.<br /> <br /> Pass netdev and mdev to all flows requiring<br /> mlx5e_netdev_change_profile() and avoid passing priv.<br /> In mlx5e_netdev_change_profile() check if current priv is valid, and if<br /> not, just attach the new profile without trying to access the old one.<br /> <br /> This fixes the following oops, when enabling switchdev mode for the 2nd<br /> time after first time failure:<br /> <br /> ## Enabling switchdev mode first time:<br /> <br /> mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12<br /> ^^^^^^^^<br /> mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)<br /> <br /> ## retry: Enabling switchdev mode 2nd time:<br /> <br /> mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload<br /> BUG: kernel NULL pointer dereference, address: 0000000000000038<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:mlx5e_detach_netdev+0x3c/0x90<br /> Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07<br /> RSP: 0018:ffffc90000673890 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000<br /> RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000<br /> R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000<br /> R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000<br /> FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0<br /> Call Trace:<br /> <br /> mlx5e_netdev_change_profile+0x45/0xb0<br /> mlx5e_vport_rep_load+0x27b/0x2d0<br /> mlx5_esw_offloads_rep_load+0x72/0xf0<br /> esw_offloads_enable+0x5d0/0x970<br /> mlx5_eswitch_enable_locked+0x349/0x430<br /> ? is_mp_supported+0x57/0xb0<br /> mlx5_devlink_eswitch_mode_set+0x26b/0x430<br /> devlink_nl_eswitch_set_doit+0x6f/0xf0<br /> genl_family_rcv_msg_doit+0xe8/0x140<br /> genl_rcv_msg+0x18b/0x290<br /> ? __pfx_devlink_nl_pre_doit+0x10/0x10<br /> ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10<br /> ? __pfx_devlink_nl_post_doit+0x10/0x10<br /> ? __pfx_genl_rcv_msg+0x10/0x10<br /> netlink_rcv_skb+0x52/0x100<br /> genl_rcv+0x28/0x40<br /> netlink_unicast+0x282/0x3e0<br /> ? __alloc_skb+0xd6/0x190<br /> netlink_sendmsg+0x1f7/0x430<br /> __sys_sendto+0x213/0x220<br /> ? __sys_recvmsg+0x6a/0xd0<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0x50/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fdfb8495047

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macvlan: fix possible UAF in macvlan_forward_source()<br /> <br /> Add RCU protection on (struct macvlan_source_entry)-&gt;vlan.<br /> <br /> Whenever macvlan_hash_del_source() is called, we must clear<br /> entry-&gt;vlan pointer before RCU grace period starts.<br /> <br /> This allows macvlan_forward_source() to skip over<br /> entries queued for freeing.<br /> <br /> Note that macvlan_dev are already RCU protected, as they<br /> are embedded in a standard netdev (netdev_priv(ndev)).<br /> <br /> https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: tegra-adma: Fix use-after-free<br /> <br /> A use-after-free bug exists in the Tegra ADMA driver when audio streams<br /> are terminated, particularly during XRUN conditions. The issue occurs<br /> when the DMA buffer is freed by tegra_adma_terminate_all() before the<br /> vchan completion tasklet finishes accessing it.<br /> <br /> The race condition follows this sequence:<br /> <br /> 1. DMA transfer completes, triggering an interrupt that schedules the<br /> completion tasklet (tasklet has not executed yet)<br /> 2. Audio playback stops, calling tegra_adma_terminate_all() which<br /> frees the DMA buffer memory via kfree()<br /> 3. The scheduled tasklet finally executes, calling vchan_complete()<br /> which attempts to access the already-freed memory<br /> <br /> Since tasklets can execute at any time after being scheduled, there is<br /> no guarantee that the buffer will remain valid when vchan_complete()<br /> runs.<br /> <br /> Fix this by properly synchronizing the virtual channel completion:<br /> - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the<br /> descriptors as terminated instead of freeing the descriptor.<br /> - Add the callback tegra_adma_synchronize() that calls<br /> vchan_synchronize() which kills any pending tasklets and frees any<br /> terminated descriptors.<br /> <br /> Crash logs:<br /> [ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0<br /> [ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0<br /> <br /> [ 337.427562] Call trace:<br /> [ 337.427564] dump_backtrace+0x0/0x320<br /> [ 337.427571] show_stack+0x20/0x30<br /> [ 337.427575] dump_stack_lvl+0x68/0x84<br /> [ 337.427584] print_address_description.constprop.0+0x74/0x2b8<br /> [ 337.427590] kasan_report+0x1f4/0x210<br /> [ 337.427598] __asan_load8+0xa0/0xd0<br /> [ 337.427603] vchan_complete+0x124/0x3b0<br /> [ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0<br /> [ 337.427617] tasklet_action+0x30/0x40<br /> [ 337.427623] __do_softirq+0x1a0/0x5c4<br /> [ 337.427628] irq_exit+0x110/0x140<br /> [ 337.427633] handle_domain_irq+0xa4/0xe0<br /> [ 337.427640] gic_handle_irq+0x64/0x160<br /> [ 337.427644] call_on_irq_stack+0x20/0x4c<br /> [ 337.427649] do_interrupt_handler+0x7c/0x90<br /> [ 337.427654] el1_interrupt+0x30/0x80<br /> [ 337.427659] el1h_64_irq_handler+0x18/0x30<br /> [ 337.427663] el1h_64_irq+0x7c/0x80<br /> [ 337.427667] cpuidle_enter_state+0xe4/0x540<br /> [ 337.427674] cpuidle_enter+0x54/0x80<br /> [ 337.427679] do_idle+0x2e0/0x380<br /> [ 337.427685] cpu_startup_entry+0x2c/0x70<br /> [ 337.427690] rest_init+0x114/0x130<br /> [ 337.427695] arch_call_rest_init+0x18/0x24<br /> [ 337.427702] start_kernel+0x380/0x3b4<br /> [ 337.427706] __primary_switched+0xc0/0xc8

*** Pendiente de traducción *** Deep Instinct Windows Agent 1.2.24.0 contains an unquoted service path vulnerability in the DeepNetworkService that allows local users to potentially execute code with elevated privileges. Attackers can exploit the unquoted path in C:\Program Files\HP Sure Sense\DeepNetworkService.exe to inject malicious code that would execute with LocalSystem permissions during service startup.

*** Pendiente de traducción *** KMSpico 17.1.0.0 contains an unquoted service path vulnerability in the Service KMSELDI configuration that allows local attackers to potentially execute arbitrary code. Attackers can exploit the unquoted binary path in C:\Program Files\KMSpico\Service_KMS.exe to inject malicious executables and escalate privileges.

*** Pendiente de traducción *** Magic Mouse 2 Utilities 2.20 contains an unquoted service path vulnerability in its Windows service configuration. Attackers can exploit the unquoted path to inject malicious executables and gain elevated system privileges by placing a malicious file in the service path.