Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()<br /> <br /> In the for statement of lbs_allocate_cmd_buffer(), if the allocation of<br /> cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to<br /> be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: ncm: Fix handling of zero block length packets<br /> <br /> While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX<br /> set to 65536, it has been observed that we receive short packets,<br /> which come at interval of 5-10 seconds sometimes and have block<br /> length zero but still contain 1-2 valid datagrams present.<br /> <br /> According to the NCM spec:<br /> <br /> "If wBlockLength = 0x0000, the block is terminated by a<br /> short packet. In this case, the USB transfer must still<br /> be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If<br /> exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,<br /> and the size is a multiple of wMaxPacketSize for the<br /> given pipe, then no ZLP shall be sent.<br /> <br /> wBlockLength= 0x0000 must be used with extreme care, because<br /> of the possibility that the host and device may get out of<br /> sync, and because of test issues.<br /> <br /> wBlockLength = 0x0000 allows the sender to reduce latency by<br /> starting to send a very large NTB, and then shortening it when<br /> the sender discovers that there’s not sufficient data to justify<br /> sending a large NTB"<br /> <br /> However, there is a potential issue with the current implementation,<br /> as it checks for the occurrence of multiple NTBs in a single<br /> giveback by verifying if the leftover bytes to be processed is zero<br /> or not. If the block length reads zero, we would process the same<br /> NTB infintely because the leftover bytes is never zero and it leads<br /> to a crash. Fix this by bailing out if block length reads zero.

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 /> vt: fix unicode buffer corruption when deleting characters<br /> <br /> This is the same issue that was fixed for the VGA text buffer in commit<br /> 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the<br /> buffer"). The cure is also the same i.e. replace memcpy() with memmove()<br /> due to the overlaping buffers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Set page uptodate in the correct place<br /> <br /> Page cache reads are lockless, so setting the freshly allocated page<br /> uptodate before we&amp;#39;ve overwritten it with the data it&amp;#39;s supposed to have<br /> in it will allow a simultaneous reader to see old data. Move the call<br /> to SetPageUptodate into ubifs_write_end(), which is after we copied the<br /> new data into the page.

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]