Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: Fix use-after-free in tipc_mon_reinit_self().<br /> <br /> syzbot reported use-after-free of tipc_net(net)-&gt;monitors[]<br /> in tipc_mon_reinit_self(). [0]<br /> <br /> The array is protected by RTNL, but tipc_mon_reinit_self()<br /> iterates over it without RTNL.<br /> <br /> tipc_mon_reinit_self() is called from tipc_net_finalize(),<br /> which is always under RTNL except for tipc_net_finalize_work().<br /> <br /> Let&amp;#39;s hold RTNL in tipc_net_finalize_work().<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162<br /> Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989<br /> <br /> CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)}<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025<br /> Workqueue: events tipc_net_finalize_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xca/0x240 mm/kasan/report.c:482<br /> kasan_report+0x118/0x150 mm/kasan/report.c:595<br /> __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568<br /> kasan_check_byte include/linux/kasan.h:399 [inline]<br /> lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162<br /> rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline]<br /> rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline]<br /> rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244<br /> rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243<br /> write_lock_bh include/linux/rwlock_rt.h:99 [inline]<br /> tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718<br /> tipc_net_finalize+0x115/0x190 net/tipc/net.c:140<br /> process_one_work kernel/workqueue.c:3236 [inline]<br /> process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400<br /> kthread+0x70e/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> Allocated by task 6089:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:388 [inline]<br /> __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407<br /> kmalloc_noprof include/linux/slab.h:905 [inline]<br /> kzalloc_noprof include/linux/slab.h:1039 [inline]<br /> tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657<br /> tipc_enable_bearer net/tipc/bearer.c:357 [inline]<br /> __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047<br /> __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline]<br /> tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393<br /> tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline]<br /> tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321<br /> genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115<br /> genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]<br /> genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210<br /> netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552<br /> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]<br /> netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346<br /> netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> __sock_sendmsg+0x21c/0x270 net/socket.c:729<br /> ____sys_sendmsg+0x508/0x820 net/socket.c:2614<br /> ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668<br /> __sys_sendmsg net/socket.c:2700 [inline]<br /> __do_sys_sendmsg net/socket.c:2705 [inline]<br /> __se_sys_sendmsg net/socket.c:2703 [inline]<br /> __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rw: ensure allocated iovec gets cleared for early failure<br /> <br /> A previous commit reused the recyling infrastructure for early cleanup,<br /> but this is not enough for the case where our internal caches have<br /> overflowed. If this happens, then the allocated iovec can get leaked if<br /> the request is also aborted early.<br /> <br /> Reinstate the previous forced free of the iovec for that situation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: client: fix memory leak in smb3_fs_context_parse_param<br /> <br /> The user calls fsconfig twice, but when the program exits, free() only<br /> frees ctx-&gt;source for the second fsconfig, not the first.<br /> Regarding fc-&gt;source, there is no code in the fs context related to its<br /> memory reclamation.<br /> <br /> To fix this memory leak, release the source memory corresponding to ctx<br /> or fc before each parsing.<br /> <br /> syzbot reported:<br /> BUG: memory leak<br /> unreferenced object 0xffff888128afa360 (size 96):<br /> backtrace (crc 79c9c7ba):<br /> kstrdup+0x3c/0x80 mm/util.c:84<br /> smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888112c7d900 (size 96):<br /> backtrace (crc 79c9c7ba):<br /> smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629<br /> smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix potential overflow of PCM transfer buffer<br /> <br /> The PCM stream data in USB-audio driver is transferred over USB URB<br /> packet buffers, and each packet size is determined dynamically. The<br /> packet sizes are limited by some factors such as wMaxPacketSize USB<br /> descriptor. OTOH, in the current code, the actually used packet sizes<br /> are determined only by the rate and the PPS, which may be bigger than<br /> the size limit above. This results in a buffer overflow, as reported<br /> by syzbot.<br /> <br /> Basically when the limit is smaller than the calculated packet size,<br /> it implies that something is wrong, most likely a weird USB<br /> descriptor. So the best option would be just to return an error at<br /> the parameter setup time before doing any further operations.<br /> <br /> This patch introduces such a sanity check, and returns -EINVAL when<br /> the packet size is greater than maxpacksize. The comparison with<br /> ep-&gt;packsize[1] alone should suffice since it&amp;#39;s always equal or<br /> greater than ep-&gt;packsize[0].

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm, swap: fix potential UAF issue for VMA readahead<br /> <br /> Since commit 78524b05f1a3 ("mm, swap: avoid redundant swap device<br /> pinning"), the common helper for allocating and preparing a folio in the<br /> swap cache layer no longer tries to get a swap device reference<br /> internally, because all callers of __read_swap_cache_async are already<br /> holding a swap entry reference. The repeated swap device pinning isn&amp;#39;t<br /> needed on the same swap device.<br /> <br /> Caller of VMA readahead is also holding a reference to the target entry&amp;#39;s<br /> swap device, but VMA readahead walks the page table, so it might encounter<br /> swap entries from other devices, and call __read_swap_cache_async on<br /> another device without holding a reference to it.<br /> <br /> So it is possible to cause a UAF when swapoff of device A raced with<br /> swapin on device B, and VMA readahead tries to read swap entries from<br /> device A. It&amp;#39;s not easy to trigger, but in theory, it could cause real<br /> issues.<br /> <br /> Make VMA readahead try to get the device reference first if the swap<br /> device is a different one from the target entry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/proc: fix uaf in proc_readdir_de()<br /> <br /> Pde is erased from subdir rbtree through rb_erase(), but not set the node<br /> to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()<br /> set the erased node to EMPTY, then pde_subdir_next() will return NULL to<br /> avoid uaf access.<br /> <br /> We found an uaf issue while using stress-ng testing, need to run testcase<br /> getdent and tun in the same time. The steps of the issue is as follows:<br /> <br /> 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current<br /> pde is tun3;<br /> <br /> 2) in the [time windows] unregister netdevice tun3 and tun2, and erase<br /> them from rbtree. erase tun3 first, and then erase tun2. the<br /> pde(tun2) will be released to slab;<br /> <br /> 3) continue to getdent process, then pde_subdir_next() will return<br /> pde(tun2) which is released, it will case uaf access.<br /> <br /> CPU 0 | CPU 1<br /> -------------------------------------------------------------------------<br /> traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-&gt;dev) //tun3 tun2<br /> sys_getdents64() |<br /> iterate_dir() |<br /> proc_readdir() |<br /> proc_readdir_de() | snmp6_unregister_dev()<br /> pde_get(de); | proc_remove()<br /> read_unlock(&amp;proc_subdir_lock); | remove_proc_subtree()<br /> | write_lock(&amp;proc_subdir_lock);<br /> [time window] | rb_erase(&amp;root-&gt;subdir_node, &amp;parent-&gt;subdir);<br /> | write_unlock(&amp;proc_subdir_lock);<br /> read_lock(&amp;proc_subdir_lock); |<br /> next = pde_subdir_next(de); |<br /> pde_put(de); |<br /> de = next; //UAF |<br /> <br /> rbtree of dev_snmp6<br /> |<br /> pde(tun3)<br /> / \<br /> NULL pde(tun2)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/secretmem: fix use-after-free race in fault handler<br /> <br /> When a page fault occurs in a secret memory file created with<br /> `memfd_secret(2)`, the kernel will allocate a new folio for it, mark the<br /> underlying page as not-present in the direct map, and add it to the file<br /> mapping.<br /> <br /> If two tasks cause a fault in the same page concurrently, both could end<br /> up allocating a folio and removing the page from the direct map, but only<br /> one would succeed in adding the folio to the file mapping. The task that<br /> failed undoes the effects of its attempt by (a) freeing the folio again<br /> and (b) putting the page back into the direct map. However, by doing<br /> these two operations in this order, the page becomes available to the<br /> allocator again before it is placed back in the direct mapping.<br /> <br /> If another task attempts to allocate the page between (a) and (b), and the<br /> kernel tries to access it via the direct map, it would result in a<br /> supervisor not-present page fault.<br /> <br /> Fix the ordering to restore the direct map before the folio is freed.

*** Pendiente de traducción *** A flaw has been found in UTT 进取 520W 1.7.7-180627. The impacted element is the function strcpy of the file /goform/formArpBindConfig. Executing manipulation of the argument pools can lead to buffer overflow. The attack may be performed from remote. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

*** Pendiente de traducción *** A vulnerability was detected in UTT 进取 520W 1.7.7-180627. The affected element is the function strcpy of the file /goform/websHostFilter. Performing manipulation of the argument addHostFilter results in buffer overflow. The attack is possible to be carried out remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

*** Pendiente de traducción *** A security vulnerability has been detected in UTT 进取 520W 1.7.7-180627. Impacted is the function strcpy of the file /goform/formConfigDnsFilterGlobal. Such manipulation of the argument timeRangeName leads to buffer overflow. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

*** Pendiente de traducción *** A security flaw has been discovered in Linksys RE6500, RE6250, RE6300, RE6350, RE7000 and RE9000 1.0.013.001/1.0.04.001/1.0.04.002/1.1.05.003/1.2.07.001. This vulnerability affects the function RE2000v2Repeater_get_wired_clientlist_setClientsName of the file mod_form.so. The manipulation of the argument clientsname_0 results in stack-based buffer overflow. The attack may be launched remotely. The exploit has been released to the public and may be exploited. The vendor was contacted early about this disclosure but did not respond in any way.

*** Pendiente de traducción *** A vulnerability was identified in Linksys RE6500, RE6250, RE6300, RE6350, RE7000 and RE9000 1.0.013.001/1.0.04.001/1.0.04.002/1.1.05.003/1.2.07.001. This affects the function AP_get_wired_clientlist_setClientsName of the file mod_form.so. The manipulation of the argument clientsname_0 leads to stack-based buffer overflow. The attack may be initiated remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.