Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: Fix use-after-free on a dentry&amp;#39;s dname.name<br /> <br /> -&gt;d_name.name can change on rename and the earlier value can be freed;<br /> there are conditions sufficient to stabilize it (-&gt;d_lock on dentry,<br /> -&gt;d_lock on its parent, -&gt;i_rwsem exclusive on the parent&amp;#39;s inode,<br /> rename_lock), but none of those are met at any of the sites. Take a stable<br /> snapshot of the name instead.

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

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.

The WP Total Branding – Complete branding solution for WordPress plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 1.2 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.

The PowerPress Podcasting plugin by Blubrry plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the ‘media_url’ parameter in all versions up to, and including, 11.9.10 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.

The ContentLock WordPress plugin through 1.0.3 does not have CSRF check in place when adding emails, which could allow attackers to make a logged in admin perform such action via a CSRF attack

The ContentLock WordPress plugin through 1.0.3 does not have CSRF check in place when deleting groups or emails, which could allow attackers to make a logged in admin remove them via a CSRF attack