Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: fix use-after-free due to race with dev replace<br /> <br /> While loading a zone&amp;#39;s info during creation of a block group, we can race<br /> with a device replace operation and then trigger a use-after-free on the<br /> device that was just replaced (source device of the replace operation).<br /> <br /> This happens because at btrfs_load_zone_info() we extract a device from<br /> the chunk map into a local variable and then use the device while not<br /> under the protection of the device replace rwsem. So if there&amp;#39;s a device<br /> replace operation happening when we extract the device and that device<br /> is the source of the replace operation, we will trigger a use-after-free<br /> if before we finish using the device the replace operation finishes and<br /> frees the device.<br /> <br /> Fix this by enlarging the critical section under the protection of the<br /> device replace rwsem so that all uses of the device are done inside the<br /> critical section.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> greybus: Fix use-after-free bug in gb_interface_release due to race condition.<br /> <br /> In gb_interface_create, &amp;intf-&gt;mode_switch_completion is bound with<br /> gb_interface_mode_switch_work. Then it will be started by<br /> gb_interface_request_mode_switch. Here is the relevant code.<br /> if (!queue_work(system_long_wq, &amp;intf-&gt;mode_switch_work)) {<br /> ...<br /> }<br /> <br /> If we call gb_interface_release to make cleanup, there may be an<br /> unfinished work. This function will call kfree to free the object<br /> "intf". However, if gb_interface_mode_switch_work is scheduled to<br /> run after kfree, it may cause use-after-free error as<br /> gb_interface_mode_switch_work will use the object "intf".<br /> The possible execution flow that may lead to the issue is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | gb_interface_create<br /> | gb_interface_request_mode_switch<br /> gb_interface_release |<br /> kfree(intf) (free) |<br /> | gb_interface_mode_switch_work<br /> | mutex_lock(&amp;intf-&gt;mutex) (use)<br /> <br /> Fix it by canceling the work before kfree.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)<br /> <br /> Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap<br /> allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag<br /> causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:<br /> BUG_ON((vma-&gt;vm_flags &amp; VM_PFNMAP) &amp;&amp; is_cow_mapping(vma-&gt;vm_flags));<br /> <br /> Return -EINVAL early if COW mapping is detected.<br /> <br /> This bug affects all drm drivers using default shmem helpers.<br /> It can be reproduced by this simple example:<br /> void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);<br /> ptr[0] = 0;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vmci: prevent speculation leaks by sanitizing event in event_deliver()<br /> <br /> Coverity spotted that event_msg is controlled by user-space,<br /> event_msg-&gt;event_data.event is passed to event_deliver() and used<br /> as an index without sanitization.<br /> <br /> This change ensures that the event index is sanitized to mitigate any<br /> possibility of speculative information leaks.<br /> <br /> This bug was discovered and resolved using Coverity Static Analysis<br /> Security Testing (SAST) by Synopsys, Inc.<br /> <br /> Only compile tested, no access to HW.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sock_map: avoid race between sock_map_close and sk_psock_put<br /> <br /> sk_psock_get will return NULL if the refcount of psock has gone to 0, which<br /> will happen when the last call of sk_psock_put is done. However,<br /> sk_psock_drop may not have finished yet, so the close callback will still<br /> point to sock_map_close despite psock being NULL.<br /> <br /> This can be reproduced with a thread deleting an element from the sock map,<br /> while the second one creates a socket, adds it to the map and closes it.<br /> <br /> That will trigger the WARN_ON_ONCE:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701<br /> Modules linked in:<br /> CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024<br /> RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701<br /> Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02<br /> RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293<br /> RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000<br /> RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0<br /> RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3<br /> R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840<br /> R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870<br /> FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> unix_release+0x87/0xc0 net/unix/af_unix.c:1048<br /> __sock_release net/socket.c:659 [inline]<br /> sock_close+0xbe/0x240 net/socket.c:1421<br /> __fput+0x42b/0x8a0 fs/file_table.c:422<br /> __do_sys_close fs/open.c:1556 [inline]<br /> __se_sys_close fs/open.c:1541 [inline]<br /> __x64_sys_close+0x7f/0x110 fs/open.c:1541<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fb37d618070<br /> Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c<br /> RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003<br /> RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070<br /> RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004<br /> RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> <br /> Use sk_psock, which will only check that the pointer is not been set to<br /> NULL yet, which should only happen after the callbacks are restored. If,<br /> then, a reference can still be gotten, we may call sk_psock_stop and cancel<br /> psock-&gt;work.<br /> <br /> As suggested by Paolo Abeni, reorder the condition so the control flow is<br /> less convoluted.<br /> <br /> After that change, the reproducer does not trigger the WARN_ON_ONCE<br /> anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ionic: fix use after netif_napi_del()<br /> <br /> When queues are started, netif_napi_add() and napi_enable() are called.<br /> If there are 4 queues and only 3 queues are used for the current<br /> configuration, only 3 queues&amp;#39; napi should be registered and enabled.<br /> The ionic_qcq_enable() checks whether the .poll pointer is not NULL for<br /> enabling only the using queue&amp;#39; napi. Unused queues&amp;#39; napi will not be<br /> registered by netif_napi_add(), so the .poll pointer indicates NULL.<br /> But it couldn&amp;#39;t distinguish whether the napi was unregistered or not<br /> because netif_napi_del() doesn&amp;#39;t reset the .poll pointer to NULL.<br /> So, ionic_qcq_enable() calls napi_enable() for the queue, which was<br /> unregistered by netif_napi_del().<br /> <br /> Reproducer:<br /> ethtool -L rx 1 tx 1 combined 0<br /> ethtool -L rx 0 tx 0 combined 1<br /> ethtool -L rx 0 tx 0 combined 4<br /> <br /> Splat looks like:<br /> kernel BUG at net/core/dev.c:6666!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16<br /> Workqueue: events ionic_lif_deferred_work [ionic]<br /> RIP: 0010:napi_enable+0x3b/0x40<br /> Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f<br /> RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029<br /> RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28<br /> RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001<br /> R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000<br /> R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20<br /> FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? die+0x33/0x90<br /> ? do_trap+0xd9/0x100<br /> ? napi_enable+0x3b/0x40<br /> ? do_error_trap+0x83/0xb0<br /> ? napi_enable+0x3b/0x40<br /> ? napi_enable+0x3b/0x40<br /> ? exc_invalid_op+0x4e/0x70<br /> ? napi_enable+0x3b/0x40<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? napi_enable+0x3b/0x40<br /> ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]<br /> ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]<br /> ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]<br /> ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]<br /> process_one_work+0x145/0x360<br /> worker_thread+0x2bb/0x3d0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xcc/0x100<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2d/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type<br /> <br /> Lion Ackermann reported that there is a race condition between namespace cleanup<br /> in ipset and the garbage collection of the list:set type. The namespace<br /> cleanup can destroy the list:set type of sets while the gc of the set type is<br /> waiting to run in rcu cleanup. The latter uses data from the destroyed set which<br /> thus leads use after free. The patch contains the following parts:<br /> <br /> - When destroying all sets, first remove the garbage collectors, then wait<br /> if needed and then destroy the sets.<br /> - Fix the badly ordered "wait then remove gc" for the destroy a single set<br /> case.<br /> - Fix the missing rcu locking in the list:set type in the userspace test<br /> case.<br /> - Use proper RCU list handlings in the list:set type.<br /> <br /> The patch depends on c1193d9bbbd3 (netfilter: ipset: Add list flush to cancel_gc).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/komeda: check for error-valued pointer<br /> <br /> komeda_pipeline_get_state() may return an error-valued pointer, thus<br /> check the pointer for negative or null value before dereferencing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet<br /> <br /> In lio_vf_rep_copy_packet() pg_info-&gt;page is compared to a NULL value,<br /> but then it is unconditionally passed to skb_add_rx_frag() which looks<br /> strange and could lead to null pointer dereference.<br /> <br /> lio_vf_rep_copy_packet() call trace looks like:<br /> octeon_droq_process_packets<br /> octeon_droq_fast_process_packets<br /> octeon_droq_dispatch_pkt<br /> octeon_create_recv_info<br /> ...search in the dispatch_list...<br /> -&gt;disp_fn(rdisp-&gt;rinfo, ...)<br /> lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)<br /> In this path there is no code which sets pg_info-&gt;page to NULL.<br /> So this check looks unneeded and doesn&amp;#39;t solve potential problem.<br /> But I guess the author had reason to add a check and I have no such card<br /> and can&amp;#39;t do real test.<br /> In addition, the code in the function liquidio_push_packet() in<br /> liquidio/lio_core.c does exactly the same.<br /> <br /> Based on this, I consider the most acceptable compromise solution to<br /> adjust this issue by moving skb_add_rx_frag() into conditional scope.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

The default configuration of XSLTResourceStream.java is vulnerable to remote code execution via XSLT injection when processing input from an untrusted source without validation.<br /> Users are recommended to upgrade to versions 10.1.0, 9.18.0 or 8.16.0, which fix this issue.

The MStore API – Create Native Android &amp; iOS Apps On The Cloud plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 4.14.7. This is due to insufficient verification on the &amp;#39;phone&amp;#39; parameter of the &amp;#39;firebase_sms_login&amp;#39; and &amp;#39;firebase_sms_login_v2&amp;#39; functions. This makes it possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, if they have access to the email address or phone number. Additionally, if a new email address is supplied, a new user account is created with the default role, even if registration is disabled.

The Wallet for WooCommerce plugin for WordPress is vulnerable to SQL Injection via the &amp;#39;search[value]&amp;#39; parameter in all versions up to, and including, 1.5.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 Subscriber-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.