| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Unauthenticated Cross Site Scripting (XSS) in MP3 Audio Player for Music, Radio & Podcast by Sonaar <= 5.13.1 versions. |
| Server-Side Request Forgery (SSRF) vulnerability in Drupal Entity Share Websub allows Server Side Request Forgery. This issue affects Entity Share Websub versions: from 0.0.0 to 1.1.2. |
| An authentication bypass vulnerability exists in the underlying operating system of HPE Networking Fabric Composer. Successful exploitation could allow an unauthenticated adjacent attacker to execute arbitrary code as a privileged user on the underlying operating system, leading to complete compromise of the AFC host. |
| A vulnerability in the web-based management interface of HPE Networking Fabric Composer could allow an authenticated low privilege operator user to conduct a stored cross-site scripting (XSS) attack against an administrative user of the interface. A successful exploit could allow an attacker to execute arbitrary script code in a victim's browser in the context of the affected interface. |
| An unauthenticated remote code execution vulnerability exists in the underlying operating system of HPE Networking Fabric Composer and could be exploited if certain preconditions outside of the attacker's control are met. Successful exploitation of this vulnerability could allow an unauthenticated remote attacker to execute arbitrary code as a privileged user on the underlying operating system, leading to complete compromise of the HPE Networking Fabric Composer host. |
| A privilege escalation vulnerability exists in the API of HPE Networking Fabric Composer. Successful exploitation could allow an authenticated low privilege operator user to escalate their permissions to those of an administrative user, leading to complete system compromise. |
| A vulnerability in the web-based management interface of HPE Networking Fabric Composer could allow an unauthenticated adjacent attacker to conduct a stored cross-site scripting (XSS) attack against a user of the interface. A successful exploit could allow an attacker to execute arbitrary script code in a victim's browser in the context of the affected interface. |
| A vulnerability in the API of HPE Networking Fabric Composer could allow an unauthenticated remote attacker to obtain limited system information and to change the state of certain settings of a vulnerable system. Successful exploitation could allow an attacker to gain insight into internal services and workflows and to make unauthorized changes that may disrupt the normal operation of the affected service. |
| Privilege escalation vulnerabilities exist in the API of HPE Networking Fabric Composer. Successful exploitation could allow an authenticated low privilege operator user to complete state-changing actions that should not be allowed by their current level of authorization on the platform, including changes to the configuration of systems managed by the affected product. |
| A business logic vulnerability exists in the API of HPE Networking Fabric Composer. Successful exploitation could allow an authenticated low privilege operator user to obtain elevated privileges and modify settings beyond what is authorized by the user's existing privilege level on a vulnerable system. |
| A vulnerability in the underlying operating system of HPE Networking Fabric Composer could allow an unauthenticated adjacent attacker to run arbitrary commands on the underlying host if certain preconditions outside of the attacker's control are met. Successful exploitation could allow an attacker to execute arbitrary commands on the underlying operating system. |
| Local privilege-escalation vulnerabilities have been discovered in HPE Networking Fabric Composer. Successful exploitation of these vulnerabilities could allow a local attacker to achieve arbitrary code execution with root privileges on the underlying operating system of the affected system. |
| Insecure file operations in the API of HPE Networking Fabric Composer could allow an authenticated remote attacker to achieve remote code execution. Successful exploitation could allow an attacker to execute arbitrary commands as a privileged user on the underlying operating system. |
| Vulnerabilities in the API of HPE Networking Fabric Composer could allow an authenticated remote attacker to conduct SQL injection attacks against the HPE Networking Fabric Composer instance. An attacker could exploit these vulnerabilities to obtain and modify sensitive information in the underlying database potentially leading to complete compromise of the HPE Networking Fabric Composer host. |
| Command injection vulnerabilities in the web-based management interface of HPE Networking Fabric Composer could allow an authenticated remote attacker to perform command injection against the affected system. Successful exploitation could allow an attacker to execute arbitrary commands as a privileged user on the underlying operating system. |
| go-redis is the official Redis client library for the Go programming language. Prior to 9.5.5, 9.6.3, and 9.7.2, go-redis potentially responds out of order when `CLIENT SETINFO` times out during connection establishment. This can happen when the client is configured to transmit its identity, there are network connectivity issues, or the client was configured with aggressive timeouts. The problem occurs for multiple use cases. For sticky connections, you receive persistent out-of-order responses for the lifetime of the connection. All commands in the pipeline receive incorrect responses. When used with the default ConnPool once a connection is returned after use with ConnPool#Put the read buffer will be checked and the connection will be marked as bad due to the unread data. This means that at most one out-of-order response before the connection is discarded. This issue is fixed in 9.5.5, 9.6.3, and 9.7.2; however, 9.7.2 has been yanked and 9.7.3 is the lowest available patched version on the 9.7.x branch. As a workaround, set the flag `DisableIndentity` to `true` when constructing the client instance. |
| In the Linux kernel, the following vulnerability has been resolved:
net: shaper: reject duplicate leaves in GROUP request
net_shaper_nl_group_doit() does not deduplicate NET_SHAPER_A_LEAVES
entries. When userspace supplies the same leaf handle twice, the same
old-parent pointer lands twice in old_nodes[]. The cleanup loop double
frees the parent. Of course the same parent may still be in old_nodes[]
twice if we are moving multiple of its leaves.
Note that this patch also implicitly fixes the fact that the
i >= leaves_count path forgets to set ret. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: cortina: Carry over frag counter
The gmac_rx() NAPI poll function assembles packets in an
SKB from a ring buffer.
If the ring buffer gets completely emptied during a poll cycle,
we exit gmac_rx(), but the packet is not yet completely
assembled in the SKB, yet the fragment counter frag_nr is
reset to zero on the next invocation.
Solve this by making the RX fragment counter a part of the
port struct, and carry it over between invocations.
Reset the fragment counter only right after calling
napi_gro_frags(), on error (after calling napi_free_frags())
or if stopping the port.
Reset it in some place where not strictly necessary just to
emphasize what is going on.
This was found by Sashiko during normal patch review. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: cortina: Make RX SKB per-port
The SKB used to assemble packets from fragments in gmac_rx()
is static local, but the Gemini has two ethernet ports, meaning
there can be races between the ports on a bad day if a device
is using both.
Make the RX SKB a per-port variable and carry it over between
invocations in the port struct instead.
Zero the pointer once we call napi_gro_frags(), on error (after
calling napi_free_frags()) or if the port is stopped.
Zero it in some place where not strictly necessary just to
emphasize what is going on.
This was found by Sashiko during normal patch review. |
| In the Linux kernel, the following vulnerability has been resolved:
afs: Fix the locking used by afs_get_link()
The afs filesystem in the kernel doesn't do locking correctly for symbolic
links. There are a number of problems:
(1) It doesn't do any locking around afs_read_single() to prevent races
between multiple ->get_link() calls, thereby allowing the possibility
of leaks.
(2) It doesn't use RCU barriering when accessing the buffer pointers
during RCU pathwalk.
(3) It can race with another thread updating the contents of the symlink
if a third party updated it on the server.
Fix this by the following means:
(0) Move symlink handling into its own file as this makes it more
complicated.
(1) Take the validate_lock around afs_read_single() to prevent races
between multiple ->get_link() calls.
(2) Keep a separate copy of the symlink contents with an rcu_head. This
is always going to be a lot smaller than a page, so it can be
kmalloc'd and save quite a bit of memory. It also needs a refcount
for non-RCU pathwalk.
(3) Split the symlink read and write-to-cache routines in afs from those
for directories.
(4) Discard the I/O buffer as soon as the write-to-cache completes as this
is a full page (plus a folio_queue).
(5) If there's no cache, discard the I/O buffer immediately after reading
and copying if there is no cache. |
