Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: chipidea: udc: fix DMA and SG cleanup in _ep_nuke()<br /> <br /> The ChipIdea UDC driver can encounter "not page aligned sg buffer"<br /> errors when a USB device is reconnected after being disconnected<br /> during an active transfer. This occurs because _ep_nuke() returns<br /> requests to the gadget layer without properly unmapping DMA buffers<br /> or cleaning up scatter-gather bounce buffers.<br /> <br /> Root cause:<br /> When a disconnect happens during a multi-segment DMA transfer, the<br /> request&amp;#39;s num_mapped_sgs field and sgt.sgl pointer remain set with<br /> stale values. The request is returned to the gadget driver with status<br /> -ESHUTDOWN but still has active DMA state. If the gadget driver reuses<br /> this request on reconnect without reinitializing it, the stale DMA<br /> state causes _hardware_enqueue() to skip DMA mapping (seeing non-zero<br /> num_mapped_sgs) and attempt to use freed/invalid DMA addresses,<br /> leading to alignment errors and potential memory corruption.<br /> <br /> The normal completion path via _hardware_dequeue() properly calls<br /> usb_gadget_unmap_request_by_dev() and sglist_do_debounce() before<br /> returning the request. The _ep_nuke() path must do the same cleanup<br /> to ensure requests are returned in a clean, reusable state.<br /> <br /> Fix:<br /> Add DMA unmapping and bounce buffer cleanup to _ep_nuke() to mirror<br /> the cleanup sequence in _hardware_dequeue():<br /> - Call usb_gadget_unmap_request_by_dev() if num_mapped_sgs is set<br /> - Call sglist_do_debounce() with copy=false if bounce buffer exists<br /> <br /> This ensures that when requests are returned due to endpoint shutdown,<br /> they don&amp;#39;t retain stale DMA mappings. The &amp;#39;false&amp;#39; parameter to<br /> sglist_do_debounce() prevents copying data back (appropriate for<br /> shutdown path where transfer was aborted).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: prodikeys: Check presence of pm-&gt;input_ep82<br /> <br /> Fake USB devices can send their own report descriptors for which the<br /> input_mapping() hook does not get called. In this case, pm-&gt;input_ep82 stays<br /> NULL, which leads to a crash later.<br /> <br /> This does not happen with the real device, but can be provoked by imposing as<br /> one.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: in-kernel: always set ID as avail when rm endp<br /> <br /> Syzkaller managed to find a combination of actions that was generating<br /> this warning:<br /> <br /> WARNING: net/mptcp/pm_kernel.c:1074 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline], CPU#1: syz.7.48/2535<br /> WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline], CPU#1: syz.7.48/2535<br /> WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline], CPU#1: syz.7.48/2535<br /> WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538, CPU#1: syz.7.48/2535<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 2535 Comm: syz.7.48 Not tainted 6.18.0-03987-gea5f5e676cf5 #17 PREEMPT(voluntary)<br /> Hardware name: QEMU Ubuntu 25.10 PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014<br /> RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline]<br /> RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline]<br /> RIP: 0010:mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline]<br /> RIP: 0010:mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538<br /> Code: 89 c7 e8 c5 8c 73 fe e9 f7 fd ff ff 49 83 ef 80 e8 b7 8c 73 fe 4c 89 ff be 03 00 00 00 e8 4a 29 e3 fe eb ac e8 a3 8c 73 fe 90 0b 90 e9 3d ff ff ff e8 95 8c 73 fe b8 a1 ff ff ff eb 1a e8 89<br /> RSP: 0018:ffffc9001535b820 EFLAGS: 00010287<br /> netdevsim0: tun_chr_ioctl cmd 1074025677<br /> RAX: ffffffff82da294d RBX: 0000000000000001 RCX: 0000000000080000<br /> RDX: ffffc900096d0000 RSI: 00000000000006d6 RDI: 00000000000006d7<br /> netdevsim0: linktype set to 823<br /> RBP: ffff88802cdb2240 R08: 00000000000104ae R09: ffffffffffffffff<br /> R10: ffffffff82da27d4 R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffff88801246d8c0 R14: ffffc9001535b8b8 R15: ffff88802cdb1800<br /> FS: 00007fc6ac5a76c0(0000) GS:ffff8880f90c8000(0000) knlGS:0000000000000000<br /> netlink: &amp;#39;syz.3.50&amp;#39;: attribute type 5 has an invalid length.<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> netlink: 1232 bytes leftover after parsing attributes in process `syz.3.50&amp;#39;.<br /> CR2: 0000200000010000 CR3: 0000000025b1a000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> mptcp_pm_set_flags net/mptcp/pm_netlink.c:277 [inline]<br /> mptcp_pm_nl_set_flags_doit+0x1d7/0x210 net/mptcp/pm_netlink.c:282<br /> genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115<br /> genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]<br /> genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210<br /> netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550<br /> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x4ab/0x5b0 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:718 [inline]<br /> __sock_sendmsg+0xc9/0xf0 net/socket.c:733<br /> ____sys_sendmsg+0x272/0x3b0 net/socket.c:2608<br /> ___sys_sendmsg+0x2de/0x320 net/socket.c:2662<br /> __sys_sendmsg net/socket.c:2694 [inline]<br /> __do_sys_sendmsg net/socket.c:2699 [inline]<br /> __se_sys_sendmsg net/socket.c:2697 [inline]<br /> __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2697<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xed/0x360 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fc6adb66f6d<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fc6ac5a6ff8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007fc6addf5fa0 RCX: 00007fc6adb66f6d<br /> RDX: 0000000000048084 RSI: 00002000000002c0 RDI: 000000000000000e<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_skbedit: fix divide-by-zero in tcf_skbedit_hash()<br /> <br /> Commit 38a6f0865796 ("net: sched: support hash selecting tx queue")<br /> added SKBEDIT_F_TXQ_SKBHASH support. The inclusive range size is<br /> computed as:<br /> <br /> mapping_mod = queue_mapping_max - queue_mapping + 1;<br /> <br /> The range size can be 65536 when the requested range covers all possible<br /> u16 queue IDs (e.g. queue_mapping=0 and queue_mapping_max=U16_MAX).<br /> That value cannot be represented in a u16 and previously wrapped to 0,<br /> so tcf_skbedit_hash() could trigger a divide-by-zero:<br /> <br /> queue_mapping += skb_get_hash(skb) % params-&gt;mapping_mod;<br /> <br /> Compute mapping_mod in a wider type and reject ranges larger than U16_MAX<br /> to prevent params-&gt;mapping_mod from becoming 0 and avoid the crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: prevent races in -&gt;query_interfaces()<br /> <br /> It was possible for two query interface works to be concurrently trying<br /> to update the interfaces.<br /> <br /> Prevent this by checking and updating iface_last_update under<br /> iface_lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kexec: add a sanity check on previous kernel&amp;#39;s ima kexec buffer<br /> <br /> When the second-stage kernel is booted via kexec with a limiting command<br /> line such as "mem=", the physical range that contains the carried<br /> over IMA measurement list may fall outside the truncated RAM leading to a<br /> kernel panic.<br /> <br /> BUG: unable to handle page fault for address: ffff97793ff47000<br /> RIP: ima_restore_measurement_list+0xdc/0x45a<br /> #PF: error_code(0x0000) – not-present page<br /> <br /> Other architectures already validate the range with page_is_ram(), as done<br /> in commit cbf9c4b9617b ("of: check previous kernel&amp;#39;s ima-kexec-buffer<br /> against memory bounds") do a similar check on x86.<br /> <br /> Without carrying the measurement list across kexec, the attestation<br /> would fail.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access<br /> <br /> Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS,<br /> This patch protects against invalid index out of bounds access to mw_sizes<br /> When invalid access print message to user that configuration is not valid.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: ti: k3-socinfo: Fix regmap leak on probe failure<br /> <br /> The mmio regmap allocated during probe is never freed.<br /> <br /> Switch to using the device managed allocator so that the regmap is<br /> released on probe failures (e.g. probe deferral) and on driver unbind.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add signal type check for dcn401 get_phyd32clk_src<br /> <br /> Trying to access link enc on a dpia link will cause a crash otherwise

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: fix zero-frag skb in frag_list on partial sendmsg error<br /> <br /> Syzkaller reported a warning in kcm_write_msgs() when processing a<br /> message with a zero-fragment skb in the frag_list.<br /> <br /> When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb,<br /> it allocates a new skb (tskb) and links it into the frag_list before<br /> copying data. If the copy subsequently fails (e.g. -EFAULT from<br /> user memory), tskb remains in the frag_list with zero fragments:<br /> <br /> head skb (msg being assembled, NOT yet in sk_write_queue)<br /> +-----------+<br /> | frags[17] | (MAX_SKB_FRAGS, all filled with data)<br /> | frag_list-+--&gt; tskb<br /> +-----------+ +----------+<br /> | frags[0] | (empty! copy failed before filling)<br /> +----------+<br /> <br /> For SOCK_SEQPACKET with partial data already copied, the error path<br /> saves this message via partial_message for later completion. For<br /> SOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so a<br /> subsequent zero-length write(fd, NULL, 0) completes the message and<br /> queues it to sk_write_queue. kcm_write_msgs() then walks the<br /> frag_list and hits:<br /> <br /> WARN_ON(!skb_shinfo(skb)-&gt;nr_frags)<br /> <br /> TCP has a similar pattern where skbs are enqueued before data copy<br /> and cleaned up on failure via tcp_remove_empty_skb(). KCM was<br /> missing the equivalent cleanup.<br /> <br /> Fix this by tracking the predecessor skb (frag_prev) when allocating<br /> a new frag_list entry. On error, if the tail skb has zero frags,<br /> use frag_prev to unlink and free it in O(1) without walking the<br /> singly-linked frag_list. frag_prev is safe to dereference because<br /> the entire message chain is only held locally (or in kcm-&gt;seq_skb)<br /> and is not added to sk_write_queue until MSG_EOR, so the send path<br /> cannot free it underneath us.<br /> <br /> Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the log<br /> if the condition is somehow hit repeatedly.<br /> <br /> There are currently no KCM selftests in the kernel tree; a simple<br /> reproducer is available at [1].<br /> <br /> [1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs: -&gt;d_compare() must not block<br /> <br /> ... so don&amp;#39;t use __getname() there. Switch it (and ntfs_d_hash(), while<br /> we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash()<br /> almost certainly can do with smaller allocations, but let ntfs folks<br /> deal with that - keep the allocation size as-is for now.<br /> <br /> Stop abusing names_cachep in ntfs, period - various uses of that thing<br /> in there have nothing to do with pathnames; just use k[mz]alloc() and<br /> be done with that. For now let&amp;#39;s keep sizes as-in, but AFAICS none of<br /> the users actually want PATH_MAX.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: radio-keene: fix memory leak in error path<br /> <br /> Fix a memory leak in usb_keene_probe(). The v4l2 control handler is<br /> initialized and controls are added, but if v4l2_device_register() or<br /> video_register_device() fails afterward, the handler was never freed,<br /> leaking memory.<br /> <br /> Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure<br /> the control handler is properly freed for all error paths after it is<br /> initialized.