Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix uprobe pte be overwritten when expanding vma<br /> <br /> Patch series "Fix uprobe pte be overwritten when expanding vma".<br /> <br /> <br /> This patch (of 4):<br /> <br /> We encountered a BUG alert triggered by Syzkaller as follows:<br /> BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1<br /> <br /> And we can reproduce it with the following steps:<br /> 1. register uprobe on file at zero offset<br /> 2. mmap the file at zero offset:<br /> addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0);<br /> 3. mremap part of vma1 to new vma2:<br /> addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE);<br /> 4. mremap back to orig addr1:<br /> mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1);<br /> <br /> In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2<br /> with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1<br /> to vma2, then unmap the vma1 range [addr1, addr1 + 4096].<br /> <br /> In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the<br /> addr range [addr1, addr1 + 4096]. Since the addr range [addr1 + 4096,<br /> addr1 + 8192] still maps the file, it will take vma_merge_new_range to<br /> expand the range, and then do uprobe_mmap in vma_complete. Since the<br /> merged vma pgoff is also zero offset, it will install uprobe anon page to<br /> the merged vma. However, the upcomming move_page_tables step, which use<br /> set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite<br /> the newly uprobe pte in the merged vma, and lead that pte to be orphan.<br /> <br /> Since the uprobe pte will be remapped to the merged vma, we can remove the<br /> unnecessary uprobe_mmap upon merged vma.<br /> <br /> This problem was first found in linux-6.6.y and also exists in the<br /> community syzkaller:<br /> https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: add NULL check in automount_fullpath<br /> <br /> page is checked for null in __build_path_from_dentry_optional_prefix<br /> when tcon-&gt;origin_fullpath is not set. However, the check is missing when<br /> it is set.<br /> Add a check to prevent a potential NULL pointer dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbcon: Make sure modelist not set on unregistered console<br /> <br /> It looks like attempting to write to the "store_modes" sysfs node will<br /> run afoul of unregistered consoles:<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28<br /> index -1 is out of range for type &amp;#39;fb_info *[32]&amp;#39;<br /> ...<br /> fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122<br /> fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048<br /> fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673<br /> store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113<br /> dev_attr_store+0x55/0x80 drivers/base/core.c:2439<br /> <br /> static struct fb_info *fbcon_registered_fb[FB_MAX];<br /> ...<br /> static signed char con2fb_map[MAX_NR_CONSOLES];<br /> ...<br /> static struct fb_info *fbcon_info_from_console(int console)<br /> ...<br /> return fbcon_registered_fb[con2fb_map[console]];<br /> <br /> If con2fb_map contains a -1 things go wrong here. Instead, return NULL,<br /> as callers of fbcon_info_from_console() are trying to compare against<br /> existing "info" pointers, so error handling should kick in correctly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Fix memory leak due to multiple rx_stats allocation<br /> <br /> rx_stats for each arsta is allocated when adding a station.<br /> arsta-&gt;rx_stats will be freed when a station is removed.<br /> <br /> Redundant allocations are occurring when the same station is added<br /> multiple times. This causes ath12k_mac_station_add() to be called<br /> multiple times, and rx_stats is allocated each time. As a result there<br /> is memory leaks.<br /> <br /> Prevent multiple allocations of rx_stats when ath12k_mac_station_add()<br /> is called repeatedly by checking if rx_stats is already allocated<br /> before allocating again. Allocate arsta-&gt;rx_stats if arsta-&gt;rx_stats<br /> is NULL respectively.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1<br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: fix MMIO write access to an invalid page in i40e_clear_hw<br /> <br /> When the device sends a specific input, an integer underflow can occur, leading<br /> to MMIO write access to an invalid page.<br /> <br /> Prevent the integer underflow by changing the type of related variables.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: Revert atm_account_tx() if copy_from_iter_full() fails.<br /> <br /> In vcc_sendmsg(), we account skb-&gt;truesize to sk-&gt;sk_wmem_alloc by<br /> atm_account_tx().<br /> <br /> It is expected to be reverted by atm_pop_raw() later called by<br /> vcc-&gt;dev-&gt;ops-&gt;send(vcc, skb).<br /> <br /> However, vcc_sendmsg() misses the same revert when copy_from_iter_full()<br /> fails, and then we will leak a socket.<br /> <br /> Let&amp;#39;s factorise the revert part as atm_return_tx() and call it in<br /> the failure path.<br /> <br /> Note that the corresponding sk_wmem_alloc operation can be found in<br /> alloc_tx() as of the blamed commit.<br /> <br /> $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix null pointer dereference in destroy_previous_session<br /> <br /> If client set -&gt;PreviousSessionId on kerberos session setup stage,<br /> NULL pointer dereference error will happen. Since sess-&gt;user is not<br /> set yet, It can pass the user argument as NULL to destroy_previous_session.<br /> sess-&gt;user will be set in ksmbd_krb5_authenticate(). So this patch move<br /> calling destroy_previous_session() after ksmbd_krb5_authenticate().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: clear the dst when changing skb protocol<br /> <br /> A not-so-careful NAT46 BPF program can crash the kernel<br /> if it indiscriminately flips ingress packets from v4 to v6:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ip6_rcv_core (net/ipv6/ip6_input.c:190:20)<br /> ipv6_rcv (net/ipv6/ip6_input.c:306:8)<br /> process_backlog (net/core/dev.c:6186:4)<br /> napi_poll (net/core/dev.c:6906:9)<br /> net_rx_action (net/core/dev.c:7028:13)<br /> do_softirq (kernel/softirq.c:462:3)<br /> netif_rx (net/core/dev.c:5326:3)<br /> dev_loopback_xmit (net/core/dev.c:4015:2)<br /> ip_mc_finish_output (net/ipv4/ip_output.c:363:8)<br /> NF_HOOK (./include/linux/netfilter.h:314:9)<br /> ip_mc_output (net/ipv4/ip_output.c:400:5)<br /> dst_output (./include/net/dst.h:459:9)<br /> ip_local_out (net/ipv4/ip_output.c:130:9)<br /> ip_send_skb (net/ipv4/ip_output.c:1496:8)<br /> udp_send_skb (net/ipv4/udp.c:1040:8)<br /> udp_sendmsg (net/ipv4/udp.c:1328:10)<br /> <br /> The output interface has a 4-&gt;6 program attached at ingress.<br /> We try to loop the multicast skb back to the sending socket.<br /> Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr<br /> and changes skb-&gt;protocol to v6. We enter ip6_rcv_core which<br /> tries to use skb_dst(). But the dst is still an IPv4 one left<br /> after IPv4 mcast output.<br /> <br /> Clear the dst in all BPF helpers which change the protocol.<br /> Try to preserve metadata dsts, those may carry non-routing<br /> metadata.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: sch_sfq: reject invalid perturb period<br /> <br /> Gerrard Tai reported that SFQ perturb_period has no range check yet,<br /> and this can be used to trigger a race condition fixed in a separate patch.<br /> <br /> We want to make sure ctl-&gt;perturb_period * HZ will not overflow<br /> and is positive.<br /> <br /> <br /> tc qd add dev lo root sfq perturb -10 # negative value : error<br /> Error: sch_sfq: invalid perturb period.<br /> <br /> tc qd add dev lo root sfq perturb 1000000000 # too big : error<br /> Error: sch_sfq: invalid perturb period.<br /> <br /> tc qd add dev lo root sfq perturb 2000000 # acceptable value<br /> tc -s -d qd sh dev lo<br /> qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec<br /> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)<br /> backlog 0b 0p requeues 0

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jffs2: check that raw node were preallocated before writing summary<br /> <br /> Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault<br /> injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn&amp;#39;t<br /> check return value of jffs2_prealloc_raw_node_refs and simply lets any<br /> error propagate into jffs2_sum_write_data, which eventually calls<br /> jffs2_link_node_ref in order to link the summary to an expectedly allocated<br /> node.<br /> <br /> kernel BUG at fs/jffs2/nodelist.c:592!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592<br /> Call Trace:<br /> <br /> jffs2_sum_write_data fs/jffs2/summary.c:841 [inline]<br /> jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874<br /> jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388<br /> jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197<br /> jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362<br /> jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301<br /> generic_perform_write+0x314/0x5d0 mm/filemap.c:3856<br /> __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973<br /> generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005<br /> call_write_iter include/linux/fs.h:2265 [inline]<br /> do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735<br /> do_iter_write+0x186/0x710 fs/read_write.c:861<br /> vfs_iter_write+0x70/0xa0 fs/read_write.c:902<br /> iter_file_splice_write+0x73b/0xc90 fs/splice.c:685<br /> do_splice_from fs/splice.c:763 [inline]<br /> direct_splice_actor+0x10c/0x170 fs/splice.c:950<br /> splice_direct_to_actor+0x337/0xa10 fs/splice.c:896<br /> do_splice_direct+0x1a9/0x280 fs/splice.c:1002<br /> do_sendfile+0xb13/0x12c0 fs/read_write.c:1255<br /> __do_sys_sendfile64 fs/read_write.c:1323 [inline]<br /> __se_sys_sendfile64 fs/read_write.c:1309 [inline]<br /> __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Fix this issue by checking return value of jffs2_prealloc_raw_node_refs<br /> before calling jffs2_sum_write_data.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()<br /> <br /> ERROR INFO:<br /> <br /> CPU 25 Unable to handle kernel paging request at virtual address 0x0<br /> ...<br /> Call Trace:<br /> [] huge_pte_offset+0x3c/0x58<br /> [] hugetlb_follow_page_mask+0x74/0x438<br /> [] __get_user_pages+0xe0/0x4c8<br /> [] faultin_page_range+0x84/0x380<br /> [] madvise_vma_behavior+0x534/0xa48<br /> [] do_madvise+0x1bc/0x3e8<br /> [] sys_madvise+0x24/0x38<br /> [] do_syscall+0x78/0x98<br /> [] handle_syscall+0xb8/0x158<br /> <br /> In some cases, pmd may be NULL and rely on NULL as the return value for<br /> processing, so it is necessary to determine this situation here.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rsrc: validate buffer count with offset for cloning<br /> <br /> syzbot reports that it can trigger a WARN_ON() for kmalloc() attempt<br /> that&amp;#39;s too big:<br /> <br /> WARNING: CPU: 0 PID: 6488 at mm/slub.c:5024 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 6488 Comm: syz-executor312 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024<br /> lr : __do_kmalloc_node mm/slub.c:-1 [inline]<br /> lr : __kvmalloc_node_noprof+0x3b4/0x640 mm/slub.c:5012<br /> sp : ffff80009cfd7a90<br /> x29: ffff80009cfd7ac0 x28: ffff0000dd52a120 x27: 0000000000412dc0<br /> x26: 0000000000000178 x25: ffff7000139faf70 x24: 0000000000000000<br /> x23: ffff800082f4cea8 x22: 00000000ffffffff x21: 000000010cd004a8<br /> x20: ffff0000d75816c0 x19: ffff0000dd52a000 x18: 00000000ffffffff<br /> x17: ffff800092f39000 x16: ffff80008adbe9e4 x15: 0000000000000005<br /> x14: 1ffff000139faf1c x13: 0000000000000000 x12: 0000000000000000<br /> x11: ffff7000139faf21 x10: 0000000000000003 x9 : ffff80008f27b938<br /> x8 : 0000000000000002 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 00000000ffffffff x4 : 0000000000400dc0 x3 : 0000000200000000<br /> x2 : 000000010cd004a8 x1 : ffff80008b3ebc40 x0 : 0000000000000001<br /> Call trace:<br /> __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 (P)<br /> kvmalloc_array_node_noprof include/linux/slab.h:1065 [inline]<br /> io_rsrc_data_alloc io_uring/rsrc.c:206 [inline]<br /> io_clone_buffers io_uring/rsrc.c:1178 [inline]<br /> io_register_clone_buffers+0x484/0xa14 io_uring/rsrc.c:1287<br /> __io_uring_register io_uring/register.c:815 [inline]<br /> __do_sys_io_uring_register io_uring/register.c:926 [inline]<br /> __se_sys_io_uring_register io_uring/register.c:903 [inline]<br /> __arm64_sys_io_uring_register+0x42c/0xea8 io_uring/register.c:903<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767<br /> el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600<br /> <br /> which is due to offset + buffer_count being too large. The registration<br /> code checks only the total count of buffers, but given that the indexing<br /> is an array, it should also check offset + count. That can&amp;#39;t exceed<br /> IORING_MAX_REG_BUFFERS either, as there&amp;#39;s no way to reach buffers beyond<br /> that limit.<br /> <br /> There&amp;#39;s no issue with registrering a table this large, outside of the<br /> fact that it&amp;#39;s pointless to register buffers that cannot be reached, and<br /> that it can trigger this kmalloc() warning for attempting an allocation<br /> that is too large.