Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx88: Add missing unmap in snd_cx88_hw_params()<br /> <br /> In error path, add cx88_alsa_dma_unmap() to release<br /> resource acquired by cx88_alsa_dma_map().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: move wait_on_sem() out of spinlock<br /> <br /> With iommu.strict=1, the existing completion wait path can cause soft<br /> lockups under stressed environment, as wait_on_sem() busy-waits under the<br /> spinlock with interrupts disabled.<br /> <br /> Move the completion wait in iommu_completion_wait() out of the spinlock.<br /> wait_on_sem() only polls the hardware-updated cmd_sem and does not require<br /> iommu-&gt;lock, so holding the lock during the busy wait unnecessarily<br /> increases contention and extends the time with interrupts disabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: tcp - fix packet extraction from stream<br /> <br /> When processing TCP stream data in ovpn_tcp_recv, we receive large<br /> cloned skbs from __strp_rcv that may contain multiple coalesced packets.<br /> The current implementation has two bugs:<br /> <br /> 1. Header offset overflow: Using pskb_pull with large offsets on<br /> coalesced skbs causes skb-&gt;data - skb-&gt;head to exceed the u16 storage<br /> of skb-&gt;network_header. This causes skb_reset_network_header to fail<br /> on the inner decapsulated packet, resulting in packet drops.<br /> <br /> 2. Unaligned protocol headers: Extracting packets from arbitrary<br /> positions within the coalesced TCP stream provides no alignment<br /> guarantees for the packet data causing performance penalties on<br /> architectures without efficient unaligned access. Additionally,<br /> openvpn&amp;#39;s 2-byte length prefix on TCP packets causes the subsequent<br /> 4-byte opcode and packet ID fields to be inherently misaligned.<br /> <br /> Fix both issues by allocating a new skb for each openvpn packet and<br /> using skb_copy_bits to extract only the packet content into the new<br /> buffer, skipping the 2-byte length prefix. Also, check the length before<br /> invoking the function that performs the allocation to avoid creating an<br /> invalid skb.<br /> <br /> If the packet has to be forwarded to userspace the 2-byte prefix can be<br /> pushed to the head safely, without misalignment.<br /> <br /> As a side effect, this approach also avoids the expensive linearization<br /> that pskb_pull triggers on cloned skbs with page fragments. In testing,<br /> this resulted in TCP throughput improvements of up to 74%.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: qcom: camss: vfe: Fix out-of-bounds access in vfe_isr_reg_update()<br /> <br /> vfe_isr() iterates using MSM_VFE_IMAGE_MASTERS_NUM(7) as the loop<br /> bound and passes the index to vfe_isr_reg_update(). However,<br /> vfe-&gt;line[] array is defined with VFE_LINE_NUM_MAX(4):<br /> <br /> struct vfe_line line[VFE_LINE_NUM_MAX];<br /> <br /> When index is 4, 5, 6, the access to vfe-&gt;line[line_id] exceeds<br /> the array bounds and resulting in out-of-bounds memory access.<br /> <br /> Fix this by using separate loops for output lines and write masters.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> alpha: fix user-space corruption during memory compaction<br /> <br /> Alpha systems can suffer sporadic user-space crashes and heap<br /> corruption when memory compaction is enabled.<br /> <br /> Symptoms include SIGSEGV, glibc allocator failures (e.g. "unaligned<br /> tcache chunk"), and compiler internal errors. The failures disappear<br /> when compaction is disabled or when using global TLB invalidation.<br /> <br /> The root cause is insufficient TLB shootdown during page migration.<br /> Alpha relies on ASN-based MM context rollover for instruction cache<br /> coherency, but this alone is not sufficient to prevent stale data or<br /> instruction translations from surviving migration.<br /> <br /> Fix this by introducing a migration-specific helper that combines:<br /> - MM context invalidation (ASN rollover),<br /> - immediate per-CPU TLB invalidation (TBI),<br /> - synchronous cross-CPU shootdown when required.<br /> <br /> The helper is used only by migration/compaction paths to avoid changing<br /> global TLB semantics.<br /> <br /> Additionally, update flush_tlb_other(), pte_clear(), to use<br /> READ_ONCE()/WRITE_ONCE() for correct SMP memory ordering.<br /> <br /> This fixes observed crashes on both UP and SMP Alpha systems.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: fsl-imx8mq-usb: set platform driver data<br /> <br /> Add missing platform_set_drvdata() as the data will be used in remove().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix RSS context delete logic<br /> <br /> We need to free the corresponding RSS context VNIC<br /> in FW everytime an RSS context is deleted in driver.<br /> Commit 667ac333dbb7 added a check to delete the VNIC<br /> in FW only when netif_running() is true to help delete<br /> RSS contexts with interface down.<br /> <br /> Having that condition will make the driver leak VNICs<br /> in FW whenever close() happens with active RSS contexts.<br /> On the subsequent open(), as part of RSS context restoration,<br /> we will end up trying to create extra VNICs for which we<br /> did not make any reservation. FW can fail this request,<br /> thereby making us lose active RSS contexts.<br /> <br /> Suppose an RSS context is deleted already and we try to<br /> process a delete request again, then the HWRM functions<br /> will check for validity of the request and they simply<br /> return if the resource is already freed. So, even for<br /> delete-when-down cases, netif_running() check is not<br /> necessary.<br /> <br /> Remove the netif_running() condition check when deleting<br /> an RSS context.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c/tw9906: Fix potential memory leak in tw9906_probe()<br /> <br /> In one of the error paths in tw9906_probe(), the memory allocated in<br /> v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that<br /> by calling v4l2_ctrl_handler_free() on the handler in that error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: chips-media: wave5: Fix SError of kernel panic when closed<br /> <br /> SError of kernel panic rarely happened while testing fluster.<br /> The root cause was to enter suspend mode because timeout of autosuspend<br /> delay happened.<br /> <br /> [ 48.834439] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError<br /> [ 48.834455] CPU: 0 UID: 0 PID: 1067 Comm: v4l2h265dec0:sr Not tainted 6.12.9-gc9e21a1ebd75-dirty #7<br /> [ 48.834461] Hardware name: ti Texas Instruments J721S2 EVM/Texas Instruments J721S2 EVM, BIOS 2025.01-00345-gbaf3aaa8ecfa 01/01/2025<br /> [ 48.834464] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 48.834468] pc : wave5_dec_clr_disp_flag+0x40/0x80 [wave5]<br /> [ 48.834488] lr : wave5_dec_clr_disp_flag+0x40/0x80 [wave5]<br /> [ 48.834495] sp : ffff8000856e3a30<br /> [ 48.834497] x29: ffff8000856e3a30 x28: ffff0008093f6010 x27: ffff000809158130<br /> [ 48.834504] x26: 0000000000000000 x25: ffff00080b625000 x24: ffff000804a9ba80<br /> [ 48.834509] x23: ffff000802343028 x22: ffff000809158150 x21: ffff000802218000<br /> [ 48.834513] x20: ffff0008093f6000 x19: ffff0008093f6000 x18: 0000000000000000<br /> [ 48.834518] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff74009618<br /> [ 48.834523] x14: 000000010000000c x13: 0000000000000000 x12: 0000000000000000<br /> [ 48.834527] x11: ffffffffffffffff x10: ffffffffffffffff x9 : ffff000802343028<br /> [ 48.834532] x8 : ffff00080b6252a0 x7 : 0000000000000038 x6 : 0000000000000000<br /> [ 48.834536] x5 : ffff00080b625060 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 48.834541] x2 : 0000000000000000 x1 : ffff800084bf0118 x0 : ffff800084bf0000<br /> [ 48.834547] Kernel panic - not syncing: Asynchronous SError Interrupt<br /> [ 48.834549] CPU: 0 UID: 0 PID: 1067 Comm: v4l2h265dec0:sr Not tainted 6.12.9-gc9e21a1ebd75-dirty #7<br /> [ 48.834554] Hardware name: ti Texas Instruments J721S2 EVM/Texas Instruments J721S2 EVM, BIOS 2025.01-00345-gbaf3aaa8ecfa 01/01/2025<br /> [ 48.834556] Call trace:<br /> [ 48.834559] dump_backtrace+0x94/0xec<br /> [ 48.834574] show_stack+0x18/0x24<br /> [ 48.834579] dump_stack_lvl+0x38/0x90<br /> [ 48.834585] dump_stack+0x18/0x24<br /> [ 48.834588] panic+0x35c/0x3e0<br /> [ 48.834592] nmi_panic+0x40/0x8c<br /> [ 48.834595] arm64_serror_panic+0x64/0x70<br /> [ 48.834598] do_serror+0x3c/0x78<br /> [ 48.834601] el1h_64_error_handler+0x34/0x4c<br /> [ 48.834605] el1h_64_error+0x64/0x68<br /> [ 48.834608] wave5_dec_clr_disp_flag+0x40/0x80 [wave5]<br /> [ 48.834615] wave5_vpu_dec_clr_disp_flag+0x54/0x80 [wave5]<br /> [ 48.834622] wave5_vpu_dec_buf_queue+0x19c/0x1a0 [wave5]<br /> [ 48.834628] __enqueue_in_driver+0x3c/0x74 [videobuf2_common]<br /> [ 48.834639] vb2_core_qbuf+0x508/0x61c [videobuf2_common]<br /> [ 48.834646] vb2_qbuf+0xa4/0x168 [videobuf2_v4l2]<br /> [ 48.834656] v4l2_m2m_qbuf+0x80/0x238 [v4l2_mem2mem]<br /> [ 48.834666] v4l2_m2m_ioctl_qbuf+0x18/0x24 [v4l2_mem2mem]<br /> [ 48.834673] v4l_qbuf+0x48/0x5c [videodev]<br /> [ 48.834704] __video_do_ioctl+0x180/0x3f0 [videodev]<br /> [ 48.834725] video_usercopy+0x2ec/0x68c [videodev]<br /> [ 48.834745] video_ioctl2+0x18/0x24 [videodev]<br /> [ 48.834766] v4l2_ioctl+0x40/0x60 [videodev]<br /> [ 48.834786] __arm64_sys_ioctl+0xa8/0xec<br /> [ 48.834793] invoke_syscall+0x44/0x100<br /> [ 48.834800] el0_svc_common.constprop.0+0xc0/0xe0<br /> [ 48.834804] do_el0_svc+0x1c/0x28<br /> [ 48.834809] el0_svc+0x30/0xd0<br /> [ 48.834813] el0t_64_sync_handler+0xc0/0xc4<br /> [ 48.834816] el0t_64_sync+0x190/0x194<br /> [ 48.834820] SMP: stopping secondary CPUs<br /> [ 48.834831] Kernel Offset: disabled<br /> [ 48.834833] CPU features: 0x08,00002002,80200000,4200421b<br /> [ 48.834837] Memory Limit: none<br /> [ 49.161404] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---

*** 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---