Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: fiemap page fault fix<br /> <br /> In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode<br /> glock. This can lead to recursive glock taking if the fiemap buffer is<br /> memory mapped to the same inode and accessing it triggers a page fault.<br /> <br /> Fix by disabling page faults for iomap_fiemap() and faulting in the<br /> buffer by hand if necessary.<br /> <br /> Fixes xfstest generic/742.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: of: display_timing: fix refcount leak in of_get_display_timings()<br /> <br /> of_parse_phandle() returns a device_node with refcount incremented,<br /> which is stored in &amp;#39;entry&amp;#39; and then copied to &amp;#39;native_mode&amp;#39;. When the<br /> error paths at lines 184 or 192 jump to &amp;#39;entryfail&amp;#39;, native_mode&amp;#39;s<br /> refcount is not decremented, causing a refcount leak.<br /> <br /> Fix this by changing the goto target from &amp;#39;entryfail&amp;#39; to &amp;#39;timingfail&amp;#39;,<br /> which properly calls of_node_put(native_mode) before cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Ignore -EBUSY when checking nested events from vcpu_block()<br /> <br /> Ignore -EBUSY when checking nested events after exiting a blocking state<br /> while L2 is active, as exiting to userspace will generate a spurious<br /> userspace exit, usually with KVM_EXIT_UNKNOWN, and likely lead to the VM&amp;#39;s<br /> demise. Continuing with the wakeup isn&amp;#39;t perfect either, as *something*<br /> has gone sideways if a vCPU is awakened in L2 with an injected event (or<br /> worse, a nested run pending), but continuing on gives the VM a decent<br /> chance of surviving without any major side effects.<br /> <br /> As explained in the Fixes commits, it _should_ be impossible for a vCPU to<br /> be put into a blocking state with an already-injected event (exception,<br /> IRQ, or NMI). Unfortunately, userspace can stuff MP_STATE and/or injected<br /> events, and thus put the vCPU into what should be an impossible state.<br /> <br /> Don&amp;#39;t bother trying to preserve the WARN, e.g. with an anti-syzkaller<br /> Kconfig, as WARNs can (hopefully) be added in paths where _KVM_ would be<br /> violating x86 architecture, e.g. by WARNing if KVM attempts to inject an<br /> exception or interrupt while the vCPU isn&amp;#39;t running.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EFI/CPER: don&amp;#39;t go past the ARM processor CPER record buffer<br /> <br /> There&amp;#39;s a logic inside GHES/CPER to detect if the section_length<br /> is too small, but it doesn&amp;#39;t detect if it is too big.<br /> <br /> Currently, if the firmware receives an ARM processor CPER record<br /> stating that a section length is big, kernel will blindly trust<br /> section_length, producing a very long dump. For instance, a 67<br /> bytes record with ERR_INFO_NUM set 46198 and section length<br /> set to 854918320 would dump a lot of data going a way past the<br /> firmware memory-mapped area.<br /> <br /> Fix it by adding a logic to prevent it to go past the buffer<br /> if ERR_INFO_NUM is too big, making it report instead:<br /> <br /> [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1<br /> [Hardware Error]: event severity: recoverable<br /> [Hardware Error]: Error 0, type: recoverable<br /> [Hardware Error]: section_type: ARM processor error<br /> [Hardware Error]: MIDR: 0xff304b2f8476870a<br /> [Hardware Error]: section length: 854918320, CPER size: 67<br /> [Hardware Error]: section length is too big<br /> [Hardware Error]: firmware-generated error record is incorrect<br /> [Hardware Error]: ERR_INFO_NUM is 46198<br /> <br /> [ rjw: Subject and changelog tweaks ]

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

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