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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: copy_verifier_state() should copy &amp;#39;loop_entry&amp;#39; field<br /> <br /> The bpf_verifier_state.loop_entry state should be copied by<br /> copy_verifier_state(). Otherwise, .loop_entry values from unrelated<br /> states would poison env-&gt;cur_state.<br /> <br /> Additionally, env-&gt;stack should not contain any states with<br /> .loop_entry != NULL. The states in env-&gt;stack are yet to be verified,<br /> while .loop_entry is set for states that reached an equivalent state.<br /> This means that env-&gt;cur_state-&gt;loop_entry should always be NULL after<br /> pop_stack().<br /> <br /> See the selftest in the next commit for an example of the program that<br /> is not safe yet is accepted by verifier w/o this fix.<br /> <br /> This change has some verification performance impact for selftests:<br /> <br /> File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)<br /> ---------------------------------- ---------------------------- --------- --------- -------------- ---------- ---------- -------------<br /> arena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%)<br /> arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%)<br /> arena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%)<br /> iters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%)<br /> iters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%)<br /> iters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%)<br /> kmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%)<br /> verifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%)<br /> verifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%)<br /> <br /> And significant negative impact for sched_ext:<br /> <br /> File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)<br /> ----------------- ---------------------- --------- --------- -------------------- ---------- ---------- ------------------<br /> bpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%)<br /> bpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%)<br /> bpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%)<br /> bpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%)<br /> bpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%)<br /> bpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%)<br /> bpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%)<br /> bpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%)<br /> scx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%)<br /> scx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%)<br /> scx_qmap.bpf.o qmap_dispatch <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: avoid NULL pointer dereference if no valid csum tree<br /> <br /> [BUG]<br /> When trying read-only scrub on a btrfs with rescue=idatacsums mount<br /> option, it will crash with the following call trace:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000208<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022<br /> RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs]<br /> Call Trace:<br /> <br /> scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs]<br /> scrub_simple_mirror+0x175/0x290 [btrfs]<br /> scrub_stripe+0x5f7/0x6f0 [btrfs]<br /> scrub_chunk+0x9a/0x150 [btrfs]<br /> scrub_enumerate_chunks+0x333/0x660 [btrfs]<br /> btrfs_scrub_dev+0x23e/0x600 [btrfs]<br /> btrfs_ioctl+0x1dcf/0x2f80 [btrfs]<br /> __x64_sys_ioctl+0x97/0xc0<br /> do_syscall_64+0x4f/0x120<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> [CAUSE]<br /> Mount option "rescue=idatacsums" will completely skip loading the csum<br /> tree, so that any data read will not find any data csum thus we will<br /> ignore data checksum verification.<br /> <br /> Normally call sites utilizing csum tree will check the fs state flag<br /> NO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all.<br /> <br /> This results in scrub to call btrfs_search_slot() on a NULL pointer<br /> and triggered above crash.<br /> <br /> [FIX]<br /> Check both extent and csum tree root before doing any tree search.