Vulnerabilidades

*** Pendiente de traducción *** A vulnerability was identified in SourceCodester Pet Grooming Management Software 1.0. This issue affects some unknown processing of the file /admin/search_product.php. Such manipulation of the argument group_id leads to sql injection. The attack may be launched remotely. The exploit is publicly available and might be used.

*** Pendiente de traducción *** A security flaw has been discovered in itsourcecode Web-Based Internet Laboratory Management System 1.0. Impacted is the function User::AuthenticateUser of the file login.php. Performing manipulation of the argument user_email results in sql injection. Remote exploitation of the attack is possible. The exploit has been released to the public and may be exploited.

*** Pendiente de traducción *** A vulnerability was determined in kidaze CourseSelectionSystem up to 42cd892b40a18d50bd4ed1905fa89f939173a464. This vulnerability affects unknown code of the file /Profilers/PriProfile/COUNT2.php. This manipulation of the argument cname causes sql injection. The attack may be initiated remotely. This product uses a rolling release model to deliver continuous updates. As a result, specific version information for affected or updated releases is not available.

*** Pendiente de traducción *** A Cross-Site Request Forgery (CSRF) vulnerability exists in the ResetPasswordRequest operation of Zimbra Collaboration (ZCS) when the zimbraFeatureResetPasswordStatus attribute is enabled. An attacker can exploit this by tricking an authenticated user into visiting a malicious webpage that silently sends a crafted SOAP request to reset the user's password. The vulnerability stems from a lack of CSRF token validation on the endpoint, allowing password resets without the user's consent.

*** Pendiente de traducción *** Server-Side Request Forgery (SSRF) vulnerability in Ghost allows an attacker to access internal resources.This issue affects Ghost: from 6.0.0 through 6.0.8, from 5.99.0 through 5.130.3.

*** Pendiente de traducción *** WonderCMS 3.5.0 is vulnerable to Server-Side Request Forgery (SSRF) in the custom module installation functionality. An authenticated administrator can supply a malicious URL via the pluginThemeUrl POST parameter. The server fetches the provided URL using curl_exec() without sufficient validation, allowing the attacker to force internal or external HTTP requests.

*** Pendiente de traducción *** A vulnerability was found in SourceCodester Online Exam Form Submission 1.0. This affects an unknown part of the file /index.php. The manipulation of the argument usn results in sql injection. The attack can be launched remotely. The exploit has been made public and could be used.

*** Pendiente de traducción *** A vulnerability has been found in SourceCodester Online Student File Management System 1.0. Affected by this issue is some unknown functionality of the file /admin/delete_user.php. The manipulation of the argument user_id leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

*** Pendiente de traducción *** Apache::AuthAny::Cookie v0.201 or earlier for Perl generates session ids insecurely.<br /> <br /> Session ids are generated using an MD5 hash of the epoch time and a call to the built-in rand function. The epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage.<br /> <br /> Predicable session ids could allow an attacker to gain access to systems.

*** Pendiente de traducción *** Use of a One-Way Hash with a Predictable Salt vulnerability in ABB FLXEON.This issue affects FLXEON: through 9.3.5. and newer versions

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/habanalabs: fix mem leak in capture user mappings<br /> <br /> This commit fixes a memory leak caused when clearing the user_mappings<br /> info when a new context is opened immediately after user_mapping is<br /> captured and a hard reset is performed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix race issue between cpu buffer write and swap<br /> <br /> Warning happened in rb_end_commit() at code:<br /> if (RB_WARN_ON(cpu_buffer, !local_read(&amp;cpu_buffer-&gt;committing)))<br /> <br /> WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142<br /> rb_commit+0x402/0x4a0<br /> Call Trace:<br /> ring_buffer_unlock_commit+0x42/0x250<br /> trace_buffer_unlock_commit_regs+0x3b/0x250<br /> trace_event_buffer_commit+0xe5/0x440<br /> trace_event_buffer_reserve+0x11c/0x150<br /> trace_event_raw_event_sched_switch+0x23c/0x2c0<br /> __traceiter_sched_switch+0x59/0x80<br /> __schedule+0x72b/0x1580<br /> schedule+0x92/0x120<br /> worker_thread+0xa0/0x6f0<br /> <br /> It is because the race between writing event into cpu buffer and swapping<br /> cpu buffer through file per_cpu/cpu0/snapshot:<br /> <br /> Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1<br /> -------- --------<br /> tracing_snapshot_write()<br /> [...]<br /> <br /> ring_buffer_lock_reserve()<br /> cpu_buffer = buffer-&gt;buffers[cpu]; // 1. Suppose find &amp;#39;cpu_buffer_a&amp;#39;;<br /> [...]<br /> rb_reserve_next_event()<br /> [...]<br /> <br /> ring_buffer_swap_cpu()<br /> if (local_read(&amp;cpu_buffer_a-&gt;committing))<br /> goto out_dec;<br /> if (local_read(&amp;cpu_buffer_b-&gt;committing))<br /> goto out_dec;<br /> buffer_a-&gt;buffers[cpu] = cpu_buffer_b;<br /> buffer_b-&gt;buffers[cpu] = cpu_buffer_a;<br /> // 2. cpu_buffer has swapped here.<br /> <br /> rb_start_commit(cpu_buffer);<br /> if (unlikely(READ_ONCE(cpu_buffer-&gt;buffer)<br /> != buffer)) { // 3. This check passed due to &amp;#39;cpu_buffer-&gt;buffer&amp;#39;<br /> [...] // has not changed here.<br /> return NULL;<br /> }<br /> cpu_buffer_b-&gt;buffer = buffer_a;<br /> cpu_buffer_a-&gt;buffer = buffer_b;<br /> [...]<br /> <br /> // 4. Reserve event from &amp;#39;cpu_buffer_a&amp;#39;.<br /> <br /> ring_buffer_unlock_commit()<br /> [...]<br /> cpu_buffer = buffer-&gt;buffers[cpu]; // 5. Now find &amp;#39;cpu_buffer_b&amp;#39; !!!<br /> rb_commit(cpu_buffer)<br /> rb_end_commit() // 6. WARN for the wrong &amp;#39;committing&amp;#39; state !!!<br /> <br /> Based on above analysis, we can easily reproduce by following testcase:<br /> ``` bash<br /> #!/bin/bash<br /> <br /> dmesg -n 7<br /> sysctl -w kernel.panic_on_warn=1<br /> TR=/sys/kernel/tracing<br /> echo 7 &gt; ${TR}/buffer_size_kb<br /> echo "sched:sched_switch" &gt; ${TR}/set_event<br /> while [ true ]; do<br /> echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot<br /> done &amp;<br /> while [ true ]; do<br /> echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot<br /> done &amp;<br /> while [ true ]; do<br /> echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot<br /> done &amp;<br /> ```<br /> <br /> To fix it, IIUC, we can use smp_call_function_single() to do the swap on<br /> the target cpu where the buffer is located, so that above race would be<br /> avoided.