Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Disable preemption while updating GPU stats<br /> <br /> We forgot to disable preemption around the write_seqcount_begin/end() pair<br /> while updating GPU stats:<br /> <br /> [ ] WARNING: CPU: 2 PID: 12 at include/linux/seqlock.h:221 __seqprop_assert.isra.0+0x128/0x150 [v3d]<br /> [ ] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched]<br /> <br /> [ ] Call trace:<br /> [ ] __seqprop_assert.isra.0+0x128/0x150 [v3d]<br /> [ ] v3d_job_start_stats.isra.0+0x90/0x218 [v3d]<br /> [ ] v3d_bin_job_run+0x23c/0x388 [v3d]<br /> [ ] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched]<br /> [ ] process_one_work+0x62c/0xb48<br /> [ ] worker_thread+0x468/0x5b0<br /> [ ] kthread+0x1c4/0x1e0<br /> [ ] ret_from_fork+0x10/0x20<br /> <br /> Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/mes: fix mes ring buffer overflow<br /> <br /> wait memory room until enough before writing mes packets<br /> to avoid ring buffer overflow.<br /> <br /> v2: squash in sched_hw_submission fix<br /> <br /> (cherry picked from commit 34e087e8920e635c62e2ed6a758b0cd27f836d13)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_elf_fdpic: fix AUXV size calculation when ELF_HWCAP2 is defined<br /> <br /> create_elf_fdpic_tables() does not correctly account the space for the<br /> AUX vector when an architecture has ELF_HWCAP2 defined. Prior to the<br /> commit 10e29251be0e ("binfmt_elf_fdpic: fix /proc//auxv") it<br /> resulted in the last entry of the AUX vector being set to zero, but with<br /> that change it results in a kernel BUG.<br /> <br /> Fix that by adding one to the number of AUXV entries (nitems) when<br /> ELF_HWCAP2 is defined.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix out-of-bound access when z_erofs_gbuf_growsize() partially fails<br /> <br /> If z_erofs_gbuf_growsize() partially fails on a global buffer due to<br /> memory allocation failure or fault injection (as reported by syzbot [1]),<br /> new pages need to be freed by comparing to the existing pages to avoid<br /> memory leaks.<br /> <br /> However, the old gbuf-&gt;pages[] array may not be large enough, which can<br /> lead to null-ptr-deref or out-of-bound access.<br /> <br /> Fix this by checking against gbuf-&gt;nrpages in advance.<br /> <br /> [1] https://lore.kernel.org/r/000000000000f7b96e062018c6e3@google.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: cmd-db: Map shared memory as WC, not WB<br /> <br /> Linux does not write into cmd-db region. This region of memory is write<br /> protected by XPU. XPU may sometime falsely detect clean cache eviction<br /> as "write" into the write protected region leading to secure interrupt<br /> which causes an endless loop somewhere in Trust Zone.<br /> <br /> The only reason it is working right now is because Qualcomm Hypervisor<br /> maps the same region as Non-Cacheable memory in Stage 2 translation<br /> tables. The issue manifests if we want to use another hypervisor (like<br /> Xen or KVM), which does not know anything about those specific mappings.<br /> <br /> Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC<br /> removes dependency on correct mappings in Stage 2 tables. This patch<br /> fixes the issue by updating the mapping to MEMREMAP_WC.<br /> <br /> I tested this on SA8155P with Xen.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix nfsd4_deleg_getattr_conflict in presence of third party lease<br /> <br /> It is not safe to dereference fl-&gt;c.flc_owner without first confirming<br /> fl-&gt;fl_lmops is the expected manager. nfsd4_deleg_getattr_conflict()<br /> tests fl_lmops but largely ignores the result and assumes that flc_owner<br /> is an nfs4_delegation anyway. This is wrong.<br /> <br /> With this patch we restore the "!= &amp;nfsd_lease_mng_ops" case to behave<br /> as it did before the change mentioned below. This is the same as the<br /> current code, but without any reference to a possible delegation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: Move unregister out of atomic section<br /> <br /> Commit &amp;#39;9329933699b3 ("soc: qcom: pmic_glink: Make client-lock<br /> non-sleeping")&amp;#39; moved the pmic_glink client list under a spinlock, as it<br /> is accessed by the rpmsg/glink callback, which in turn is invoked from<br /> IRQ context.<br /> <br /> This means that ucsi_unregister() is now called from atomic context,<br /> which isn&amp;#39;t feasible as it&amp;#39;s expecting a sleepable context. An effort is<br /> under way to get GLINK to invoke its callbacks in a sleepable context,<br /> but until then lets schedule the unregistration.<br /> <br /> A side effect of this is that ucsi_unregister() can now happen<br /> after the remote processor, and thereby the communication link with it, is<br /> gone. pmic_glink_send() is amended with a check to avoid the resulting NULL<br /> pointer dereference.<br /> This does however result in the user being informed about this error by<br /> the following entry in the kernel log:<br /> <br /> ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI write request: -5

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: single: fix potential NULL dereference in pcs_get_function()<br /> <br /> pinmux_generic_get_function() can return NULL and the pointer &amp;#39;function&amp;#39;<br /> was dereferenced without checking against NULL. Add checking of pointer<br /> &amp;#39;function&amp;#39; in pcs_get_function().<br /> <br /> Found by code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()<br /> <br /> This happens when called from SMB2_read() while using rdma<br /> and reaching the rdma_readwrite_threshold.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk()<br /> <br /> [BUG]<br /> There is an internal report that KASAN is reporting use-after-free, with<br /> the following backtrace:<br /> <br /> BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs]<br /> Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45<br /> CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014<br /> Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]<br /> Call Trace:<br /> dump_stack_lvl+0x61/0x80<br /> print_address_description.constprop.0+0x5e/0x2f0<br /> print_report+0x118/0x216<br /> kasan_report+0x11d/0x1f0<br /> btrfs_check_read_bio+0xa68/0xb70 [btrfs]<br /> process_one_work+0xce0/0x12a0<br /> worker_thread+0x717/0x1250<br /> kthread+0x2e3/0x3c0<br /> ret_from_fork+0x2d/0x70<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Allocated by task 20917:<br /> kasan_save_stack+0x37/0x60<br /> kasan_save_track+0x10/0x30<br /> __kasan_slab_alloc+0x7d/0x80<br /> kmem_cache_alloc_noprof+0x16e/0x3e0<br /> mempool_alloc_noprof+0x12e/0x310<br /> bio_alloc_bioset+0x3f0/0x7a0<br /> btrfs_bio_alloc+0x2e/0x50 [btrfs]<br /> submit_extent_page+0x4d1/0xdb0 [btrfs]<br /> btrfs_do_readpage+0x8b4/0x12a0 [btrfs]<br /> btrfs_readahead+0x29a/0x430 [btrfs]<br /> read_pages+0x1a7/0xc60<br /> page_cache_ra_unbounded+0x2ad/0x560<br /> filemap_get_pages+0x629/0xa20<br /> filemap_read+0x335/0xbf0<br /> vfs_read+0x790/0xcb0<br /> ksys_read+0xfd/0x1d0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Freed by task 20917:<br /> kasan_save_stack+0x37/0x60<br /> kasan_save_track+0x10/0x30<br /> kasan_save_free_info+0x37/0x50<br /> __kasan_slab_free+0x4b/0x60<br /> kmem_cache_free+0x214/0x5d0<br /> bio_free+0xed/0x180<br /> end_bbio_data_read+0x1cc/0x580 [btrfs]<br /> btrfs_submit_chunk+0x98d/0x1880 [btrfs]<br /> btrfs_submit_bio+0x33/0x70 [btrfs]<br /> submit_one_bio+0xd4/0x130 [btrfs]<br /> submit_extent_page+0x3ea/0xdb0 [btrfs]<br /> btrfs_do_readpage+0x8b4/0x12a0 [btrfs]<br /> btrfs_readahead+0x29a/0x430 [btrfs]<br /> read_pages+0x1a7/0xc60<br /> page_cache_ra_unbounded+0x2ad/0x560<br /> filemap_get_pages+0x629/0xa20<br /> filemap_read+0x335/0xbf0<br /> vfs_read+0x790/0xcb0<br /> ksys_read+0xfd/0x1d0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> [CAUSE]<br /> Although I cannot reproduce the error, the report itself is good enough<br /> to pin down the cause.<br /> <br /> The call trace is the regular endio workqueue context, but the<br /> free-by-task trace is showing that during btrfs_submit_chunk() we<br /> already hit a critical error, and is calling btrfs_bio_end_io() to error<br /> out. And the original endio function called bio_put() to free the whole<br /> bio.<br /> <br /> This means a double freeing thus causing use-after-free, e.g.:<br /> <br /> 1. Enter btrfs_submit_bio() with a read bio<br /> The read bio length is 128K, crossing two 64K stripes.<br /> <br /> 2. The first run of btrfs_submit_chunk()<br /> <br /> 2.1 Call btrfs_map_block(), which returns 64K<br /> 2.2 Call btrfs_split_bio()<br /> Now there are two bios, one referring to the first 64K, the other<br /> referring to the second 64K.<br /> 2.3 The first half is submitted.<br /> <br /> 3. The second run of btrfs_submit_chunk()<br /> <br /> 3.1 Call btrfs_map_block(), which by somehow failed<br /> Now we call btrfs_bio_end_io() to handle the error<br /> <br /> 3.2 btrfs_bio_end_io() calls the original endio function<br /> Which is end_bbio_data_read(), and it calls bio_put() for the<br /> original bio.<br /> <br /> Now the original bio is freed.<br /> <br /> 4. The submitted first 64K bio finished<br /> Now we call into btrfs_check_read_bio() and tries to advance the bio<br /> iter.<br /> But since the original bio (thus its iter) is already freed, we<br /> trigger the above use-after free.<br /> <br /> And even if the memory is not poisoned/corrupted, we will later call<br /> the original endio function, causing a double freeing.<br /> <br /> [FIX]<br /> Instead of calling btrfs_bio_end_io(), call btrfs_orig_bbio_end_io(),<br /> which has the extra check on split bios and do the pr<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: core: Prevent USB core invalid event buffer address access<br /> <br /> This commit addresses an issue where the USB core could access an<br /> invalid event buffer address during runtime suspend, potentially causing<br /> SMMU faults and other memory issues in Exynos platforms. The problem<br /> arises from the following sequence.<br /> 1. In dwc3_gadget_suspend, there is a chance of a timeout when<br /> moving the USB core to the halt state after clearing the<br /> run/stop bit by software.<br /> 2. In dwc3_core_exit, the event buffer is cleared regardless of<br /> the USB core&amp;#39;s status, which may lead to an SMMU faults and<br /> other memory issues. if the USB core tries to access the event<br /> buffer address.<br /> <br /> To prevent this hardware quirk on Exynos platforms, this commit ensures<br /> that the event buffer address is not cleared by software when the USB<br /> core is active during runtime suspend by checking its status before<br /> clearing the buffer address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: pn533: Add poll mod list filling check<br /> <br /> In case of im_protocols value is 1 and tm_protocols value is 0 this<br /> combination successfully passes the check<br /> &amp;#39;if (!im_protocols &amp;&amp; !tm_protocols)&amp;#39; in the nfc_start_poll().<br /> But then after pn533_poll_create_mod_list() call in pn533_start_poll()<br /> poll mod list will remain empty and dev-&gt;poll_mod_count will remain 0<br /> which lead to division by zero.<br /> <br /> Normally no im protocol has value 1 in the mask, so this combination is<br /> not expected by driver. But these protocol values actually come from<br /> userspace via Netlink interface (NFC_CMD_START_POLL operation). So a<br /> broken or malicious program may pass a message containing a "bad"<br /> combination of protocol parameter values so that dev-&gt;poll_mod_count<br /> is not incremented inside pn533_poll_create_mod_list(), thus leading<br /> to division by zero.<br /> Call trace looks like:<br /> nfc_genl_start_poll()<br /> nfc_start_poll()<br /> -&gt;start_poll()<br /> pn533_start_poll()<br /> <br /> Add poll mod list filling check.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.