Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: udc: remove warning when queue disabled ep<br /> <br /> It is possible trigger below warning message from mass storage function,<br /> <br /> WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104<br /> pc : usb_ep_queue+0x7c/0x104<br /> lr : fsg_main_thread+0x494/0x1b3c<br /> <br /> Root cause is mass storage function try to queue request from main thread,<br /> but other thread may already disable ep when function disable.<br /> <br /> As there is no function failure in the driver, in order to avoid effort<br /> to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: ohci: prevent leak of left-over IRQ on unbind<br /> <br /> Commit 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ")<br /> also removed the call to free_irq() in pci_remove(), leading to a<br /> leftover irq of devm_request_irq() at pci_disable_msi() in pci_remove()<br /> when unbinding the driver from the device<br /> <br /> remove_proc_entry: removing non-empty directory &amp;#39;irq/136&amp;#39;, leaking at<br /> least &amp;#39;firewire_ohci&amp;#39;<br /> Call Trace:<br /> ? remove_proc_entry+0x19c/0x1c0<br /> ? __warn+0x81/0x130<br /> ? remove_proc_entry+0x19c/0x1c0<br /> ? report_bug+0x171/0x1a0<br /> ? console_unlock+0x78/0x120<br /> ? handle_bug+0x3c/0x80<br /> ? exc_invalid_op+0x17/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? remove_proc_entry+0x19c/0x1c0<br /> unregister_irq_proc+0xf4/0x120<br /> free_desc+0x3d/0xe0<br /> ? kfree+0x29f/0x2f0<br /> irq_free_descs+0x47/0x70<br /> msi_domain_free_locked.part.0+0x19d/0x1d0<br /> msi_domain_free_irqs_all_locked+0x81/0xc0<br /> pci_free_msi_irqs+0x12/0x40<br /> pci_disable_msi+0x4c/0x60<br /> pci_remove+0x9d/0xc0 [firewire_ohci<br /> 01b483699bebf9cb07a3d69df0aa2bee71db1b26]<br /> pci_device_remove+0x37/0xa0<br /> device_release_driver_internal+0x19f/0x200<br /> unbind_store+0xa1/0xb0<br /> <br /> remove irq with devm_free_irq() before pci_disable_msi()<br /> also remove it in fail_msi: of pci_probe() as this would lead to<br /> an identical leak

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag<br /> <br /> Otherwise after the GTT bo is released, the GTT and gart space is freed<br /> but amdgpu_ttm_backend_unbind will not clear the gart page table entry<br /> and leave valid mapping entry pointing to the stale system page. Then<br /> if GPU access the gart address mistakely, it will read undefined value<br /> instead page fault, harder to debug and reproduce the real issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Define the __io_aw() hook as mmiowb()<br /> <br /> Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of<br /> mmiowb()") remove all mmiowb() in drivers, but it says:<br /> <br /> "NOTE: mmiowb() has only ever guaranteed ordering in conjunction with<br /> spin_unlock(). However, pairing each mmiowb() removal in this patch with<br /> the corresponding call to spin_unlock() is not at all trivial, so there<br /> is a small chance that this change may regress any drivers incorrectly<br /> relying on mmiowb() to order MMIO writes between CPUs using lock-free<br /> synchronisation."<br /> <br /> The mmio in radeon_ring_commit() is protected by a mutex rather than a<br /> spinlock, but in the mutex fastpath it behaves similar to spinlock. We<br /> can add mmiowb() calls in the radeon driver but the maintainer says he<br /> doesn&amp;#39;t like such a workaround, and radeon is not the only example of<br /> mutex protected mmio.<br /> <br /> So we should extend the mmiowb tracking system from spinlock to mutex,<br /> and maybe other locking primitives. This is not easy and error prone, so<br /> we solve it in the architectural code, by simply defining the __io_aw()<br /> hook as mmiowb(). And we no longer need to override queued_spin_unlock()<br /> so use the generic definition.<br /> <br /> Without this, we get such an error when run &amp;#39;glxgears&amp;#39; on weak ordering<br /> architectures such as LoongArch:<br /> <br /> radeon 0000:04:00.0: ring 0 stalled for more than 10324msec<br /> radeon 0000:04:00.0: ring 3 stalled for more than 10240msec<br /> radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3)<br /> radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0)<br /> radeon 0000:04:00.0: scheduling IB failed (-35).<br /> [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&amp;#39;t update BO_VA (-35)<br /> radeon 0000:04:00.0: scheduling IB failed (-35).<br /> [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&amp;#39;t update BO_VA (-35)<br /> radeon 0000:04:00.0: scheduling IB failed (-35).<br /> [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&amp;#39;t update BO_VA (-35)<br /> radeon 0000:04:00.0: scheduling IB failed (-35).<br /> [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&amp;#39;t update BO_VA (-35)<br /> radeon 0000:04:00.0: scheduling IB failed (-35).<br /> [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&amp;#39;t update BO_VA (-35)<br /> radeon 0000:04:00.0: scheduling IB failed (-35).<br /> [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&amp;#39;t update BO_VA (-35)<br /> radeon 0000:04:00.0: scheduling IB failed (-35).<br /> [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&amp;#39;t update BO_VA (-35)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion<br /> <br /> The first kiocb_set_cancel_fn() argument may point at a struct kiocb<br /> that is not embedded inside struct aio_kiocb. With the current code,<br /> depending on the compiler, the req-&gt;ki_ctx read happens either before<br /> the IOCB_AIO_RW test or after that test. Move the req-&gt;ki_ctx read such<br /> that it is guaranteed that the IOCB_AIO_RW test happens first.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: fsl: qbman: Use raw spinlock for cgr_lock<br /> <br /> smp_call_function always runs its callback in hard IRQ context, even on<br /> PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock<br /> for cgr_lock to ensure we aren&amp;#39;t waiting on a sleeping task.<br /> <br /> Although this bug has existed for a while, it was not apparent until<br /> commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change")<br /> which invokes smp_call_function_single via qman_update_cgr_safe every<br /> time a link goes up or down.

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]

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