Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-verity: correctly handle dm_bufio_client_create() failure<br /> <br /> If either of the calls to dm_bufio_client_create() in verity_fec_ctr()<br /> fails, then dm_bufio_client_destroy() is later called with an ERR_PTR()<br /> argument. That causes a crash. Fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Fix null pointer dereference issue<br /> <br /> If SMU is disabled, during RAS initialization,<br /> there will be null pointer dereference issue here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode<br /> <br /> Commit 4fc82cd907ac ("iommu/vt-d: Don&amp;#39;t issue ATS Invalidation<br /> request when device is disconnected") relies on<br /> pci_dev_is_disconnected() to skip ATS invalidation for<br /> safely-removed devices, but it does not cover link-down caused<br /> by faults, which can still hard-lock the system.<br /> <br /> For example, if a VM fails to connect to the PCIe device,<br /> "virsh destroy" is executed to release resources and isolate<br /> the fault, but a hard-lockup occurs while releasing the group fd.<br /> <br /> Call Trace:<br /> qi_submit_sync<br /> qi_flush_dev_iotlb<br /> intel_pasid_tear_down_entry<br /> device_block_translation<br /> blocking_domain_attach_dev<br /> __iommu_attach_device<br /> __iommu_device_set_domain<br /> __iommu_group_set_domain_internal<br /> iommu_detach_group<br /> vfio_iommu_type1_detach_group<br /> vfio_group_detach_container<br /> vfio_group_fops_release<br /> __fput<br /> <br /> Although pci_device_is_present() is slower than<br /> pci_dev_is_disconnected(), it still takes only ~70 µs on a<br /> ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed<br /> and width increase.<br /> <br /> Besides, devtlb_invalidation_with_pasid() is called only in the<br /> paths below, which are far less frequent than memory map/unmap.<br /> <br /> 1. mm-struct release<br /> 2. {attach,release}_dev<br /> 3. set/remove PASID<br /> 4. dirty-tracking setup<br /> <br /> The gain in system stability far outweighs the negligible cost<br /> of using pci_device_is_present() instead of pci_dev_is_disconnected()<br /> to decide when to skip ATS invalidation, especially under GDR<br /> high-load conditions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ<br /> <br /> This adds a check for encryption key size upon receiving<br /> L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which<br /> expects L2CAP_CR_LE_BAD_KEY_SIZE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx23885: Add missing unmap in snd_cx23885_hw_params()<br /> <br /> In error path, add cx23885_alsa_dma_unmap() to release the<br /> resource acquired by cx23885_alsa_dma_map().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: logitech-hidpp: Check maxfield in hidpp_get_report_length()<br /> <br /> Do not crash when a report has no fields.<br /> <br /> Fake USB gadgets can send their own HID report descriptors and can define report<br /> structures without valid fields. This can be used to crash the kernel over USB.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/umem: Fix double dma_buf_unpin in failure path<br /> <br /> In ib_umem_dmabuf_get_pinned_with_dma_device(), the call to<br /> ib_umem_dmabuf_map_pages() can fail. If this occurs, the dmabuf<br /> is immediately unpinned but the umem_dmabuf-&gt;pinned flag is still<br /> set. Then, when ib_umem_release() is called, it calls<br /> ib_umem_dmabuf_revoke() which will call dma_buf_unpin() again.<br /> <br /> Fix this by removing the immediate unpin upon failure and just let<br /> the ib_umem_release/revoke path handle it. This also ensures the<br /> proper unmap-unpin unwind ordering if the dmabuf_map_pages call<br /> happened to fail due to dma_resv_wait_timeout (and therefore has<br /> a non-NULL umem_dmabuf-&gt;sgt).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: fix circular locking dependency in run_unpack_ex<br /> <br /> Syzbot reported a circular locking dependency between wnd-&gt;rw_lock<br /> (sbi-&gt;used.bitmap) and ni-&gt;file.run_lock.<br /> <br /> The deadlock scenario:<br /> 1. ntfs_extend_mft() takes ni-&gt;file.run_lock then wnd-&gt;rw_lock.<br /> 2. run_unpack_ex() takes wnd-&gt;rw_lock then tries to acquire<br /> ni-&gt;file.run_lock inside ntfs_refresh_zone().<br /> <br /> This creates an AB-BA deadlock.<br /> <br /> Fix this by using down_read_trylock() instead of down_read() when<br /> acquiring run_lock in run_unpack_ex(). If the lock is contended,<br /> skip ntfs_refresh_zone() - the MFT zone will be refreshed on the<br /> next MFT operation. This breaks the circular dependency since we<br /> never block waiting for run_lock while holding wnd-&gt;rw_lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: mixer: oss: Add card disconnect checkpoints<br /> <br /> ALSA OSS mixer layer calls the kcontrol ops rather individually, and<br /> pending calls might be not always caught at disconnecting the device.<br /> <br /> For avoiding the potential UAF scenarios, add sanity checks of the<br /> card disconnection at each entry point of OSS mixer accesses. The<br /> rwsem is taken just before that check, hence the rest context should<br /> be covered by that properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dlm: validate length in dlm_search_rsb_tree<br /> <br /> The len parameter in dlm_dump_rsb_name() is not validated and comes<br /> from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can<br /> cause out-of-bounds write in dlm_search_rsb_tree().<br /> <br /> Add length validation to prevent potential buffer overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore: ram_core: fix incorrect success return when vmap() fails<br /> <br /> In persistent_ram_vmap(), vmap() may return NULL on failure.<br /> <br /> If offset is non-zero, adding offset_in_page(start) causes the function<br /> to return a non-NULL pointer even though the mapping failed.<br /> persistent_ram_buffer_map() therefore incorrectly returns success.<br /> <br /> Subsequent access to prz-&gt;buffer may dereference an invalid address<br /> and cause crashes.<br /> <br /> Add proper NULL checking for vmap() failures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: verify the previous kernel&amp;#39;s IMA buffer lies in addressable RAM<br /> <br /> Patch series "Address page fault in ima_restore_measurement_list()", v3.<br /> <br /> When the second-stage kernel is booted via kexec with a limiting command<br /> line such as "mem=" we observe a pafe fault that happens.<br /> <br /> BUG: unable to handle page fault for address: ffff97793ff47000<br /> RIP: ima_restore_measurement_list+0xdc/0x45a<br /> #PF: error_code(0x0000) not-present page<br /> <br /> This happens on x86_64 only, as this is already fixed in aarch64 in<br /> commit: cbf9c4b9617b ("of: check previous kernel&amp;#39;s ima-kexec-buffer<br /> against memory bounds")<br /> <br /> <br /> This patch (of 3):<br /> <br /> When the second-stage kernel is booted with a limiting command line (e.g. <br /> "mem="), the IMA measurement buffer handed over from the previous<br /> kernel may fall outside the addressable RAM of the new kernel. Accessing<br /> such a buffer can fault during early restore.<br /> <br /> Introduce a small generic helper, ima_validate_range(), which verifies<br /> that a physical [start, end] range for the previous-kernel IMA buffer lies<br /> within addressable memory:<br /> - On x86, use pfn_range_is_mapped().<br /> - On OF based architectures, use page_is_ram().