Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix infinite loop when replaying fast_commit<br /> <br /> When doing fast_commit replay an infinite loop may occur due to an<br /> uninitialized extent_status struct. ext4_ext_determine_insert_hole() does<br /> not detect the replay and calls ext4_es_find_extent_range(), which will<br /> return immediately without initializing the &amp;#39;es&amp;#39; variable.<br /> <br /> Because &amp;#39;es&amp;#39; contains garbage, an integer overflow may happen causing an<br /> infinite loop in this function, easily reproducible using fstest generic/039.<br /> <br /> This commit fixes this issue by unconditionally initializing the structure<br /> in function ext4_es_find_extent_range().<br /> <br /> Thanks to Zhang Yi, for figuring out the real problem!

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/qxl: Add check for drm_cvt_mode<br /> <br /> Add check for the return value of drm_cvt_mode() and return the error if<br /> it fails in order to avoid NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> leds: trigger: Unregister sysfs attributes before calling deactivate()<br /> <br /> Triggers which have trigger specific sysfs attributes typically store<br /> related data in trigger-data allocated by the activate() callback and<br /> freed by the deactivate() callback.<br /> <br /> Calling device_remove_groups() after calling deactivate() leaves a window<br /> where the sysfs attributes show/store functions could be called after<br /> deactivation and then operate on the just freed trigger-data.<br /> <br /> Move the device_remove_groups() call to before deactivate() to close<br /> this race window.<br /> <br /> This also makes the deactivation path properly do things in reverse order<br /> of the activation path which calls the activate() callback before calling<br /> device_add_groups().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/uv: Don&amp;#39;t call folio_wait_writeback() without a folio reference<br /> <br /> folio_wait_writeback() requires that no spinlocks are held and that<br /> a folio reference is held, as documented. After we dropped the PTL, the<br /> folio could get freed concurrently. So grab a temporary reference.

The tagDiv Opt-In Builder plugin is vulnerable to Blind SQL Injection via the &amp;#39;subscriptionCouponId&amp;#39; parameter via the &amp;#39;create_stripe_subscription&amp;#39; REST API endpoint in versions up to, and including, 1.4.4 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers with administrator-level privileges to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

The tagDiv Opt-In Builder plugin is vulnerable to Blind SQL Injection via the &amp;#39;couponId&amp;#39; parameter of the &amp;#39;recreate_stripe_subscription&amp;#39; REST API endpoint in versions up to, and including, 1.4.4 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers with administrator-level privileges to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: mxs-dcp - Ensure payload is zero when using key slot<br /> <br /> We could leak stack memory through the payload field when running<br /> AES with a key from one of the hardware&amp;#39;s key slots. Fix this by<br /> ensuring the payload field is set to 0 in such cases.<br /> <br /> This does not affect the common use case when the key is supplied<br /> from main memory via the descriptor payload.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Revise lpfc_prep_embed_io routine with proper endian macro usages<br /> <br /> On big endian architectures, it is possible to run into a memory out of<br /> bounds pointer dereference when FCP targets are zoned.<br /> <br /> In lpfc_prep_embed_io, the memcpy(ptr, fcp_cmnd, sgl-&gt;sge_len) is<br /> referencing a little endian formatted sgl-&gt;sge_len value. So, the memcpy<br /> can cause big endian systems to crash.<br /> <br /> Redefine the *sgl ptr as a struct sli4_sge_le to make it clear that we are<br /> referring to a little endian formatted data structure. And, update the<br /> routine with proper le32_to_cpu macro usages.

The Metform Elementor Contact Form Builder for WordPress is vulnerable to Arbitrary File Upload due to insufficient file type validation in versions up to, and including, 3.2.4. This allows unauthenticated visitors to perform a "double extension" attack and upload files containing a malicious extension but ending with a benign extension, which may make remote code execution possible in some configurations.

A vulnerability was found in LimeSurvey 6.3.0-231016 and classified as problematic. Affected by this issue is some unknown functionality of the file /index.php of the component File Upload. The manipulation of the argument size leads to denial of service. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: avoid PMD-size page cache if needed<br /> <br /> xarray can&amp;#39;t support arbitrary page cache size. the largest and supported<br /> page cache size is defined as MAX_PAGECACHE_ORDER by commit 099d90642a71<br /> ("mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray"). However,<br /> it&amp;#39;s possible to have 512MB page cache in the huge memory&amp;#39;s collapsing<br /> path on ARM64 system whose base page size is 64KB. 512MB page cache is<br /> breaking the limitation and a warning is raised when the xarray entry is<br /> split as shown in the following example.<br /> <br /> [root@dhcp-10-26-1-207 ~]# cat /proc/1/smaps | grep KernelPageSize<br /> KernelPageSize: 64 kB<br /> [root@dhcp-10-26-1-207 ~]# cat /tmp/test.c<br /> :<br /> int main(int argc, char **argv)<br /> {<br /> const char *filename = TEST_XFS_FILENAME;<br /> int fd = 0;<br /> void *buf = (void *)-1, *p;<br /> int pgsize = getpagesize();<br /> int ret = 0;<br /> <br /> if (pgsize != 0x10000) {<br /> fprintf(stdout, "System with 64KB base page size is required!\n");<br /> return -EPERM;<br /> }<br /> <br /> system("echo 0 &gt; /sys/devices/virtual/bdi/253:0/read_ahead_kb");<br /> system("echo 1 &gt; /proc/sys/vm/drop_caches");<br /> <br /> /* Open the xfs file */<br /> fd = open(filename, O_RDONLY);<br /> assert(fd &gt; 0);<br /> <br /> /* Create VMA */<br /> buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ, MAP_SHARED, fd, 0);<br /> assert(buf != (void *)-1);<br /> fprintf(stdout, "mapped buffer at 0x%p\n", buf);<br /> <br /> /* Populate VMA */<br /> ret = madvise(buf, TEST_MEM_SIZE, MADV_NOHUGEPAGE);<br /> assert(ret == 0);<br /> ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_READ);<br /> assert(ret == 0);<br /> <br /> /* Collapse VMA */<br /> ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE);<br /> assert(ret == 0);<br /> ret = madvise(buf, TEST_MEM_SIZE, MADV_COLLAPSE);<br /> if (ret) {<br /> fprintf(stdout, "Error %d to madvise(MADV_COLLAPSE)\n", errno);<br /> goto out;<br /> }<br /> <br /> /* Split xarray entry. Write permission is needed */<br /> munmap(buf, TEST_MEM_SIZE);<br /> buf = (void *)-1;<br /> close(fd);<br /> fd = open(filename, O_RDWR);<br /> assert(fd &gt; 0);<br /> fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,<br /> TEST_MEM_SIZE - pgsize, pgsize);<br /> out:<br /> if (buf != (void *)-1)<br /> munmap(buf, TEST_MEM_SIZE);<br /> if (fd &gt; 0)<br /> close(fd);<br /> <br /> return ret;<br /> }<br /> <br /> [root@dhcp-10-26-1-207 ~]# gcc /tmp/test.c -o /tmp/test<br /> [root@dhcp-10-26-1-207 ~]# /tmp/test<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 25 PID: 7560 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128<br /> Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \<br /> nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \<br /> nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \<br /> ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse \<br /> xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 virtio_net \<br /> sha1_ce net_failover virtio_blk virtio_console failover dimlib virtio_mmio<br /> CPU: 25 PID: 7560 Comm: test Kdump: loaded Not tainted 6.10.0-rc7-gavin+ #9<br /> Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024<br /> pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : xas_split_alloc+0xf8/0x128<br /> lr : split_huge_page_to_list_to_order+0x1c4/0x780<br /> sp : ffff8000ac32f660<br /> x29: ffff8000ac32f660 x28: ffff0000e0969eb0 x27: ffff8000ac32f6c0<br /> x26: 0000000000000c40 x25: ffff0000e0969eb0 x24: 000000000000000d<br /> x23: ffff8000ac32f6c0 x22: ffffffdfc0700000 x21: 0000000000000000<br /> x20: 0000000000000000 x19: ffffffdfc0700000 x18: 0000000000000000<br /> x17: 0000000000000000 x16: ffffd5f3708ffc70 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: ffffffffffffffc0 x10: 0000000000000040 x9 : ffffd5f3708e692c<br /> x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff0000e0969eb8<br /> x5 : ffffd5f37289e378 x4 : 0000000000000000 x3 : 0000000000000c40<br /> x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000<br /> Call trace:<br /> xas_split_alloc+0xf8/0x128<br /> split_huge_page_to_list_to_order+0x1c4/0x780<br /> truncate_inode_partial_folio+0xdc/0x160<br /> truncate_inode_pages_range+0x1b4/0x4a8<br /> truncate_pagecache_range+0x84/0xa<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix potential deadlock on __exfat_get_dentry_set<br /> <br /> When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array<br /> is allocated in __exfat_get_entry_set. The problem is that the bh-array is<br /> allocated with GFP_KERNEL. It does not make sense. In the following cases,<br /> a deadlock for sbi-&gt;s_lock between the two processes may occur.<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> kswapd<br /> balance_pgdat<br /> lock(fs_reclaim)<br /> exfat_iterate<br /> lock(&amp;sbi-&gt;s_lock)<br /> exfat_readdir<br /> exfat_get_uniname_from_ext_entry<br /> exfat_get_dentry_set<br /> __exfat_get_dentry_set<br /> kmalloc_array<br /> ...<br /> lock(fs_reclaim)<br /> ...<br /> evict<br /> exfat_evict_inode<br /> lock(&amp;sbi-&gt;s_lock)<br /> <br /> To fix this, let&amp;#39;s allocate bh-array with GFP_NOFS.