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.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

The Avada | Website Builder For WordPress &amp; eCommerce plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin&amp;#39;s fusion_button shortcode in all versions up to, and including, 3.11.9 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. NOTE: This vulnerability was partially fixed in 3.11.9. Additional hardening for alternate attack vectors was added to version 3.11.10.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: avoid using null object of framebuffer<br /> <br /> Instead of using state-&gt;fb-&gt;obj[0] directly, get object from framebuffer<br /> by calling drm_gem_fb_get_obj() and return error code when object is<br /> null to avoid using null object of framebuffer.<br /> <br /> (cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux,smack: don&amp;#39;t bypass permissions check in inode_setsecctx hook<br /> <br /> Marek Gresko reports that the root user on an NFS client is able to<br /> change the security labels on files on an NFS filesystem that is<br /> exported with root squashing enabled.<br /> <br /> The end of the kerneldoc comment for __vfs_setxattr_noperm() states:<br /> <br /> * This function requires the caller to lock the inode&amp;#39;s i_mutex before it<br /> * is executed. It also assumes that the caller will make the appropriate<br /> * permission checks.<br /> <br /> nfsd_setattr() does do permissions checking via fh_verify() and<br /> nfsd_permission(), but those don&amp;#39;t do all the same permissions checks<br /> that are done by security_inode_setxattr() and its related LSM hooks do.<br /> <br /> Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),<br /> simplest solution appears to be to replace the call to<br /> __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This<br /> fixes the above issue and has the added benefit of causing nfsd to<br /> recall conflicting delegations on a file when a client tries to change<br /> its security label.

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