Vulnerabilidades

*** Pendiente de traducción *** Multiple unbounded alloca() calls in the PulseAudio protocol server.

*** Pendiente de traducción *** A vulnerability has been identified in the Feast Feature Server’s `/save-document` endpoint that allows an unauthenticated remote attacker to write arbitrary JSON files to the server's filesystem. Although the system attempts to restrict file locations, these protections can be bypassed, enabling an attacker to overwrite vital application configurations or startup scripts. Because this flaw requires no credentials or special privileges, any attacker with network access to the server can potentially compromise the integrity of the system. This could lead to unauthorized system modifications, denial of service through disk exhaustion, or potential remote code execution.

*** Pendiente de traducción *** The following Poly Voice IP devices, CCX, Trio, and Edge E, might be inoperable if they connect to a malicious SIP server and receive malformed data. HP is releasing updates to mitigate these potential vulnerabilities.

*** Pendiente de traducción *** We found a chain of combining multiple weaknesses in the product that could allow an attacker to become any user in the backend and access any data:<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> * <br /> <br /> <br /> The payment integration plugins Stripe (included in the core system), pretix-mollie, pretix-oppwa, pretix-bitpay, pretix-payone, pretix-secuconnect, pretix-sofort, and pretix-saferpay<br /> contain a code path that is intended for the transport of session <br /> parameters from a tab with isolated cookies (e.g. in the pretix widget) <br /> to a new tab. For this purpose, a set of session parameters is <br /> cryptographically signed and then passed to the new tab as a URL <br /> parameter. The plugins perform no further validation of the session <br /> parameters, other than the cryptographic signature being valid. This is <br /> fixed with the releases issued today by strictly validating that no <br /> session parameters outside of the scope of the respective plugin may be <br /> set.<br /> <br /> <br /> <br /> <br /> * <br /> <br /> <br /> An unrelated feature in the core system is used to generate redirect links that obfuscate any Referer<br /> headers for outgoing links to prevent leakage of secrets in URLs. This <br /> redirect page also requires cryptographically signed parameters. <br /> Unfortunately, it uses the same key and salt for the signature as the <br /> previously mentioned feature in the payment integration plugins. A <br /> motivated attacker with access to at least one event in the backend can <br /> trick the system into cryptographically signing arbitrary content using <br /> specially crafted links. In combination with the previous issue, the <br /> attacker could use this to set and modify arbitrary parameters on their <br /> user session by injecting the signed parameters into the feature of the <br /> payment providers. This is fixed with the releases issued today by using<br /> different salts for the signature for each plugin and feature.<br /> <br /> <br /> <br /> <br /> * <br /> <br /> <br /> A third, unrelated feature in the core system is used for admin users<br /> to act on behalf of another user, mostly for debugging purposes. With <br /> being able to insert arbitrary parameters into a session, an attacker <br /> can abuse this feature to change their session from their actual user to<br /> any user in the system by guessing a valid user ID. This is fixed with<br /> the release today by requiring unguessable information to be contained <br /> in the session of the user to switch to.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** A flaw was found in Foreman. The Usergroup model in Foreman does not properly validate role assignments against the calling user&amp;#39;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.

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

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.