| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In Deark before v1.5.8, a specially crafted input file can cause a division by zero in (src/fmtutil.c) because of the value of pixelsize. |
| QOCA aim AI Medical Cloud Platform developed by Quanta Computer has a Path Traversal vulnerability, allowing authenticated remote attackers to read folder names under the specified path by exploiting an Absolute Path Traversal vulnerability. |
| QOCA aim AI Medical Cloud Platform developed by Quanta Computer has a Path Traversal vulnerability, allowing authenticated remote attackers to read folder names under the specified path by exploiting an Absolute Path Traversal vulnerability. |
| A group deletion race condition in 2FAuth v5.5.0 causes data inconsistencies and orphaned accounts when a group is deleted while other operations are pending. |
| In Eclipse Jersey versions 2.45, 3.0.16, 3.1.9 a race condition can cause ignoring of critical SSL configurations - such as mutual authentication, custom key/trust stores, and other security settings. This issue may result in SSLHandshakeException under normal circumstances, but under certain conditions, it could lead to unauthorized trust in insecure servers (see PoC) |
| In the Linux kernel, the following vulnerability has been resolved:
mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters()
Patch series "mm/damon: avoid divide-by-zero in DAMON module's parameters
application".
DAMON's RECLAIM and LRU_SORT modules perform no validation on
user-configured parameters during application, which may lead to
division-by-zero errors.
Avoid the divide-by-zero by adding validation checks when DAMON modules
attempt to apply the parameters.
This patch (of 2):
During the calculation of 'hot_thres' and 'cold_thres', either
'sample_interval' or 'aggr_interval' is used as the divisor, which may
lead to division-by-zero errors. Fix it by directly returning -EINVAL
when such a case occurs. Additionally, since 'aggr_interval' is already
required to be set no smaller than 'sample_interval' in damon_set_attrs(),
only the case where 'sample_interval' is zero needs to be checked. |
| BullWall Server Intrusion Protection (SIP) services are initialized after login services during system startup. A local, authenticated attacker can log in after boot and before SIP MFA is running. The SIP services do not retroactively enforce MFA or disconnect sessions that were not subject to SIP MFA. Versions 4.6.0.0, 4.6.0.6, 4.6.0.7, and 4.6.1.4 are affected. Other versions mayy also be affected. BullWall plans to improve detection method documentation. |
| BullWall Server Intrusion Protection has a noticeable configuration-dependent delay before the MFA check for RDP connections. A remote, authenticated attacker can potentially bypass detection during this delay. Versions 4.6.0.0, 4.6.0.6, 4.6.0.7, and 4.6.1.4 are affected. Other versions may also be affected. |
| Multi-thread race condition vulnerability in the camera framework module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| Multi-thread race condition vulnerability in the camera framework module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| Multi-thread race condition vulnerability in the video framework module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| Multi-thread race condition vulnerability in the card framework module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| Multi-thread race condition vulnerability in the card framework module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| Multi-thread race condition vulnerability in the card framework module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| Multi-thread race condition vulnerability in the card framework module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| Multi-thread race condition vulnerability in the thermal management module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| Vitals ESP developed by Galaxy Software Services has an Arbitrary File Read vulnerability, allowing privileged remote attackers to exploit Absolute Path Traversal to download arbitrary system files. |
| A local privilege escalation vulnerability exists in SevenCs ORCA G2 2.0.1.35 (EC2007 Kernel v5.22). The flaw is a Time-of-Check Time-of-Use (TOCTOU) race condition in the license management logic. The regService process, which runs with SYSTEM privileges, creates a fixed directory and writes files without verifying whether the path is an NTFS reparse point. By exploiting this race condition, an attacker can replace the target directory with a junction pointing to a user-controlled path. This causes the SYSTEM-level process to drop binaries in a location fully controlled by the attacker, allowing arbitrary code execution with SYSTEM privileges. The vulnerability can be exploited by any standard user with only a single UAC confirmation, making it highly practical and dangerous in real-world environments. |
| In the Linux kernel, the following vulnerability has been resolved:
net: phylink: add lock for serializing concurrent pl->phydev writes with resolver
Currently phylink_resolve() protects itself against concurrent
phylink_bringup_phy() or phylink_disconnect_phy() calls which modify
pl->phydev by relying on pl->state_mutex.
The problem is that in phylink_resolve(), pl->state_mutex is in a lock
inversion state with pl->phydev->lock. So pl->phydev->lock needs to be
acquired prior to pl->state_mutex. But that requires dereferencing
pl->phydev in the first place, and without pl->state_mutex, that is
racy.
Hence the reason for the extra lock. Currently it is redundant, but it
will serve a functional purpose once mutex_lock(&phy->lock) will be
moved outside of the mutex_lock(&pl->state_mutex) section.
Another alternative considered would have been to let phylink_resolve()
acquire the rtnl_mutex, which is also held when phylink_bringup_phy()
and phylink_disconnect_phy() are called. But since phylink_disconnect_phy()
runs under rtnl_lock(), it would deadlock with phylink_resolve() when
calling flush_work(&pl->resolve). Additionally, it would have been
undesirable because it would have unnecessarily blocked many other call
paths as well in the entire kernel, so the smaller-scoped lock was
preferred. |
| In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix race issue between cpu buffer write and swap
Warning happened in rb_end_commit() at code:
if (RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing)))
WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142
rb_commit+0x402/0x4a0
Call Trace:
ring_buffer_unlock_commit+0x42/0x250
trace_buffer_unlock_commit_regs+0x3b/0x250
trace_event_buffer_commit+0xe5/0x440
trace_event_buffer_reserve+0x11c/0x150
trace_event_raw_event_sched_switch+0x23c/0x2c0
__traceiter_sched_switch+0x59/0x80
__schedule+0x72b/0x1580
schedule+0x92/0x120
worker_thread+0xa0/0x6f0
It is because the race between writing event into cpu buffer and swapping
cpu buffer through file per_cpu/cpu0/snapshot:
Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1
-------- --------
tracing_snapshot_write()
[...]
ring_buffer_lock_reserve()
cpu_buffer = buffer->buffers[cpu]; // 1. Suppose find 'cpu_buffer_a';
[...]
rb_reserve_next_event()
[...]
ring_buffer_swap_cpu()
if (local_read(&cpu_buffer_a->committing))
goto out_dec;
if (local_read(&cpu_buffer_b->committing))
goto out_dec;
buffer_a->buffers[cpu] = cpu_buffer_b;
buffer_b->buffers[cpu] = cpu_buffer_a;
// 2. cpu_buffer has swapped here.
rb_start_commit(cpu_buffer);
if (unlikely(READ_ONCE(cpu_buffer->buffer)
!= buffer)) { // 3. This check passed due to 'cpu_buffer->buffer'
[...] // has not changed here.
return NULL;
}
cpu_buffer_b->buffer = buffer_a;
cpu_buffer_a->buffer = buffer_b;
[...]
// 4. Reserve event from 'cpu_buffer_a'.
ring_buffer_unlock_commit()
[...]
cpu_buffer = buffer->buffers[cpu]; // 5. Now find 'cpu_buffer_b' !!!
rb_commit(cpu_buffer)
rb_end_commit() // 6. WARN for the wrong 'committing' state !!!
Based on above analysis, we can easily reproduce by following testcase:
``` bash
#!/bin/bash
dmesg -n 7
sysctl -w kernel.panic_on_warn=1
TR=/sys/kernel/tracing
echo 7 > ${TR}/buffer_size_kb
echo "sched:sched_switch" > ${TR}/set_event
while [ true ]; do
echo 1 > ${TR}/per_cpu/cpu0/snapshot
done &
while [ true ]; do
echo 1 > ${TR}/per_cpu/cpu0/snapshot
done &
while [ true ]; do
echo 1 > ${TR}/per_cpu/cpu0/snapshot
done &
```
To fix it, IIUC, we can use smp_call_function_single() to do the swap on
the target cpu where the buffer is located, so that above race would be
avoided. |
