Vulnerabilities

Improper certificate validation and a time-of-check time-of-use (TOCTOU) race condition in the PrivilegedHelperTool XPC service in Cato Client before v.5.13.1 on macOS allows a local authenticated attacker to escalate privileges to root via a self-signed certificate that bypasses the XPC caller verification and a symlink swap during package installation.

A flaw was found in Foreman. The Usergroup model in Foreman does not properly validate role assignments against the calling user's permissions. This allows an authenticated user with usergroup management permissions to attach arbitrary roles, including administrative roles, to a user group and then add themselves as a member. Successful exploitation of this vulnerability leads to full privilege escalation, granting the attacker administrator-level access.

Incorrect Privilege Assignment vulnerability in LCweb PrivateContent allows Privilege Escalation.<br /> <br /> This issue affects PrivateContent: from n/a through 9.9.2.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gem: Fix phys BO pread/pwrite with offset<br /> <br /> sg_page() returns struct page pointer not (void *) so the scaling<br /> of pread/pwrite is wrong for phys BO and wrong parts of BO would be<br /> accessed if non-zero offset is used.<br /> <br /> Last impacted platform with overlay or cursor planes using phys<br /> mapping was Gen3/945G/Lakeport.<br /> <br /> (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rds: clear i_sends on setup unwind<br /> <br /> The RDS IB connection teardown path is written so it can run during<br /> partial startup and on repeated shutdown attempts. It uses NULL<br /> pointers to distinguish resources that are still owned from resources<br /> that have already been released.<br /> <br /> When rds_ib_setup_qp() fails after allocating i_sends but before<br /> allocating i_recvs, the sends_out path frees i_sends without clearing<br /> the pointer. A later shutdown pass can still treat that stale pointer<br /> as a live send ring allocation.<br /> <br /> Clear i_sends after vfree() in the error unwind path so the existing<br /> shutdown logic continues to use the correct ownership state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: errata: Mitigate TLBI errata on various Arm CPUs<br /> <br /> A number of CPUs developed by Arm suffer from errata whereby a broadcast<br /> TLBI;DSB sequence may complete before the global observation of writes<br /> which are translated by an affected TLB entry.<br /> <br /> These errata ONLY affect the completion of memory accesses which have<br /> been translated by an invalidated TLB entry, and these errata DO NOT<br /> affect the actual invalidation of TLB entries. TLB entries are removed<br /> correctly.<br /> <br /> This issue has been assigned CVE ID CVE-2025-10263.<br /> <br /> To mitigate this issue, Arm recommends that software follows any<br /> affected TLBI;DSB sequence with an additional TLBI;DSB, which will<br /> ensure that all memory write effects affected by the first TLBI have<br /> been globally observed. The additional TLBI can use any operation that<br /> is broadcast to affected CPUs, and the additional DSB can use any option<br /> that is sufficient to complete the additional TLBI.<br /> <br /> The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate<br /> the issue. Enable this workaround for affected CPUs, and update the<br /> silicon errata documentation accordingly.<br /> <br /> Note that due to the manner in which Arm develops IP and tracks errata,<br /> some CPUs share a common erratum number.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hsr: Remove WARN_ONCE() in hsr_addr_is_self().<br /> <br /> syzbot reported the warning [0] in hsr_addr_is_self(),<br /> whose assumption is simply wrong.<br /> <br /> hsr-&gt;self_node is cleared in hsr_del_self_node(), which<br /> is called from hsr_dellink().<br /> <br /> Since dev-&gt;rtnl_link_ops-&gt;dellink() is called before<br /> unregister_netdevice_many(), there is a window when<br /> user can find the device but without hsr-&gt;self_node.<br /> <br /> Let&amp;#39;s remove WARN_ONCE() in hsr_addr_is_self().<br /> <br /> [0]:<br /> HSR: No self node<br /> WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}<br /> Tainted: [L]=SOFTLOCKUP<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026<br /> RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39<br /> Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96<br /> RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283<br /> RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000<br /> RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000<br /> R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000<br /> FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0<br /> DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002<br /> DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> check_local_dest net/hsr/hsr_forward.c:592 [inline]<br /> fill_frame_info net/hsr/hsr_forward.c:728 [inline]<br /> hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739<br /> hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236<br /> __netdev_start_xmit include/linux/netdevice.h:5368 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5377 [inline]<br /> xmit_one net/core/dev.c:3888 [inline]<br /> dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904<br /> __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870<br /> neigh_output include/net/neighbour.h:556 [inline]<br /> ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237<br /> ip_send_skb net/ipv4/ip_output.c:1510 [inline]<br /> ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530<br /> raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659<br /> sock_sendmsg_nosec net/socket.c:787 [inline]<br /> __sock_sendmsg net/socket.c:802 [inline]<br /> ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698<br /> ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752<br /> __sys_sendmsg net/socket.c:2784 [inline]<br /> __do_sys_sendmsg net/socket.c:2789 [inline]<br /> __se_sys_sendmsg net/socket.c:2787 [inline]<br /> __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f6feb62ce59<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59<br /> RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004<br /> RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()<br /> <br /> When a multi-threaded process receives a stop signal (e.g., SIGSTOP),<br /> do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all<br /> threads and sets signal-&gt;group_stop_count to the number of threads. If<br /> one of the threads concurrently calls execve(), de_thread() invokes<br /> zap_other_threads() to kill all other threads. zap_other_threads()<br /> aborts the pending group stop by resetting signal-&gt;group_stop_count to 0<br /> and clears the JOBCTL_PENDING_MASK for all other threads. However, it<br /> fails to clear the job control flags for the calling thread.<br /> <br /> When execve() completes, the calling thread returns to user mode and<br /> checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag,<br /> it calls do_signal_stop(), which invokes task_participate_group_stop().<br /> Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the<br /> already-zero signal-&gt;group_stop_count, triggering a warning:<br /> <br /> sig-&gt;group_stop_count == 0<br /> WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373<br /> task_participate_group_stop+0x215/0x2d0<br /> Call Trace:<br /> <br /> do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619<br /> get_signal+0xa8c/0x1330 kernel/signal.c:2884<br /> arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337<br /> exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98<br /> do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> Fix this race condition by clearing the JOBCTL_PENDING_MASK for the<br /> calling thread in zap_other_threads(), ensuring it does not retain any<br /> stale job control state after the thread group is destroyed. This aligns<br /> with other functions that tear down a thread group and abort group<br /> stops, such as zap_process() and complete_signal(), which correctly<br /> clear these flags for all threads including the current one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv/ptrace: Use USER_REGSET_NOTE_TYPE for REGSET_CFI<br /> <br /> Fixes a warning while dumping core:<br /> <br /> [54983.546369][ C7] WARNING: [!note_name] fs/binfmt_elf.c:1771 at elf_core_dump+0x910/0xf68, CPU#7: abort01/31982

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: wm_adsp: Fix NULL dereference when removing firmware controls<br /> <br /> In wm_adsp_control_remove() check that the priv pointer is not NULL<br /> before attempting to cleanup what it points to.<br /> <br /> When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that<br /> wm_adsp can create its own private control data. There are two cases<br /> where private data is not created:<br /> <br /> 1. The control is a SYSTEM control, so an ALSA control is not created.<br /> <br /> 2. The codec driver has registered a control_add() callback that<br /> hides the control, so wm_adsp_control_add() is not called.<br /> <br /> When cs_dsp_remove destroys its control list it calls<br /> wm_adsp_control_remove() for each control. But wm_adsp_control_remove()<br /> was attempting to cleanup the private data pointed to by cs_ctl-&gt;priv<br /> without checking the pointer for NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack: destroy stale expectfn expectations on unregister<br /> <br /> NAT helpers such as nf_nat_h323 store a raw pointer to module text in<br /> exp-&gt;expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister()<br /> only unlinks the callback descriptor and never walks the expectation table,<br /> so an expectation pending at module removal survives with a dangling<br /> exp-&gt;expectfn into freed module text.<br /> <br /> When the expected connection arrives, init_conntrack() invokes<br /> exp-&gt;expectfn(), now a stale pointer into the unloaded module. Reproduced<br /> on a KASAN build by loading the H.323 helpers, creating a Q.931<br /> expectation, unloading nf_nat_h323, then connecting to the expected port:<br /> <br /> Oops: int3: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:0xffffffffa06102d1<br /> init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862)<br /> nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049)<br /> ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223)<br /> nf_hook_slow (net/netfilter/core.c:619)<br /> __ip_local_out (net/ipv4/ip_output.c:120)<br /> __tcp_transmit_skb (net/ipv4/tcp_output.c:1715)<br /> tcp_connect (net/ipv4/tcp_output.c:4374)<br /> tcp_v4_connect (net/ipv4/tcp_ipv4.c:345)<br /> __sys_connect (net/socket.c:2167)<br /> Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323]<br /> <br /> Reaching the dangling state requires CAP_SYS_MODULE in the initial user<br /> namespace to remove a NAT helper that still has live expectations, so this<br /> is a robustness fix; leaving an expectation pointing at freed text is wrong<br /> regardless.<br /> <br /> Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and<br /> drops every expectation whose -&gt;expectfn matches the descriptor being torn<br /> down. Call it from each NAT helper&amp;#39;s exit path after the existing RCU grace<br /> period, so no expectation outlives the code it points at and no extra<br /> synchronize_rcu() is introduced. With the fix, the same reproducer runs to<br /> completion without the Oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SDCA: fix NULL pointer dereference in sdca_dev_unregister_functions<br /> <br /> sdca_dev_unregister_functions() iterates over all SDCA function<br /> descriptors and calls sdca_dev_unregister() on each func_dev without<br /> checking for NULL. When a function registration has failed partway<br /> through, or the device cleanup races with probe deferral, func_dev<br /> entries may be NULL, leading to a kernel oops:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000040<br /> RIP: 0010:device_del+0x1e/0x3e0<br /> Call Trace:<br /> sdca_dev_unregister_functions+0x37/0x60 [snd_soc_sdca]<br /> release_nodes+0x35/0xb0<br /> devres_release_all+0x90/0x100<br /> device_unbind_cleanup+0xe/0x80<br /> device_release_driver_internal+0x1c1/0x200<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x161/0x3e0<br /> device_unregister+0x17/0x60<br /> sdw_delete_slave+0xb6/0xd0 [soundwire_bus]<br /> sdw_bus_master_delete+0x1e/0x50 [soundwire_bus]<br /> ...<br /> sof_probe_work+0x19/0x30 [snd_sof]<br /> <br /> This was observed on a Lenovo ThinkPad X1 Carbon G14 (Panther Lake)<br /> with the SOF audio driver probe failing due to missing Panther Lake<br /> firmware, causing the subsequent cleanup of SoundWire devices to<br /> trigger the crash.<br /> <br /> Fix this with three changes:<br /> <br /> 1) Add a NULL guard in sdca_dev_unregister() so that callers do not<br /> need to pre-validate the pointer (defense in depth).<br /> <br /> 2) In sdca_dev_unregister_functions(), skip NULL func_dev entries<br /> and clear func_dev to NULL after unregistration, making the<br /> function idempotent and safe against double-invocation.<br /> <br /> 3) In sdca_dev_register_functions(), roll back all previously<br /> registered functions when a later one fails, so the function<br /> array is never left in a partially-populated state.