Vulnerabilities

The GitHub CLI is GitHub’s official command line tool. A security vulnerability has been identified in GitHub CLI that could create or overwrite files in unintended directories when users download a malicious GitHub Actions workflow artifact through gh run download. This vulnerability stems from a GitHub Actions workflow artifact named .. when downloaded using gh run download. The artifact name and --dir flag are used to determine the artifact’s download path. When the artifact is named .., the resulting files within the artifact are extracted exactly 1 directory higher than the specified --dir flag value. This vulnerability is fixed in 2.63.1.

A publish-access account was compromised for `@solana/web3.js`, a JavaScript library that is commonly used by Solana dapps. This allowed an attacker to publish unauthorized and malicious packages that were modified, allowing them to steal private key material and drain funds from dapps, like bots, that handle private keys directly. This issue should not affect non-custodial wallets, as they generally do not expose private keys during transactions. This is not an issue with the Solana protocol itself, but with a specific JavaScript client library and only appears to affect projects that directly handle private keys and that updated within the window of 3:20pm UTC and 8:25pm UTC on Tuesday, December 3, 2024. These two unauthorized versions (1.95.6 and 1.95.7) were caught within hours and have since been unpublished. All Solana app developers should upgrade to version 1.95.8. Developers that suspect they might be compromised should rotate any suspect authority keys, including multisigs, program authorities, server keypairs, and so on.

The Accessibility by AllAccessible plugin for WordPress is vulnerable to unauthorized modification of data that can lead to privilege escalation due to a missing capability check on the 'AllAccessible_save_settings' function in all versions up to, and including, 1.3.4. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update arbitrary options on the WordPress site. This can be leveraged to update the default role for registration to administrator and enable user registration for attackers to gain administrative user access to a vulnerable site.

The Mister org.mistergroup.shouldianswer application 1.4.264 for Android enables any installed application (with no permissions) to place phone calls without user interaction by sending a crafted intent via the org.mistergroup.shouldianswer.ui.default_dialer.DefaultDialerActivity component.

The GriceMobile com.grice.call application 4.5.2 for Android enables any installed application (with no permissions) to place phone calls without user interaction by sending a crafted intent via the com.iui.mobile.presentation.MobileActivity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: terminate outstanding dump on socket close<br /> <br /> Netlink supports iterative dumping of data. It provides the families<br /> the following ops:<br /> - start - (optional) kicks off the dumping process<br /> - dump - actual dump helper, keeps getting called until it returns 0<br /> - done - (optional) pairs with .start, can be used for cleanup<br /> The whole process is asynchronous and the repeated calls to .dump<br /> don&amp;#39;t actually happen in a tight loop, but rather are triggered<br /> in response to recvmsg() on the socket.<br /> <br /> This gives the user full control over the dump, but also means that<br /> the user can close the socket without getting to the end of the dump.<br /> To make sure .start is always paired with .done we check if there<br /> is an ongoing dump before freeing the socket, and if so call .done.<br /> <br /> The complication is that sockets can get freed from BH and .done<br /> is allowed to sleep. So we use a workqueue to defer the call, when<br /> needed.<br /> <br /> Unfortunately this does not work correctly. What we defer is not<br /> the cleanup but rather releasing a reference on the socket.<br /> We have no guarantee that we own the last reference, if someone<br /> else holds the socket they may release it in BH and we&amp;#39;re back<br /> to square one.<br /> <br /> The whole dance, however, appears to be unnecessary. Only the user<br /> can interact with dumps, so we can clean up when socket is closed.<br /> And close always happens in process context. Some async code may<br /> still access the socket after close, queue notification skbs to it etc.<br /> but no dumps can start, end or otherwise make progress.<br /> <br /> Delete the workqueue and flush the dump state directly from the release<br /> handler. Note that further cleanup is possible in -next, for instance<br /> we now always call .done before releasing the main module reference,<br /> so dump doesn&amp;#39;t have to take a reference of its own.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: fix possible UAF in sctp_v6_available()<br /> <br /> A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints<br /> that sctp_v6_available() is calling dev_get_by_index_rcu()<br /> and ipv6_chk_addr() without holding rcu.<br /> <br /> [1]<br /> =============================<br /> WARNING: suspicious RCU usage<br /> 6.12.0-rc5-virtme #1216 Tainted: G W<br /> -----------------------------<br /> net/core/dev.c:876 RCU-list traversed in non-reader section!!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by sctp_hello/31495:<br /> #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp<br /> <br /> stack backtrace:<br /> CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:123)<br /> lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)<br /> dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7))<br /> sctp_v6_available (net/sctp/ipv6.c:701) sctp<br /> sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp<br /> sctp_bind (net/sctp/socket.c:320) sctp<br /> inet6_bind_sk (net/ipv6/af_inet6.c:465)<br /> ? security_socket_bind (security/security.c:4581 (discriminator 1))<br /> __sys_bind (net/socket.c:1848 net/socket.c:1869)<br /> ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340)<br /> ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13))<br /> __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1))<br /> do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> RIP: 0033:0x7f59b934a1e7<br /> Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48<br /> All code<br /> ========<br /> 0: 44 00 00 add %r8b,(%rax)<br /> 3: 48 8b 15 39 8c 0c 00 mov 0xc8c39(%rip),%rdx # 0xc8c43<br /> a: f7 d8 neg %eax<br /> c: 64 89 02 mov %eax,%fs:(%rdx)<br /> f: b8 ff ff ff ff mov $0xffffffff,%eax<br /> 14: eb bd jmp 0xffffffffffffffd3<br /> 16: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)<br /> 1d: 00 00 00<br /> 20: 0f 1f 00 nopl (%rax)<br /> 23: b8 31 00 00 00 mov $0x31,%eax<br /> 28: 0f 05 syscall<br /> 2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: fix cacheflush with PAN<br /> <br /> It seems that the cacheflush syscall got broken when PAN for LPAE was<br /> implemented. User access was not enabled around the cache maintenance<br /> instructions, causing them to fault.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx93-blk-ctrl: correct remove path<br /> <br /> The check condition should be &amp;#39;i onecell_data.num_domains&amp;#39;, not<br /> &amp;#39;bc-&gt;onecell_data.num_domains&amp;#39; which will make the look never finish<br /> and cause kernel panic.<br /> <br /> Also disable runtime to address<br /> "imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!"

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Handle dml allocation failure to avoid crash<br /> <br /> [Why]<br /> In the case where a dml allocation fails for any reason, the<br /> current state&amp;#39;s dml contexts would no longer be valid. Then<br /> subsequent calls dc_state_copy_internal would shallow copy<br /> invalid memory and if the new state was released, a double<br /> free would occur.<br /> <br /> [How]<br /> Reset dml pointers in new_state to NULL and avoid invalid<br /> pointer<br /> <br /> (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/oa: Fix "Missing outer runtime PM protection" warning<br /> <br /> Fix the following drm_WARN:<br /> <br /> [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection<br /> ...<br /> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe]<br /> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe]<br /> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe]<br /> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe]<br /> [953.587515] xe_oa_release+0x9c/0xc0 [xe]<br /> <br /> (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint<br /> <br /> Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".<br /> <br /> This series fixes null pointer dereference bugs that occur when using<br /> nilfs2 and two block-related tracepoints.<br /> <br /> <br /> This patch (of 2):<br /> <br /> It has been reported that when using "block:block_touch_buffer"<br /> tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a<br /> NULL pointer dereference, or a general protection fault when KASAN is<br /> enabled.<br /> <br /> This happens because since the tracepoint was added in touch_buffer(), it<br /> references the dev_t member bh-&gt;b_bdev-&gt;bd_dev regardless of whether the<br /> buffer head has a pointer to a block_device structure. In the current<br /> implementation, the block_device structure is set after the function<br /> returns to the caller.<br /> <br /> Here, touch_buffer() is used to mark the folio/page that owns the buffer<br /> head as accessed, but the common search helper for folio/page used by the<br /> caller function was optimized to mark the folio/page as accessed when it<br /> was reimplemented a long time ago, eliminating the need to call<br /> touch_buffer() here in the first place.<br /> <br /> So this solves the issue by eliminating the touch_buffer() call itself.