Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix log recovery buffer allocation for the legacy h_size fixup<br /> <br /> Commit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by<br /> mkfs") added a fixup for incorrect h_size values used for the initial<br /> umount record in old xfsprogs versions. Later commit 0c771b99d6c9<br /> ("xfs: clean up calculation of LR header blocks") cleaned up the log<br /> reover buffer calculation, but stoped using the fixed up h_size value<br /> to size the log recovery buffer, which can lead to an out of bounds<br /> access when the incorrect h_size does not come from the old mkfs<br /> tool, but a fuzzer.<br /> <br /> Fix this by open coding xlog_logrec_hblks and taking the fixed h_size<br /> into account for this calculation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension<br /> <br /> If a process module does not have base config extension then the same<br /> format applies to all of it&amp;#39;s inputs and the process-&gt;base_config_ext is<br /> NULL, causing NULL dereference when specifically crafted topology and<br /> sequences used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL<br /> <br /> commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc")<br /> includes support for __GFP_NOFAIL, but it presents a conflict with commit<br /> dd544141b9eb ("vmalloc: back off when the current task is OOM-killed"). A<br /> possible scenario is as follows:<br /> <br /> process-a<br /> __vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL)<br /> __vmalloc_area_node()<br /> vm_area_alloc_pages()<br /> --&gt; oom-killer send SIGKILL to process-a<br /> if (fatal_signal_pending(current)) break;<br /> --&gt; return NULL;<br /> <br /> To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages()<br /> if __GFP_NOFAIL set.<br /> <br /> This issue occurred during OPLUS KASAN TEST. Below is part of the log<br /> -&gt; oom-killer sends signal to process<br /> [65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198<br /> <br /> [65731.259685] [T32454] Call trace:<br /> [65731.259698] [T32454] dump_backtrace+0xf4/0x118<br /> [65731.259734] [T32454] show_stack+0x18/0x24<br /> [65731.259756] [T32454] dump_stack_lvl+0x60/0x7c<br /> [65731.259781] [T32454] dump_stack+0x18/0x38<br /> [65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump]<br /> [65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump]<br /> [65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc<br /> [65731.260047] [T32454] notify_die+0x114/0x198<br /> [65731.260073] [T32454] die+0xf4/0x5b4<br /> [65731.260098] [T32454] die_kernel_fault+0x80/0x98<br /> [65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8<br /> [65731.260146] [T32454] do_bad_area+0x68/0x148<br /> [65731.260174] [T32454] do_mem_abort+0x151c/0x1b34<br /> [65731.260204] [T32454] el1_abort+0x3c/0x5c<br /> [65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90<br /> [65731.260248] [T32454] el1h_64_sync+0x68/0x6c<br /> <br /> [65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258<br /> --&gt; be-&gt;decompressed_pages = kvcalloc(be-&gt;nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL);<br /> kernel panic by NULL pointer dereference.<br /> erofs assume kvmalloc with __GFP_NOFAIL never return NULL.<br /> [65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c<br /> [65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968<br /> [65731.260339] [T32454] read_pages+0x170/0xadc<br /> [65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30<br /> [65731.260388] [T32454] page_cache_ra_order+0x24c/0x714<br /> [65731.260411] [T32454] filemap_fault+0xbf0/0x1a74<br /> [65731.260437] [T32454] __do_fault+0xd0/0x33c<br /> [65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0<br /> [65731.260486] [T32454] do_mem_abort+0x54c/0x1b34<br /> [65731.260509] [T32454] el0_da+0x44/0x94<br /> [65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4<br /> [65731.260553] [T32454] el0t_64_sync+0x198/0x19c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: savage: Handle err return when savagefb_check_var failed<br /> <br /> The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")<br /> checks the value of pixclock to avoid divide-by-zero error. However<br /> the function savagefb_probe doesn&amp;#39;t handle the error return of<br /> savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING<br /> <br /> Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with<br /> small possibility, the root cause is exactly the same as commit<br /> bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")<br /> <br /> However, Dan reported another hang after that, and junxiao investigated<br /> the problem and found out that this is caused by plugged bio can&amp;#39;t issue<br /> from raid5d().<br /> <br /> Current implementation in raid5d() has a weird dependence:<br /> <br /> 1) md_check_recovery() from raid5d() must hold &amp;#39;reconfig_mutex&amp;#39; to clear<br /> MD_SB_CHANGE_PENDING;<br /> 2) raid5d() handles IO in a deadloop, until all IO are issued;<br /> 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;<br /> <br /> This behaviour is introduce before v2.6, and for consequence, if other<br /> context hold &amp;#39;reconfig_mutex&amp;#39;, and md_check_recovery() can&amp;#39;t update<br /> super_block, then raid5d() will waste one cpu 100% by the deadloop, until<br /> &amp;#39;reconfig_mutex&amp;#39; is released.<br /> <br /> Refer to the implementation from raid1 and raid10, fix this problem by<br /> skipping issue IO if MD_SB_CHANGE_PENDING is still set after<br /> md_check_recovery(), daemon thread will be woken up when &amp;#39;reconfig_mutex&amp;#39;<br /> is released. Meanwhile, the hang problem will be fixed as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: do not call vma_add_reservation upon ENOMEM<br /> <br /> sysbot reported a splat [1] on __unmap_hugepage_range(). This is because<br /> vma_needs_reservation() can return -ENOMEM if<br /> allocate_file_region_entries() fails to allocate the file_region struct<br /> for the reservation.<br /> <br /> Check for that and do not call vma_add_reservation() if that is the case,<br /> otherwise region_abort() and region_del() will see that we do not have any<br /> file_regions.<br /> <br /> If we detect that vma_needs_reservation() returned -ENOMEM, we clear the<br /> hugetlb_restore_reserve flag as if this reservation was still consumed, so<br /> free_huge_folio() will not increment the resv count.<br /> <br /> [1] https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/T/#ma5983bc1ab18a54910da83416b3f89f3c7ee43aa

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: starfive - Do not free stack buffer<br /> <br /> RSA text data uses variable length buffer allocated in software stack.<br /> Calling kfree on it causes undefined behaviour in subsequent operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kdb: Fix buffer overflow during tab-complete<br /> <br /> Currently, when the user attempts symbol completion with the Tab key, kdb<br /> will use strncpy() to insert the completed symbol into the command buffer.<br /> Unfortunately it passes the size of the source buffer rather than the<br /> destination to strncpy() with predictably horrible results. Most obviously<br /> if the command buffer is already full but cp, the cursor position, is in<br /> the middle of the buffer, then we will write past the end of the supplied<br /> buffer.<br /> <br /> Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()<br /> calls plus explicit boundary checks to make sure we have enough space<br /> before we start moving characters around.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mc: Fix graph walk in media_pipeline_start<br /> <br /> The graph walk tries to follow all links, even if they are not between<br /> pads. This causes a crash with, e.g. a MEDIA_LNK_FL_ANCILLARY_LINK link.<br /> <br /> Fix this by allowing the walk to proceed only for MEDIA_LNK_FL_DATA_LINK<br /> links.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked<br /> <br /> When requesting an NMI window, WARN on vNMI support being enabled if and<br /> only if NMIs are actually masked, i.e. if the vCPU is already handling an<br /> NMI. KVM&amp;#39;s ABI for NMIs that arrive simultanesouly (from KVM&amp;#39;s point of<br /> view) is to inject one NMI and pend the other. When using vNMI, KVM pends<br /> the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the<br /> rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected).<br /> <br /> However, if KVM can&amp;#39;t immediately inject an NMI, e.g. because the vCPU is<br /> in an STI shadow or is running with GIF=0, then KVM will request an NMI<br /> window and trigger the WARN (but still function correctly).<br /> <br /> Whether or not the GIF=0 case makes sense is debatable, as the intent of<br /> KVM&amp;#39;s behavior is to provide functionality that is as close to real<br /> hardware as possible. E.g. if two NMIs are sent in quick succession, the<br /> probability of both NMIs arriving in an STI shadow is infinitesimally low<br /> on real hardware, but significantly larger in a virtual environment, e.g.<br /> if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn&amp;#39;t<br /> as clear cut, because the window where two NMIs can collide is much larger<br /> in bare metal (though still small).<br /> <br /> That said, KVM should not have divergent behavior for the GIF=0 case based<br /> on whether or not vNMI support is enabled. And KVM has allowed<br /> simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400<br /> ("KVM: Fix simultaneous NMIs"). I.e. KVM&amp;#39;s GIF=0 handling shouldn&amp;#39;t be<br /> modified without a *really* good reason to do so, and if KVM&amp;#39;s behavior<br /> were to be modified, it should be done irrespective of vNMI support.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l: async: Properly re-initialise notifier entry in unregister<br /> <br /> The notifier_entry of a notifier is not re-initialised after unregistering<br /> the notifier. This leads to dangling pointers being left there so use<br /> list_del_init() to return the notifier_entry an empty list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: fix variable length array abuse in btree_iter<br /> <br /> btree_iter is used in two ways: either allocated on the stack with a<br /> fixed size MAX_BSETS, or from a mempool with a dynamic size based on the<br /> specific cache set. Previously, the struct had a fixed-length array of<br /> size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized<br /> iterators, which causes UBSAN to complain.<br /> <br /> This patch uses the same approach as in bcachefs&amp;#39;s sort_iter and splits<br /> the iterator into a btree_iter with a flexible array member and a<br /> btree_iter_stack which embeds a btree_iter as well as a fixed-length<br /> data array.