Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: pretend special inodes as regular files<br /> <br /> Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()")<br /> requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/<br /> S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: fix potential zero beacon interval in beacon tracking<br /> <br /> During fuzz testing, it was discovered that bss_conf-&gt;beacon_int<br /> might be zero, which could result in a division by zero error in<br /> subsequent calculations. Set a default value of 100 TU if the<br /> interval is zero to ensure stability.

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().

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.

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.

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().

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.

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.

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%.

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.

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

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.