Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: Fix page refcounts for unaligned buffers in __bio_release_pages()<br /> <br /> Fix an incorrect number of pages being released for buffers that do not<br /> start at the beginning of a page.

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 /> io_uring/net: fix overflow check in io_recvmsg_mshot_prep()<br /> <br /> The "controllen" variable is type size_t (unsigned long). Casting it<br /> to int could lead to an integer underflow.<br /> <br /> The check_add_overflow() function considers the type of the destination<br /> which is type int. If we add two positive values and the result cannot<br /> fit in an integer then that&amp;#39;s counted as an overflow.<br /> <br /> However, if we cast "controllen" to an int and it turns negative, then<br /> negative values *can* fit into an int type so there is no overflow.<br /> <br /> Good: 100 + (unsigned long)-4 = 96

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