| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Due to a race condition in a global variable in 3.6.0-rc1, the argo workflows controller can be made to crash on-command by any user with access to execute a workflow. This vulnerability is fixed in 3.6.0-rc2. |
| NVIDIA Resiliency Extension for Linux contains a vulnerability in the checkpointing core, where an attacker may cause a race condition. A successful exploit of this vulnerability might lead to information disclosure, data tampering, denial of service, or escalation of privileges. |
| In the anode crate 0.1.0 for Rust, data races can occur in unlock in SpinLock. |
| The process_lock crate 0.1.0 for Rust allows data races in unlock. |
| inner::drop in inner.rs in the wgp crate through 0.2.0 for Rust lacks drop_slow thread synchronization. |
| Race condition in the turbo-frame element handler in Hotwired Turbo before 8.0.x causes logout operations to fail when delayed frame responses reapply session cookies after logout. This can be exploited by remote attackers via selective network delays (e.g. delaying requests based on sequence or timing) or by physically proximate attackers when the race condition occurs naturally on shared computers. |
| Cancelling a query (e.g. by cancelling the context passed to one of the query methods) during a call to the Scan method of the returned Rows can result in unexpected results if other queries are being made in parallel. This can result in a race condition that may overwrite the expected results with those of another query, causing the call to Scan to return either unexpected results from the other query or an error. |
| Grafana is an open-source platform for monitoring and observability. Versions starting with 9.2.0 and less than 9.2.4 contain a race condition in the authentication middlewares logic which may allow an unauthenticated user to query an administration endpoint under heavy load. This issue is patched in 9.2.4. There are no known workarounds. |
| An issue was discovered in the Camera in Samsung Mobile Processor and Wearable Processor Exynos 1330, 1380, 1480, 2400, 1580, 2500. A race condition in the issimian device driver results in a double free, leading to a denial of service. |
| 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) |
| 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. |
| 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. |
