Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Check return value from memblock_phys_alloc_range()<br /> <br /> At least with CONFIG_PHYSICAL_START=0x100000, if there is

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libnvdimm/labels: Fix divide error in nd_label_data_init()<br /> <br /> If a faulty CXL memory device returns a broken zero LSA size in its<br /> memory device information (Identify Memory Device (Opcode 4000h), CXL<br /> spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm<br /> driver:<br /> <br /> Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI<br /> RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]<br /> <br /> Code and flow:<br /> <br /> 1) CXL Command 4000h returns LSA size = 0<br /> 2) config_size is assigned to zero LSA size (CXL pmem driver):<br /> <br /> drivers/cxl/pmem.c: .config_size = mds-&gt;lsa_size,<br /> <br /> 3) max_xfer is set to zero (nvdimm driver):<br /> <br /> drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd-&gt;nsarea.max_xfer, config_size);<br /> <br /> 4) A subsequent DIV_ROUND_UP() causes a division by zero:<br /> <br /> drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */<br /> drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,<br /> drivers/nvdimm/label.c- config_size);<br /> <br /> Fix this by checking the config size parameter by extending an<br /> existing check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost-scsi: protect vq-&gt;log_used with vq-&gt;mutex<br /> <br /> The vhost-scsi completion path may access vq-&gt;log_base when vq-&gt;log_used is<br /> already set to false.<br /> <br /> vhost-thread QEMU-thread<br /> <br /> vhost_scsi_complete_cmd_work()<br /> -&gt; vhost_add_used()<br /> -&gt; vhost_add_used_n()<br /> if (unlikely(vq-&gt;log_used))<br /> QEMU disables vq-&gt;log_used<br /> via VHOST_SET_VRING_ADDR.<br /> mutex_lock(&amp;vq-&gt;mutex);<br /> vq-&gt;log_used = false now!<br /> mutex_unlock(&amp;vq-&gt;mutex);<br /> <br /> QEMU gfree(vq-&gt;log_base)<br /> log_used()<br /> -&gt; log_write(vq-&gt;log_base)<br /> <br /> Assuming the VMM is QEMU. The vq-&gt;log_base is from QEMU userpace and can be<br /> reclaimed via gfree(). As a result, this causes invalid memory writes to<br /> QEMU userspace.<br /> <br /> The control queue path has the same issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio: break and reset virtio devices on device_shutdown()<br /> <br /> Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory<br /> accesses during the hang.<br /> <br /> Invalid read at addr 0x102877002, size 2, region &amp;#39;(null)&amp;#39;, reason: rejected<br /> Invalid write at addr 0x102877A44, size 2, region &amp;#39;(null)&amp;#39;, reason: rejected<br /> ...<br /> <br /> It was traced down to virtio-console. Kexec works fine if virtio-console<br /> is not in use.<br /> <br /> The issue is that virtio-console continues to write to the MMIO even after<br /> underlying virtio-pci device is reset.<br /> <br /> Additionally, Eric noticed that IOMMUs are reset before devices, if<br /> devices are not reset on shutdown they continue to poke at guest memory<br /> and get errors from the IOMMU. Some devices get wedged then.<br /> <br /> The problem can be solved by breaking all virtio devices on virtio<br /> bus shutdown, then resetting them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rseq: Fix segfault on registration when rseq_cs is non-zero<br /> <br /> The rseq_cs field is documented as being set to 0 by user-space prior to<br /> registration, however this is not currently enforced by the kernel. This<br /> can result in a segfault on return to user-space if the value stored in<br /> the rseq_cs field doesn&amp;#39;t point to a valid struct rseq_cs.<br /> <br /> The correct solution to this would be to fail the rseq registration when<br /> the rseq_cs field is non-zero. However, some older versions of glibc<br /> will reuse the rseq area of previous threads without clearing the<br /> rseq_cs field and will also terminate the process if the rseq<br /> registration fails in a secondary thread. This wasn&amp;#39;t caught in testing<br /> because in this case the leftover rseq_cs does point to a valid struct<br /> rseq_cs.<br /> <br /> What we can do is clear the rseq_cs field on registration when it&amp;#39;s<br /> non-zero which will prevent segfaults on registration and won&amp;#39;t break<br /> the glibc versions that reuse rseq areas on thread creation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: lzo - Fix compression buffer overrun<br /> <br /> Unlike the decompression code, the compression code in LZO never<br /> checked for output overruns. It instead assumes that the caller<br /> always provides enough buffer space, disregarding the buffer length<br /> provided by the caller.<br /> <br /> Add a safe compression interface that checks for the end of buffer<br /> before each write. Use the safe interface in crypto/lzo.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: fix unconditional IO throttle caused by REQ_PREFLUSH<br /> <br /> When a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush()<br /> generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC,<br /> which causes the flush_bio to be throttled by wbt_wait().<br /> <br /> An example from v5.4, similar problem also exists in upstream:<br /> <br /> crash&gt; bt 2091206<br /> PID: 2091206 TASK: ffff2050df92a300 CPU: 109 COMMAND: "kworker/u260:0"<br /> #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8<br /> #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4<br /> #2 [ffff800084a2f880] schedule at ffff800040bfa4b4<br /> #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4<br /> #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc<br /> #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0<br /> #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254<br /> #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38<br /> #8 [ffff800084a2fa60] generic_make_request at ffff800040570138<br /> #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4<br /> #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs]<br /> #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs]<br /> #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs]<br /> #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs]<br /> #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs]<br /> #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs]<br /> #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08<br /> #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc<br /> #18 [ffff800084a2fe70] kthread at ffff800040118de4<br /> <br /> After commit 2def2845cc33 ("xfs: don&amp;#39;t allow log IO to be throttled"),<br /> the metadata submitted by xlog_write_iclog() should not be throttled.<br /> But due to the existence of the dm layer, throttling flush_bio indirectly<br /> causes the metadata bio to be throttled.<br /> <br /> Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes<br /> wbt_should_throttle() return false to avoid wbt_wait().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> orangefs: Do not truncate file size<br /> <br /> &amp;#39;len&amp;#39; is used to store the result of i_size_read(), so making &amp;#39;len&amp;#39;<br /> a size_t results in truncation to 4GiB on 32-bit systems.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: prevent BUG_ON by blocking retries on failed device resumes<br /> <br /> A cache device failing to resume due to mapping errors should not be<br /> retried, as the failure leaves a partially initialized policy object.<br /> Repeating the resume operation risks triggering BUG_ON when reloading<br /> cache mappings into the incomplete policy object.<br /> <br /> Reproduce steps:<br /> <br /> 1. create a cache metadata consisting of 512 or more cache blocks,<br /> with some mappings stored in the first array block of the mapping<br /> array. Here we use cache_restore v1.0 to build the metadata.<br /> <br /> cat cmeta.xml<br /> <br /> <br /> <br /> <br /> <br /> EOF<br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2<br /> dmsetup remove cmeta<br /> <br /> 2. wipe the second array block of the mapping array to simulate<br /> data degradations.<br /> <br /> mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \<br /> 2&gt;/dev/null | hexdump -e &amp;#39;1/8 "%u\n"&amp;#39;)<br /> ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \<br /> 2&gt;/dev/null | hexdump -e &amp;#39;1/8 "%u\n"&amp;#39;)<br /> dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock<br /> <br /> 3. try bringing up the cache device. The resume is expected to fail<br /> due to the broken array block.<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 524288 linear /dev/sdc 262144"<br /> dmsetup create cache --notable<br /> dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> dmsetup resume cache<br /> <br /> 4. try resuming the cache again. An unexpected BUG_ON is triggered<br /> while loading cache mappings.<br /> <br /> dmsetup resume cache<br /> <br /> Kernel logs:<br /> <br /> (snip)<br /> ------------[ cut here ]------------<br /> kernel BUG at drivers/md/dm-cache-policy-smq.c:752!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3<br /> RIP: 0010:smq_load_mapping+0x3e5/0x570<br /> <br /> Fix by disallowing resume operations for devices that failed the<br /> initial attempt.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie<br /> <br /> The IOMMU translation for MSI message addresses has been a 2-step process,<br /> separated in time:<br /> <br /> 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address<br /> is stored in the MSI descriptor when an MSI interrupt is allocated.<br /> <br /> 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a<br /> translated message address.<br /> <br /> This has an inherent lifetime problem for the pointer stored in the cookie<br /> that must remain valid between the two steps. However, there is no locking<br /> at the irq layer that helps protect the lifetime. Today, this works under<br /> the assumption that the iommu domain is not changed while MSI interrupts<br /> being programmed. This is true for normal DMA API users within the kernel,<br /> as the iommu domain is attached before the driver is probed and cannot be<br /> changed while a driver is attached.<br /> <br /> Classic VFIO type1 also prevented changing the iommu domain while VFIO was<br /> running as it does not support changing the "container" after starting up.<br /> <br /> However, iommufd has improved this so that the iommu domain can be changed<br /> during VFIO operation. This potentially allows userspace to directly race<br /> VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and<br /> VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).<br /> <br /> This potentially causes both the cookie pointer and the unlocked call to<br /> iommu_get_domain_for_dev() on the MSI translation path to become UAFs.<br /> <br /> Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA<br /> address is already known during iommu_dma_prepare_msi() and cannot change.<br /> Thus, it can simply be stored as an integer in the MSI descriptor.<br /> <br /> The other UAF related to iommu_get_domain_for_dev() will be addressed in<br /> patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by<br /> using the IOMMU group mutex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel: Fix segfault with PEBS-via-PT with sample_freq<br /> <br /> Currently, using PEBS-via-PT with a sample frequency instead of a sample<br /> period, causes a segfault. For example:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000195<br /> <br /> ? __die_body.cold+0x19/0x27<br /> ? page_fault_oops+0xca/0x290<br /> ? exc_page_fault+0x7e/0x1b0<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? intel_pmu_pebs_event_update_no_drain+0x40/0x60<br /> ? intel_pmu_pebs_event_update_no_drain+0x32/0x60<br /> intel_pmu_drain_pebs_icl+0x333/0x350<br /> handle_pmi_common+0x272/0x3c0<br /> intel_pmu_handle_irq+0x10a/0x2e0<br /> perf_event_nmi_handler+0x2a/0x50<br /> <br /> That happens because intel_pmu_pebs_event_update_no_drain() assumes all the<br /> pebs_enabled bits represent counter indexes, which is not always the case.<br /> In this particular case, bits 60 and 61 are set for PEBS-via-PT purposes.<br /> <br /> The behaviour of PEBS-via-PT with sample frequency is questionable because<br /> although a PMI is generated (PEBS_PMI_AFTER_EACH_RECORD), the period is not<br /> adjusted anyway.<br /> <br /> Putting that aside, fix intel_pmu_pebs_event_update_no_drain() by passing<br /> the mask of counter bits instead of &amp;#39;size&amp;#39;. Note, prior to the Fixes<br /> commit, &amp;#39;size&amp;#39; would be limited to the maximum counter index, so the issue<br /> was not hit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: ocp: Limit signal/freq counts in summary output functions<br /> <br /> The debugfs summary output could access uninitialized elements in<br /> the freq_in[] and signal_out[] arrays, causing NULL pointer<br /> dereferences and triggering a kernel Oops (page_fault_oops).<br /> This patch adds u8 fields (nr_freq_in, nr_signal_out) to track the<br /> number of initialized elements, with a maximum of 4 per array.<br /> The summary output functions are updated to respect these limits,<br /> preventing out-of-bounds access and ensuring safe array handling.<br /> <br /> Widen the label variables because the change confuses GCC about<br /> max length of the strings.