Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: fsl-mc: Check return value of platform_get_resource()<br /> <br /> platform_get_resource() returns NULL in case of failure, so check its<br /> return value and propagate the error in order to prevent NULL pointer<br /> dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: check the return value of pinmux_ops::get_function_name()<br /> <br /> While the API contract in docs doesn&amp;#39;t specify it explicitly, the<br /> generic implementation of the get_function_name() callback from struct<br /> pinmux_ops - pinmux_generic_get_function_name() - can fail and return<br /> NULL. This is already checked in pinmux_check_ops() so add a similar<br /> check in pinmux_func_name_to_selector() instead of passing the returned<br /> pointer right down to strcmp() where the NULL can get dereferenced. This<br /> is normal operation when adding new pinfunctions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tee: fix register_shm_helper()<br /> <br /> In register_shm_helper(), fix incorrect error handling for a call to<br /> iov_iter_extract_pages(). A case is missing for when<br /> iov_iter_extract_pages() only got some pages and return a number larger<br /> than 0, but not the requested amount.<br /> <br /> This fixes a possible NULL pointer dereference following a bad input from<br /> ioctl(TEE_IOC_SHM_REGISTER) where parts of the buffer isn&amp;#39;t mapped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Don&amp;#39;t (re)check L1 intercepts when completing userspace I/O<br /> <br /> When completing emulation of instruction that generated a userspace exit<br /> for I/O, don&amp;#39;t recheck L1 intercepts as KVM has already finished that<br /> phase of instruction execution, i.e. has already committed to allowing L2<br /> to perform I/O. If L1 (or host userspace) modifies the I/O permission<br /> bitmaps during the exit to userspace, KVM will treat the access as being<br /> intercepted despite already having emulated the I/O access.<br /> <br /> Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation.<br /> Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the<br /> intended "recipient") can reach the code in question. gp_interception()&amp;#39;s<br /> use is mutually exclusive with is_guest_mode(), and<br /> complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with<br /> EMULTYPE_SKIP.<br /> <br /> The bad behavior was detected by a syzkaller program that toggles port I/O<br /> interception during the userspace I/O exit, ultimately resulting in a WARN<br /> on vcpu-&gt;arch.pio.count being non-zero due to KVM no completing emulation<br /> of the I/O instruction.<br /> <br /> WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm]<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm]<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> kvm_fast_pio+0xd6/0x1d0 [kvm]<br /> vmx_handle_exit+0x149/0x610 [kvm_intel]<br /> kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm]<br /> kvm_vcpu_ioctl+0x244/0x8c0 [kvm]<br /> __x64_sys_ioctl+0x8a/0xd0<br /> do_syscall_64+0x5d/0xc60<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/9p: fix double req put in p9_fd_cancelled<br /> <br /> Syzkaller reports a KASAN issue as below:<br /> <br /> general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]<br /> CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:__list_del include/linux/list.h:114 [inline]<br /> RIP: 0010:__list_del_entry include/linux/list.h:137 [inline]<br /> RIP: 0010:list_del include/linux/list.h:148 [inline]<br /> RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734<br /> <br /> Call Trace:<br /> <br /> p9_client_flush+0x351/0x440 net/9p/client.c:614<br /> p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734<br /> p9_client_version net/9p/client.c:920 [inline]<br /> p9_client_create+0xb51/0x1240 net/9p/client.c:1027<br /> v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408<br /> v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126<br /> legacy_get_tree+0x108/0x220 fs/fs_context.c:632<br /> vfs_get_tree+0x8e/0x300 fs/super.c:1573<br /> do_new_mount fs/namespace.c:3056 [inline]<br /> path_mount+0x6a6/0x1e90 fs/namespace.c:3386<br /> do_mount fs/namespace.c:3399 [inline]<br /> __do_sys_mount fs/namespace.c:3607 [inline]<br /> __se_sys_mount fs/namespace.c:3584 [inline]<br /> __x64_sys_mount+0x283/0x300 fs/namespace.c:3584<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> This happens because of a race condition between:<br /> <br /> - The 9p client sending an invalid flush request and later cleaning it up;<br /> - The 9p client in p9_read_work() canceled all pending requests.<br /> <br /> Thread 1 Thread 2<br /> ...<br /> p9_client_create()<br /> ...<br /> p9_fd_create()<br /> ...<br /> p9_conn_create()<br /> ...<br /> // start Thread 2<br /> INIT_WORK(&amp;m-&gt;rq, p9_read_work);<br /> p9_read_work()<br /> ...<br /> p9_client_rpc()<br /> ...<br /> ...<br /> p9_conn_cancel()<br /> ...<br /> spin_lock(&amp;m-&gt;req_lock);<br /> ...<br /> p9_fd_cancelled()<br /> ...<br /> ...<br /> spin_unlock(&amp;m-&gt;req_lock);<br /> // status rewrite<br /> p9_client_cb(m-&gt;client, req, REQ_STATUS_ERROR)<br /> // first remove<br /> list_del(&amp;req-&gt;req_list);<br /> ...<br /> <br /> spin_lock(&amp;m-&gt;req_lock)<br /> ...<br /> // second remove<br /> list_del(&amp;req-&gt;req_list);<br /> spin_unlock(&amp;m-&gt;req_lock)<br /> ...<br /> <br /> Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list in<br /> p9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystem<br /> client where the req_list could be deleted simultaneously by both<br /> p9_read_work and p9_fd_cancelled functions, but for the case where req-&gt;status<br /> equals REQ_STATUS_RCVD.<br /> <br /> Update the check for req-&gt;status in p9_fd_cancelled to skip processing not<br /> just received requests, but anything that is not SENT, as whatever<br /> changed the state from SENT also removed the request from its list.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.<br /> <br /> [updated the check from status == RECV || status == ERROR to status != SENT]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix double-free in dbitmap<br /> <br /> A process might fail to allocate a new bitmap when trying to expand its<br /> proc-&gt;dmap. In that case, dbitmap_grow() fails and frees the old bitmap<br /> via dbitmap_free(). However, the driver calls dbitmap_free() again when<br /> the same process terminates, leading to a double-free error:<br /> <br /> ==================================================================<br /> BUG: KASAN: double-free in binder_proc_dec_tmpref+0x2e0/0x55c<br /> Free of addr ffff00000b7c1420 by task kworker/9:1/209<br /> <br /> CPU: 9 UID: 0 PID: 209 Comm: kworker/9:1 Not tainted 6.17.0-rc6-dirty #5 PREEMPT<br /> Hardware name: linux,dummy-virt (DT)<br /> Workqueue: events binder_deferred_func<br /> Call trace:<br /> kfree+0x164/0x31c<br /> binder_proc_dec_tmpref+0x2e0/0x55c<br /> binder_deferred_func+0xc24/0x1120<br /> process_one_work+0x520/0xba4<br /> [...]<br /> <br /> Allocated by task 448:<br /> __kmalloc_noprof+0x178/0x3c0<br /> bitmap_zalloc+0x24/0x30<br /> binder_open+0x14c/0xc10<br /> [...]<br /> <br /> Freed by task 449:<br /> kfree+0x184/0x31c<br /> binder_inc_ref_for_node+0xb44/0xe44<br /> binder_transaction+0x29b4/0x7fbc<br /> binder_thread_write+0x1708/0x442c<br /> binder_ioctl+0x1b50/0x2900<br /> [...]<br /> ==================================================================<br /> <br /> Fix this issue by marking proc-&gt;map NULL in dbitmap_free().

microCLAUDIA in v3.2.0 and prior has an improper access control vulnerability.<br /> <br /> This flaw allows an authenticated user to perform unauthorized actions on other organizations&amp;#39; systems by sending direct API requests. To do so, the attacker can use organization identifiers obtained through a compromised endpoint or deduced manually.<br /> <br /> This vulnerability allows access between tenants, enabling an attacker to list and manage remote assets, uninstall agents, and even delete vaccines configurations.

Multiple CSRF attack vectors in JDownloads component 1.0.0-4.0.47 for Joomla were discovered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on node footer for non inode dnode<br /> <br /> As syzbot reported below:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/file.c:1243!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 5354 Comm: syz.0.0 Not tainted 6.17.0-rc1-syzkaller-00211-g90d970cade8e #0 PREEMPT(full)<br /> RIP: 0010:f2fs_truncate_hole+0x69e/0x6c0 fs/f2fs/file.c:1243<br /> Call Trace:<br /> <br /> f2fs_punch_hole+0x2db/0x330 fs/f2fs/file.c:1306<br /> f2fs_fallocate+0x546/0x990 fs/f2fs/file.c:2018<br /> vfs_fallocate+0x666/0x7e0 fs/open.c:342<br /> ksys_fallocate fs/open.c:366 [inline]<br /> __do_sys_fallocate fs/open.c:371 [inline]<br /> __se_sys_fallocate fs/open.c:369 [inline]<br /> __x64_sys_fallocate+0xc0/0x110 fs/open.c:369<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f1e65f8ebe9<br /> <br /> w/ a fuzzed image, f2fs may encounter panic due to it detects inconsistent<br /> truncation range in direct node in f2fs_truncate_hole().<br /> <br /> The root cause is: a non-inode dnode may has the same footer.ino and<br /> footer.nid, so the dnode will be parsed as an inode, then ADDRS_PER_PAGE()<br /> may return wrong blkaddr count which may be 923 typically, by chance,<br /> dn.ofs_in_node is equal to 923, then count can be calculated to 0 in below<br /> statement, later it will trigger panic w/ f2fs_bug_on(, count == 0 || ...).<br /> <br /> count = min(end_offset - dn.ofs_in_node, pg_end - pg_start);<br /> <br /> This patch introduces a new node_type NODE_TYPE_NON_INODE, then allowing<br /> passing the new_type to sanity_check_node_footer in f2fs_get_node_folio()<br /> to detect corruption that a non-inode dnode has the same footer.ino and<br /> footer.nid.<br /> <br /> Scripts to reproduce:<br /> mkfs.f2fs -f /dev/vdb<br /> mount /dev/vdb /mnt/f2fs<br /> touch /mnt/f2fs/foo<br /> touch /mnt/f2fs/bar<br /> dd if=/dev/zero of=/mnt/f2fs/foo bs=1M count=8<br /> umount /mnt/f2fs<br /> inject.f2fs --node --mb i_nid --nid 4 --idx 0 --val 5 /dev/vdb<br /> mount /dev/vdb /mnt/f2fs<br /> xfs_io /mnt/f2fs/foo -c "fpunch 6984k 4k"

Webserver crash caused by scanning on TCP port 80 in Softing Industrial Automation GmbH gateways and switch.This issue affects<br /> <br /> smartLink HW-PN: from 1.02 through 1.03<br /> <br /> smartLink HW-DP: 1.31

Improper locking vulnerability in Softing Industrial Automation GmbH gateways allows infected memory and/or resource leak exposure.This issue affects<br /> <br /> smartLink HW-PN: from 1.02 through 1.03<br /> <br /> smartLink HW-DP: 1.31

The HUSKY – Products Filter Professional for WooCommerce plugin for WordPress is vulnerable to blind SQL Injection via the `phrase` parameter in all versions up to, and including, 1.3.7.1 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.