Vulnerabilities

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "readahead: properly shorten readahead when falling back to do_page_cache_ra()"<br /> <br /> This reverts commit 7c877586da3178974a8a94577b6045a48377ff25.<br /> <br /> Anders and Philippe have reported that recent kernels occasionally hang<br /> when used with NFS in readahead code. The problem has been bisected to<br /> 7c877586da3 ("readahead: properly shorten readahead when falling back to<br /> do_page_cache_ra()"). The cause of the problem is that ra-&gt;size can be<br /> shrunk by read_pages() call and subsequently we end up calling<br /> do_page_cache_ra() with negative (read huge positive) number of pages. <br /> Let&amp;#39;s revert 7c877586da3 for now until we can find a proper way how the<br /> logic in read_pages() and page_cache_ra_order() can coexist. This can<br /> lead to reduced readahead throughput due to readahead window confusion but<br /> that&amp;#39;s better than outright hangs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-net: fix overflow inside virtnet_rq_alloc<br /> <br /> When the frag just got a page, then may lead to regression on VM.<br /> Specially if the sysctl net.core.high_order_alloc_disable value is 1,<br /> then the frag always get a page when do refill.<br /> <br /> Which could see reliable crashes or scp failure (scp a file 100M in size<br /> to VM).<br /> <br /> The issue is that the virtnet_rq_dma takes up 16 bytes at the beginning<br /> of a new frag. When the frag size is larger than PAGE_SIZE,<br /> everything is fine. However, if the frag is only one page and the<br /> total size of the buffer and virtnet_rq_dma is larger than one page, an<br /> overflow may occur.<br /> <br /> The commit f9dac92ba908 ("virtio_ring: enable premapped mode whatever<br /> use_dma_api") introduced this problem. And we reverted some commits to<br /> fix this in last linux version. Now we try to enable it and fix this<br /> bug directly.<br /> <br /> Here, when the frag size is not enough, we reduce the buffer len to fix<br /> this problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: pltfrm: Dellocate HBA during ufshcd_pltfrm_remove()<br /> <br /> This will ensure that the scsi host is cleaned up properly using<br /> scsi_host_dev_release(). Otherwise, it may lead to memory leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: RCU protect disk-&gt;conv_zones_bitmap<br /> <br /> Ensure that a disk revalidation changing the conventional zones bitmap<br /> of a disk does not cause invalid memory references when using the<br /> disk_zone_is_conv() helper by RCU protecting the disk-&gt;conv_zones_bitmap<br /> pointer.<br /> <br /> disk_zone_is_conv() is modified to operate under the RCU read lock and<br /> the function disk_set_conv_zones_bitmap() is added to update a disk<br /> conv_zones_bitmap pointer using rcu_replace_pointer() with the disk<br /> zone_wplugs_lock spinlock held.<br /> <br /> disk_free_zone_resources() is modified to call<br /> disk_update_zone_resources() with a NULL bitmap pointer to free the disk<br /> conv_zones_bitmap. disk_set_conv_zones_bitmap() is also used in<br /> disk_update_zone_resources() to set the new (revalidated) bitmap and<br /> free the old one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/cpum_sf: Handle CPU hotplug remove during sampling<br /> <br /> CPU hotplug remove handling triggers the following function<br /> call sequence:<br /> <br /> CPUHP_AP_PERF_S390_SF_ONLINE --&gt; s390_pmu_sf_offline_cpu()<br /> ...<br /> CPUHP_AP_PERF_ONLINE --&gt; perf_event_exit_cpu()<br /> <br /> The s390 CPUMF sampling CPU hotplug handler invokes:<br /> <br /> s390_pmu_sf_offline_cpu()<br /> +--&gt; cpusf_pmu_setup()<br /> +--&gt; setup_pmc_cpu()<br /> +--&gt; deallocate_buffers()<br /> <br /> This function de-allocates all sampling data buffers (SDBs) allocated<br /> for that CPU at event initialization. It also clears the<br /> PMU_F_RESERVED bit. The CPU is gone and can not be sampled.<br /> <br /> With the event still being active on the removed CPU, the CPU event<br /> hotplug support in kernel performance subsystem triggers the<br /> following function calls on the removed CPU:<br /> <br /> perf_event_exit_cpu()<br /> +--&gt; perf_event_exit_cpu_context()<br /> +--&gt; __perf_event_exit_context()<br /> +--&gt; __perf_remove_from_context()<br /> +--&gt; event_sched_out()<br /> +--&gt; cpumsf_pmu_del()<br /> +--&gt; cpumsf_pmu_stop()<br /> +--&gt; hw_perf_event_update()<br /> <br /> to stop and remove the event. During removal of the event, the<br /> sampling device driver tries to read out the remaining samples from<br /> the sample data buffers (SDBs). But they have already been freed<br /> (and may have been re-assigned). This may lead to a use after free<br /> situation in which case the samples are most likely invalid. In the<br /> best case the memory has not been reassigned and still contains<br /> valid data.<br /> <br /> Remedy this situation and check if the CPU is still in reserved<br /> state (bit PMU_F_RESERVED set). In this case the SDBs have not been<br /> released an contain valid data. This is always the case when<br /> the event is removed (and no CPU hotplug off occured).<br /> If the PMU_F_RESERVED bit is not set, the SDB buffers are gone.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jffs2: Prevent rtime decompress memory corruption<br /> <br /> The rtime decompression routine does not fully check bounds during the<br /> entirety of the decompression pass and can corrupt memory outside the<br /> decompression buffer if the compressed data is corrupted. This adds the<br /> required check to prevent this failure mode.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL<br /> <br /> Currently tagged_addr_ctrl_set() doesn&amp;#39;t initialize the temporary &amp;#39;ctrl&amp;#39;<br /> variable, and a SETREGSET call with a length of zero will leave this<br /> uninitialized. Consequently tagged_addr_ctrl_set() will consume an<br /> arbitrary value, potentially leaking up to 64 bits of memory from the<br /> kernel stack. The read is limited to a specific slot on the stack, and<br /> the issue does not provide a write mechanism.<br /> <br /> As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and<br /> rejects other values, a partial SETREGSET attempt will randomly succeed<br /> or fail depending on the value of the uninitialized value, and the<br /> exposure is significantly limited.<br /> <br /> Fix this by initializing the temporary value before copying the regset<br /> from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,<br /> NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing<br /> value of the tagged address ctrl will be retained.<br /> <br /> The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the<br /> user_aarch64_view used by a native AArch64 task to manipulate another<br /> native AArch64 task. As get_tagged_addr_ctrl() only returns an error<br /> value when called for a compat task, tagged_addr_ctrl_get() and<br /> tagged_addr_ctrl_set() should never observe an error value from<br /> get_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that<br /> such an error would be unexpected, and error handlnig is not missing in<br /> either case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/dp_mst: Fix resetting msg rx state after topology removal<br /> <br /> If the MST topology is removed during the reception of an MST down reply<br /> or MST up request sideband message, the<br /> drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset<br /> from one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with<br /> the reading/parsing of the message from another thread via<br /> drm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is<br /> possible since the reader/parser doesn&amp;#39;t hold any lock while accessing<br /> the reception state. This in turn can lead to a memory corruption in the<br /> reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST<br /> sideband message body length check").<br /> <br /> Fix the above by resetting the message reception state if needed before<br /> reading/parsing a message. Another solution would be to hold the<br /> drm_dp_mst_topology_mgr::lock for the whole duration of the message<br /> reception/parsing in drm_dp_mst_handle_down_rep() and<br /> drm_dp_mst_handle_up_req(), however this would require a bigger change.<br /> Since the fix is also needed for stable, opting for the simpler solution<br /> in this patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: imx6: Fix suspend/resume support on i.MX6QDL<br /> <br /> The suspend/resume functionality is currently broken on the i.MX6QDL<br /> platform, as documented in the NXP errata (ERR005723):<br /> <br /> https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf<br /> <br /> This patch addresses the issue by sharing most of the suspend/resume<br /> sequences used by other i.MX devices, while avoiding modifications to<br /> critical registers that disrupt the PCIe functionality. It targets the<br /> same problem as the following downstream commit:<br /> <br /> https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995<br /> <br /> Unlike the downstream commit, this patch also resets the connected PCIe<br /> device if possible. Without this reset, certain drivers, such as ath10k<br /> or iwlwifi, will crash on resume. The device reset is also done by the<br /> driver on other i.MX platforms, making this patch consistent with<br /> existing practices.<br /> <br /> Upon resuming, the kernel will hang and display an error. Here&amp;#39;s an<br /> example of the error encountered with the ath10k driver:<br /> <br /> ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible<br /> Unhandled fault: imprecise external abort (0x1406) at 0x0106f944<br /> <br /> Without this patch, suspend/resume will fail on i.MX6QDL devices if a<br /> PCIe device is connected.<br /> <br /> [kwilczynski: commit log, added tag for stable releases]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/entry: Mark IRQ entries to fix stack depot warnings<br /> <br /> The stack depot filters out everything outside of the top interrupt<br /> context as an uninteresting or irrelevant part of the stack traces. This<br /> helps with stack trace de-duplication, avoiding an explosion of saved<br /> stack traces that share the same IRQ context code path but originate<br /> from different randomly interrupted points, eventually exhausting the<br /> stack depot.<br /> <br /> Filtering uses in_irqentry_text() to identify functions within the<br /> .irqentry.text and .softirqentry.text sections, which then become the<br /> last stack trace entries being saved.<br /> <br /> While __do_softirq() is placed into the .softirqentry.text section by<br /> common code, populating .irqentry.text is architecture-specific.<br /> <br /> Currently, the .irqentry.text section on s390 is empty, which prevents<br /> stack depot filtering and de-duplication and could result in warnings<br /> like:<br /> <br /> Stack depot reached limit capacity<br /> WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8<br /> <br /> with PREEMPT and KASAN enabled.<br /> <br /> Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into<br /> the .irqentry.text section and updating the kprobes blacklist to include<br /> the .irqentry.text section.<br /> <br /> This is done only for asynchronous interrupts and explicitly not for<br /> program checks, which are synchronous and where the context beyond the<br /> program check is important to preserve. Despite machine checks being<br /> somewhat in between, they are extremely rare, and preserving context<br /> when possible is also of value.<br /> <br /> SVCs and Restart Interrupts are not relevant, one being always at the<br /> boundary to user space and the other being a one-time thing.<br /> <br /> IRQ entries filtering is also optionally used in ftrace function graph,<br /> where the same logic applies.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: memalloc: prefer dma_mapping_error() over explicit address checking<br /> <br /> With CONFIG_DMA_API_DEBUG enabled, the following warning is observed:<br /> <br /> DMA-API: snd_hda_intel 0000:03:00.1: device driver failed to check map error[device address=0x00000000ffff0000] [size=20480 bytes] [mapped as single]<br /> WARNING: CPU: 28 PID: 2255 at kernel/dma/debug.c:1036 check_unmap+0x1408/0x2430<br /> CPU: 28 UID: 42 PID: 2255 Comm: wireplumber Tainted: G W L 6.12.0-10-133577cad6bf48e5a7848c4338124081393bfe8a+ #759<br /> debug_dma_unmap_page+0xe9/0xf0<br /> snd_dma_wc_free+0x85/0x130 [snd_pcm]<br /> snd_pcm_lib_free_pages+0x1e3/0x440 [snd_pcm]<br /> snd_pcm_common_ioctl+0x1c9a/0x2960 [snd_pcm]<br /> snd_pcm_ioctl+0x6a/0xc0 [snd_pcm]<br /> ...<br /> <br /> Check for returned DMA addresses using specialized dma_mapping_error()<br /> helper which is generally recommended for this purpose by<br /> Documentation/core-api/dma-api.rst.