Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> swiotlb: Fix double-allocation of slots due to broken alignment handling<br /> <br /> Commit bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix"),<br /> which was a fix for commit 0eee5ae10256 ("swiotlb: fix slot alignment<br /> checks"), causes a functional regression with vsock in a virtual machine<br /> using bouncing via a restricted DMA SWIOTLB pool.<br /> <br /> When virtio allocates the virtqueues for the vsock device using<br /> dma_alloc_coherent(), the SWIOTLB search can return page-unaligned<br /> allocations if &amp;#39;area-&gt;index&amp;#39; was left unaligned by a previous allocation<br /> from the buffer:<br /> <br /> # Final address in brackets is the SWIOTLB address returned to the caller<br /> | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800)<br /> | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800)<br /> | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800)<br /> <br /> This ends badly (typically buffer corruption and/or a hang) because<br /> swiotlb_alloc() is expecting a page-aligned allocation and so blindly<br /> returns a pointer to the &amp;#39;struct page&amp;#39; corresponding to the allocation,<br /> therefore double-allocating the first half (2KiB slot) of the 4KiB page.<br /> <br /> Fix the problem by treating the allocation alignment separately to any<br /> additional alignment requirements from the device, using the maximum<br /> of the two as the stride to search the buffer slots and taking care<br /> to ensure a minimum of page-alignment for buffers larger than a page.<br /> <br /> This also resolves swiotlb allocation failures occuring due to the<br /> inclusion of ~PAGE_MASK in &amp;#39;iotlb_align_mask&amp;#39; for large allocations and<br /> resulting in alignment requirements exceeding swiotlb_max_mapping_size().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach<br /> <br /> This is the candidate patch of CVE-2023-47233 :<br /> https://nvd.nist.gov/vuln/detail/CVE-2023-47233<br /> <br /> In brcm80211 driver,it starts with the following invoking chain<br /> to start init a timeout worker:<br /> <br /> -&gt;brcmf_usb_probe<br /> -&gt;brcmf_usb_probe_cb<br /> -&gt;brcmf_attach<br /> -&gt;brcmf_bus_started<br /> -&gt;brcmf_cfg80211_attach<br /> -&gt;wl_init_priv<br /> -&gt;brcmf_init_escan<br /> -&gt;INIT_WORK(&amp;cfg-&gt;escan_timeout_work,<br /> brcmf_cfg80211_escan_timeout_worker);<br /> <br /> If we disconnect the USB by hotplug, it will call<br /> brcmf_usb_disconnect to make cleanup. The invoking chain is :<br /> <br /> brcmf_usb_disconnect<br /> -&gt;brcmf_usb_disconnect_cb<br /> -&gt;brcmf_detach<br /> -&gt;brcmf_cfg80211_detach<br /> -&gt;kfree(cfg);<br /> <br /> While the timeout woker may still be running. This will cause<br /> a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.<br /> <br /> Fix it by deleting the timer and canceling the worker in<br /> brcmf_cfg80211_detach.<br /> <br /> [arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: core: Avoid negative index with array access<br /> <br /> Commit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") assigns<br /> prev_idata = idatas[i - 1], but doesn&amp;#39;t check that the iterator i is<br /> greater than zero. Let&amp;#39;s fix this by adding a check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: fsl: qbman: Always disable interrupts when taking cgr_lock<br /> <br /> smp_call_function_single disables IRQs when executing the callback. To<br /> prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.<br /> This is already done by qman_update_cgr and qman_delete_cgr; fix the<br /> other lockers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/dm-raid: don&amp;#39;t call md_reap_sync_thread() directly<br /> <br /> Currently md_reap_sync_thread() is called from raid_message() directly<br /> without holding &amp;#39;reconfig_mutex&amp;#39;, this is definitely unsafe because<br /> md_reap_sync_thread() can change many fields that is protected by<br /> &amp;#39;reconfig_mutex&amp;#39;.<br /> <br /> However, hold &amp;#39;reconfig_mutex&amp;#39; here is still problematic because this<br /> will cause deadlock, for example, commit 130443d60b1b ("md: refactor<br /> idle/frozen_sync_thread() to fix deadlock").<br /> <br /> Fix this problem by using stop_sync_thread() to unregister sync_thread,<br /> like md/raid did.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Fix the lifetime of the bo cursor memory<br /> <br /> The cleanup can be dispatched while the atomic update is still active,<br /> which means that the memory acquired in the atomic update needs to<br /> not be invalidated by the cleanup. The buffer objects in vmw_plane_state<br /> instead of using the builtin map_and_cache were trying to handle<br /> the lifetime of the mapped memory themselves, leading to crashes.<br /> <br /> Use the map_and_cache instead of trying to manage the lifetime of the<br /> buffer objects held by the vmw_plane_state.<br /> <br /> Fixes kernel oops&amp;#39;es in IGT&amp;#39;s kms_cursor_legacy forked-bo.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/PM: Drain runtime-idle callbacks before driver removal<br /> <br /> A race condition between the .runtime_idle() callback and the .remove()<br /> callback in the rtsx_pcr PCI driver leads to a kernel crash due to an<br /> unhandled page fault [1].<br /> <br /> The problem is that rtsx_pci_runtime_idle() is not expected to be running<br /> after pm_runtime_get_sync() has been called, but the latter doesn&amp;#39;t really<br /> guarantee that. It only guarantees that the suspend and resume callbacks<br /> will not be running when it returns.<br /> <br /> However, if a .runtime_idle() callback is already running when<br /> pm_runtime_get_sync() is called, the latter will notice that the runtime PM<br /> status of the device is RPM_ACTIVE and it will return right away without<br /> waiting for the former to complete. In fact, it cannot wait for<br /> .runtime_idle() to complete because it may be called from that callback (it<br /> arguably does not make much sense to do that, but it is not strictly<br /> prohibited).<br /> <br /> Thus in general, whoever is providing a .runtime_idle() callback needs<br /> to protect it from running in parallel with whatever code runs after<br /> pm_runtime_get_sync(). [Note that .runtime_idle() will not start after<br /> pm_runtime_get_sync() has returned, but it may continue running then if it<br /> has started earlier.]<br /> <br /> One way to address that race condition is to call pm_runtime_barrier()<br /> after pm_runtime_get_sync() (not before it, because a nonzero value of the<br /> runtime PM usage counter is necessary to prevent runtime PM callbacks from<br /> being invoked) to wait for the .runtime_idle() callback to complete should<br /> it be running at that point. A suitable place for doing that is in<br /> pci_device_remove() which calls pm_runtime_get_sync() before removing the<br /> driver, so it may as well call pm_runtime_barrier() subsequently, which<br /> will prevent the race in question from occurring, not just in the rtsx_pcr<br /> driver, but in any PCI drivers providing .runtime_idle() callbacks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix corruption during on-line resize<br /> <br /> We observed a corruption during on-line resize of a file system that is<br /> larger than 16 TiB with 4k block size. With having more then 2^32 blocks<br /> resize_inode is turned off by default by mke2fs. The issue can be<br /> reproduced on a smaller file system for convenience by explicitly<br /> turning off resize_inode. An on-line resize across an 8 GiB boundary (the<br /> size of a meta block group in this setup) then leads to a corruption:<br /> <br /> dev=/dev/ # should be &gt;= 16 GiB<br /> mkdir -p /corruption<br /> /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15))<br /> mount -t ext4 $dev /corruption<br /> <br /> dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15))<br /> sha1sum /corruption/test<br /> # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test<br /> <br /> /sbin/resize2fs $dev $((2*2**21))<br /> # drop page cache to force reload the block from disk<br /> echo 1 &gt; /proc/sys/vm/drop_caches<br /> <br /> sha1sum /corruption/test<br /> # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test<br /> <br /> 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per<br /> block group and 2^6 are the number of block groups that make a meta<br /> block group.<br /> <br /> The last checksum might be different depending on how the file is laid<br /> out across the physical blocks. The actual corruption occurs at physical<br /> block 63*2^15 = 2064384 which would be the location of the backup of the<br /> meta block group&amp;#39;s block descriptor. During the on-line resize the file<br /> system will be converted to meta_bg starting at s_first_meta_bg which is<br /> 2 in the example - meaning all block groups after 16 GiB. However, in<br /> ext4_flex_group_add we might add block groups that are not part of the<br /> first meta block group yet. In the reproducer we achieved this by<br /> substracting the size of a whole block group from the point where the<br /> meta block group would start. This must be considered when updating the<br /> backup block group descriptors to follow the non-meta_bg layout. The fix<br /> is to add a test whether the group to add is already part of the meta<br /> block group or not.

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 /> x86/efistub: Call mixed mode boot services on the firmware&amp;#39;s stack<br /> <br /> Normally, the EFI stub calls into the EFI boot services using the stack<br /> that was live when the stub was entered. According to the UEFI spec,<br /> this stack needs to be at least 128k in size - this might seem large but<br /> all asynchronous processing and event handling in EFI runs from the same<br /> stack and so quite a lot of space may be used in practice.<br /> <br /> In mixed mode, the situation is a bit different: the bootloader calls<br /> the 32-bit EFI stub entry point, which calls the decompressor&amp;#39;s 32-bit<br /> entry point, where the boot stack is set up, using a fixed allocation<br /> of 16k. This stack is still in use when the EFI stub is started in<br /> 64-bit mode, and so all calls back into the EFI firmware will be using<br /> the decompressor&amp;#39;s limited boot stack.<br /> <br /> Due to the placement of the boot stack right after the boot heap, any<br /> stack overruns have gone unnoticed. However, commit<br /> <br /> 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code")<br /> <br /> moved the definition of the boot heap into C code, and now the boot<br /> stack is placed right at the base of BSS, where any overruns will<br /> corrupt the end of the .data section.<br /> <br /> While it would be possible to work around this by increasing the size of<br /> the boot stack, doing so would affect all x86 systems, and mixed mode<br /> systems are a tiny (and shrinking) fraction of the x86 installed base.<br /> <br /> So instead, record the firmware stack pointer value when entering from<br /> the 32-bit firmware, and switch to this stack every time a EFI boot<br /> service call is made.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Mark target gfn of emulated atomic instruction as dirty<br /> <br /> When emulating an atomic access on behalf of the guest, mark the target<br /> gfn dirty if the CMPXCHG by KVM is attempted and doesn&amp;#39;t fault. This<br /> fixes a bug where KVM effectively corrupts guest memory during live<br /> migration by writing to guest memory without informing userspace that the<br /> page is dirty.<br /> <br /> Marking the page dirty got unintentionally dropped when KVM&amp;#39;s emulated<br /> CMPXCHG was converted to do a user access. Before that, KVM explicitly<br /> mapped the guest page into kernel memory, and marked the page dirty during<br /> the unmap phase.<br /> <br /> Mark the page dirty even if the CMPXCHG fails, as the old data is written<br /> back on failure, i.e. the page is still written. The value written is<br /> guaranteed to be the same because the operation is atomic, but KVM&amp;#39;s ABI<br /> is that all writes are dirty logged regardless of the value written. And<br /> more importantly, that&amp;#39;s what KVM did before the buggy commit.<br /> <br /> Huge kudos to the folks on the Cc list (and many others), who did all the<br /> actual work of triaging and debugging.<br /> <br /> base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm snapshot: fix lockup in dm_exception_table_exit<br /> <br /> There was reported lockup when we exit a snapshot with many exceptions.<br /> Fix this by adding "cond_resched" to the loop that frees the exceptions.