Vulnerabilidades

*** 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 /> wifi: libertas: fix WARNING in usb_tx_block<br /> <br /> The function usb_tx_block() submits cardp-&gt;tx_urb without ensuring that<br /> any previous transmission on this URB has completed. If a second call<br /> occurs while the URB is still active (e.g. during rapid firmware loading),<br /> usb_submit_urb() detects the active state and triggers a warning:<br /> &amp;#39;URB submitted while active&amp;#39;.<br /> <br /> Fix this by enforcing serialization: call usb_kill_urb() before<br /> submitting the new request. This ensures the URB is idle and safe to reuse.

*** 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 /> 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 /> 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 /> vhost: move vdpa group bound check to vhost_vdpa<br /> <br /> Remove duplication by consolidating these here. This reduces the<br /> posibility of a parent driver missing them.<br /> <br /> While we&amp;#39;re at it, fix a bug in vdpa_sim where a valid ASID can be<br /> assigned to a group equal to ngroups, causing an out of bound write.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 9p/xen: protect xen_9pfs_front_free against concurrent calls<br /> <br /> The xenwatch thread can race with other back-end change notifications<br /> and call xen_9pfs_front_free() twice, hitting the observed general<br /> protection fault due to a double-free. Guard the teardown path so only<br /> one caller can release the front-end state at a time, preventing the<br /> crash.<br /> <br /> This is a fix for the following double-free:<br /> <br /> [ 27.052347] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI<br /> [ 27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-02087-g51ab33fc0a8b-dirty #60 PREEMPT(none)<br /> [ 27.052363] RIP: e030:xen_9pfs_front_free+0x1d/0x150<br /> [ 27.052368] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 41 55 41 54 55 48 89 fd 48 c7 c7 48 d0 92 85 53 e8 cb cb 05 00 48 8b 45 08 48 8b 55 00 3b 28 0f 85 f9 28 35 fe 48 3b 6a 08 0f 85 ef 28 35 fe 48 89 42<br /> [ 27.052377] RSP: e02b:ffffc9004016fdd0 EFLAGS: 00010246<br /> [ 27.052381] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88800d66e400 RCX: 0000000000000000<br /> [ 27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 0000000000000000<br /> [ 27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e46b68<br /> [ 27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a887040<br /> [ 27.052404] FS: 0000000000000000(0000) GS:ffff88808ca57000(0000) knlGS:0000000000000000<br /> [ 27.052408] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 27.052412] CR2: 00007f9714004360 CR3: 0000000004834000 CR4: 0000000000050660<br /> [ 27.052418] Call Trace:<br /> [ 27.052420] <br /> [ 27.052422] xen_9pfs_front_changed+0x5d5/0x720<br /> [ 27.052426] ? xenbus_otherend_changed+0x72/0x140<br /> [ 27.052430] ? __pfx_xenwatch_thread+0x10/0x10<br /> [ 27.052434] xenwatch_thread+0x94/0x1c0<br /> [ 27.052438] ? __pfx_autoremove_wake_function+0x10/0x10<br /> [ 27.052442] kthread+0xf8/0x240<br /> [ 27.052445] ? __pfx_kthread+0x10/0x10<br /> [ 27.052449] ? __pfx_kthread+0x10/0x10<br /> [ 27.052452] ret_from_fork+0x16b/0x1a0<br /> [ 27.052456] ? __pfx_kthread+0x10/0x10<br /> [ 27.052459] ret_from_fork_asm+0x1a/0x30<br /> [ 27.052463] <br /> [ 27.052465] Modules linked in:<br /> [ 27.052471] ---[ end trace 0000000000000000 ]---