Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit()<br /> <br /> When dma_map_single() fails in tse_start_xmit(), the function returns<br /> NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the<br /> stack the packet was consumed, the skb is never freed, leaking memory<br /> on every DMA mapping failure.<br /> <br /> Add dev_kfree_skb_any() before returning to properly free the skb.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: reject oversized global TT response buffers<br /> <br /> batadv_tt_prepare_tvlv_global_data() builds the allocation length for a<br /> global TT response in 16-bit temporaries. When a remote originator<br /> advertises a large enough global TT, the TT payload length plus the VLAN<br /> header offset can exceed 65535 and wrap before kmalloc().<br /> <br /> The full-table response path still uses the original TT payload length when<br /> it fills tt_change, so the wrapped allocation is too small and<br /> batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object<br /> before the later packet-size check runs.<br /> <br /> Fix this by rejecting TT responses whose TVLV value length cannot fit in<br /> the 16-bit TVLV payload length field.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: pn533: allocate rx skb before consuming bytes<br /> <br /> pn532_receive_buf() reports the number of accepted bytes to the serdev<br /> core. The current code consumes bytes into recv_skb and may already hand<br /> a complete frame to pn533_recv_frame() before allocating a fresh receive<br /> buffer.<br /> <br /> If that alloc_skb() fails, the callback returns 0 even though it has<br /> already consumed bytes, and it leaves recv_skb as NULL for the next<br /> receive callback. That breaks the receive_buf() accounting contract and<br /> can also lead to a NULL dereference on the next skb_put_u8().<br /> <br /> Allocate the receive skb lazily before consuming the next byte instead.<br /> If allocation fails, return the number of bytes already accepted.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmsmac: Fix dma_free_coherent() size<br /> <br /> dma_alloc_consistent() may change the size to align it. The new size is<br /> saved in alloced.<br /> <br /> Change the free size to match the allocation size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG<br /> <br /> The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements<br /> bc_ackers on every inbound group ACK, even when the same member has<br /> already acknowledged the current broadcast round.<br /> <br /> Because bc_ackers is a u16, a duplicate ACK received after the last<br /> legitimate ACK wraps the counter to 65535. Once wrapped,<br /> tipc_group_bc_cong() keeps reporting congestion and later group<br /> broadcasts on the affected socket stay blocked until the group is<br /> recreated.<br /> <br /> Fix this by ignoring duplicate or stale ACKs before touching bc_acked or<br /> bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and<br /> prevents the underflow path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: filemap: fix nr_pages calculation overflow in filemap_map_pages()<br /> <br /> When running stress-ng on my Arm64 machine with v7.0-rc3 kernel, I<br /> encountered some very strange crash issues showing up as "Bad page state":<br /> <br /> "<br /> [ 734.496287] BUG: Bad page state in process stress-ng-env pfn:415735fb<br /> [ 734.496427] page: refcount:0 mapcount:1 mapping:0000000000000000 index:0x4cf316 pfn:0x415735fb<br /> [ 734.496434] flags: 0x57fffe000000800(owner_2|node=1|zone=2|lastcpupid=0x3ffff)<br /> [ 734.496439] raw: 057fffe000000800 0000000000000000 dead000000000122 0000000000000000<br /> [ 734.496440] raw: 00000000004cf316 0000000000000000 0000000000000000 0000000000000000<br /> [ 734.496442] page dumped because: nonzero mapcount<br /> "<br /> <br /> After analyzing this page’s state, it is hard to understand why the<br /> mapcount is not 0 while the refcount is 0, since this page is not where<br /> the issue first occurred. By enabling the CONFIG_DEBUG_VM config, I can<br /> reproduce the crash as well and captured the first warning where the issue<br /> appears:<br /> <br /> "<br /> [ 734.469226] page: refcount:33 mapcount:0 mapping:00000000bef2d187 index:0x81a0 pfn:0x415735c0<br /> [ 734.469304] head: order:5 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> [ 734.469315] memcg:ffff000807a8ec00<br /> [ 734.469320] aops:ext4_da_aops ino:100b6f dentry name(?):"stress-ng-mmaptorture-9397-0-2736200540"<br /> [ 734.469335] flags: 0x57fffe400000069(locked|uptodate|lru|head|node=1|zone=2|lastcpupid=0x3ffff)<br /> ......<br /> [ 734.469364] page dumped because: VM_WARN_ON_FOLIO((_Generic((page + nr_pages - 1),<br /> const struct page *: (const struct folio *)_compound_head(page + nr_pages - 1), struct page *:<br /> (struct folio *)_compound_head(page + nr_pages - 1))) != folio)<br /> [ 734.469390] ------------[ cut here ]------------<br /> [ 734.469393] WARNING: ./include/linux/rmap.h:351 at folio_add_file_rmap_ptes+0x3b8/0x468,<br /> CPU#90: stress-ng-mlock/9430<br /> [ 734.469551] folio_add_file_rmap_ptes+0x3b8/0x468 (P)<br /> [ 734.469555] set_pte_range+0xd8/0x2f8<br /> [ 734.469566] filemap_map_folio_range+0x190/0x400<br /> [ 734.469579] filemap_map_pages+0x348/0x638<br /> [ 734.469583] do_fault_around+0x140/0x198<br /> ......<br /> [ 734.469640] el0t_64_sync+0x184/0x188<br /> "<br /> <br /> The code that triggers the warning is: "VM_WARN_ON_FOLIO(page_folio(page +<br /> nr_pages - 1) != folio, folio)", which indicates that set_pte_range()<br /> tried to map beyond the large folio’s size.<br /> <br /> By adding more debug information, I found that &amp;#39;nr_pages&amp;#39; had overflowed<br /> in filemap_map_pages(), causing set_pte_range() to establish mappings for<br /> a range exceeding the folio size, potentially corrupting fields of pages<br /> that do not belong to this folio (e.g., page-&gt;_mapcount).<br /> <br /> After above analysis, I think the possible race is as follows:<br /> <br /> CPU 0 CPU 1<br /> filemap_map_pages() ext4_setattr()<br /> //get and lock folio with old inode-&gt;i_size<br /> next_uptodate_folio()<br /> <br /> .......<br /> //shrink the inode-&gt;i_size<br /> i_size_write(inode, attr-&gt;ia_size);<br /> <br /> //calculate the end_pgoff with the new inode-&gt;i_size<br /> file_end = DIV_ROUND_UP(i_size_read(mapping-&gt;host), PAGE_SIZE) - 1;<br /> end_pgoff = min(end_pgoff, file_end);<br /> <br /> ......<br /> //nr_pages can be overflowed, cause xas.xa_index &gt; end_pgoff<br /> end = folio_next_index(folio) - 1;<br /> nr_pages = min(end, end_pgoff) - xas.xa_index + 1;<br /> <br /> ......<br /> //map large folio<br /> filemap_map_folio_range()<br /> ......<br /> //truncate folios<br /> truncate_pagecache(inode, inode-&gt;i_size);<br /> <br /> To fix this issue, move the &amp;#39;end_pgoff&amp;#39; calculation before<br /> next_uptodate_folio(), so the retrieved folio stays consistent with the<br /> file end to avoid <br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: fix integer underflow in chain mode<br /> <br /> The jumbo_frm() chain-mode implementation unconditionally computes<br /> <br /> len = nopaged_len - bmax;<br /> <br /> where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is<br /> BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit()<br /> decides to invoke jumbo_frm() based on skb-&gt;len (total length including<br /> page fragments):<br /> <br /> is_jumbo = stmmac_is_jumbo_frm(priv, skb-&gt;len, enh_desc);<br /> <br /> When a packet has a small linear portion (nopaged_len len &gt; bmax), the<br /> subtraction wraps as an unsigned integer, producing a huge len value<br /> (~0xFFFFxxxx). This causes the while (len != 0) loop to execute<br /> hundreds of thousands of iterations, passing skb-&gt;data + bmax * i<br /> pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less<br /> SoCs (the typical deployment for stmmac), this maps arbitrary kernel<br /> memory to the DMA engine, constituting a kernel memory disclosure and<br /> potential memory corruption from hardware.<br /> <br /> Fix this by introducing a buf_len local variable clamped to<br /> min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then<br /> always safe: it is zero when the linear portion fits within a single<br /> descriptor, causing the while (len != 0) loop to be skipped naturally,<br /> and the fragment loop in stmmac_xmit() handles page fragments afterward.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: vub300: fix use-after-free on disconnect<br /> <br /> The vub300 driver maintains an explicit reference count for the<br /> controller and its driver data and the last reference can in theory be<br /> dropped after the driver has been unbound.<br /> <br /> This specifically means that the controller allocation must not be<br /> device managed as that can lead to use-after-free.<br /> <br /> Note that the lifetime is currently also incorrectly tied the parent USB<br /> device rather than interface, which can lead to memory leaks if the<br /> driver is unbound without its device being physically disconnected (e.g.<br /> on probe deferral).<br /> <br /> Fix both issues by reverting to non-managed allocation of the controller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: vub300: fix NULL-deref on disconnect<br /> <br /> Make sure to deregister the controller before dropping the reference to<br /> the driver data on disconnect to avoid NULL-pointer dereferences or<br /> use-after-free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/stat: deallocate damon_call() failure leaking damon_ctx<br /> <br /> damon_stat_start() always allocates the module&amp;#39;s damon_ctx object<br /> (damon_stat_context). Meanwhile, if damon_call() in the function fails,<br /> the damon_ctx object is not deallocated. Hence, if the damon_call() is<br /> failed, and the user writes Y to “enabled” again, the previously<br /> allocated damon_ctx object is leaked.<br /> <br /> This cannot simply be fixed by deallocating the damon_ctx object when<br /> damon_call() fails. That&amp;#39;s because damon_call() failure doesn&amp;#39;t guarantee<br /> the kdamond main function, which accesses the damon_ctx object, is<br /> completely finished. In other words, if damon_stat_start() deallocates<br /> the damon_ctx object after damon_call() failure, the not-yet-terminated<br /> kdamond could access the freed memory (use-after-free).<br /> <br /> Fix the leak while avoiding the use-after-free by keeping returning<br /> damon_stat_start() without deallocating the damon_ctx object after<br /> damon_call() failure, but deallocating it when the function is invoked<br /> again and the kdamond is completely terminated. If the kdamond is not yet<br /> terminated, simply return -EAGAIN, as the kdamond will soon be terminated.<br /> <br /> The issue was discovered [1] by sashiko.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: dealloc repeat_call_control if damon_call() fails<br /> <br /> damon_call() for repeat_call_control of DAMON_SYSFS could fail if somehow<br /> the kdamond is stopped before the damon_call(). It could happen, for<br /> example, when te damon context was made for monitroing of a virtual<br /> address processes, and the process is terminated immediately, before the<br /> damon_call() invocation. In the case, the dyanmically allocated<br /> repeat_call_control is not deallocated and leaked.<br /> <br /> Fix the leak by deallocating the repeat_call_control under the<br /> damon_call() failure.<br /> <br /> This issue is discovered by sashiko [1].

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vma: fix memory leak in __mmap_region()<br /> <br /> commit 605f6586ecf7 ("mm/vma: do not leak memory when .mmap_prepare<br /> swaps the file") handled the success path by skipping get_file() via<br /> file_doesnt_need_get, but missed the error path.<br /> <br /> When /dev/zero is mmap&amp;#39;d with MAP_SHARED, mmap_zero_prepare() calls<br /> shmem_zero_setup_desc() which allocates a new shmem file to back the<br /> mapping. If __mmap_new_vma() subsequently fails, this replacement<br /> file is never fput()&amp;#39;d - the original is released by<br /> ksys_mmap_pgoff(), but nobody releases the new one.<br /> <br /> Add fput() for the swapped file in the error path.<br /> <br /> Reproducible with fault injection.<br /> <br /> FAULT_INJECTION: forcing a failure.<br /> name failslab, interval 1, probability 0, space 0, times 1<br /> CPU: 2 UID: 0 PID: 366 Comm: syz.7.14 Not tainted 7.0.0-rc6 #2 PREEMPT(full)<br /> Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x164/0x1f0<br /> should_fail_ex+0x525/0x650<br /> should_failslab+0xdf/0x140<br /> kmem_cache_alloc_noprof+0x78/0x630<br /> vm_area_alloc+0x24/0x160<br /> __mmap_region+0xf6b/0x2660<br /> mmap_region+0x2eb/0x3a0<br /> do_mmap+0xc79/0x1240<br /> vm_mmap_pgoff+0x252/0x4c0<br /> ksys_mmap_pgoff+0xf8/0x120<br /> __x64_sys_mmap+0x12a/0x190<br /> do_syscall_64+0xa9/0x580<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> <br /> kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> BUG: memory leak<br /> unreferenced object 0xffff8881118aca80 (size 360):<br /> comm "syz.7.14", pid 366, jiffies 4294913255<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........<br /> ff ff ff ff ff ff ff ff c0 28 4d ae ff ff ff ff .........(M.....<br /> backtrace (crc db0f53bc):<br /> kmem_cache_alloc_noprof+0x3ab/0x630<br /> alloc_empty_file+0x5a/0x1e0<br /> alloc_file_pseudo+0x135/0x220<br /> __shmem_file_setup+0x274/0x420<br /> shmem_zero_setup_desc+0x9c/0x170<br /> mmap_zero_prepare+0x123/0x140<br /> __mmap_region+0xdda/0x2660<br /> mmap_region+0x2eb/0x3a0<br /> do_mmap+0xc79/0x1240<br /> vm_mmap_pgoff+0x252/0x4c0<br /> ksys_mmap_pgoff+0xf8/0x120<br /> __x64_sys_mmap+0x12a/0x190<br /> do_syscall_64+0xa9/0x580<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Found by syzkaller.