| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability in the API of HPE Networking Fabric Composer could allow an unauthenticated remote attacker to conduct a denial of service attack. Successful exploitation could allow an attacker to disrupt the availability of the affected interface. |
| A remote code execution vulnerability exists in the underlying operating system of HPE Networking Fabric Composer that could allow an unauthenticated remote 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 as a privileged user on the underlying operating system, leading to complete compromise of the HPE Networking Fabric Composer host. |
| A command injection vulnerability exists in the web-based management interface of HPE Networking Fabric Composer that could allow an unauthenticated remote 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 leading to complete system compromise. |
| A vulnerability in the web-based management interface of HPE Networking Fabric Composer could allow an unauthenticated remote attacker to access sensitive information if the attacker can convince an authenticated user of the interface to interact with a specially crafted URL. Successful exploitation could allow an attacker to retrieve information which could be used to potentially gain further access to network services supported by HPE Networking Fabric Composer. |
| An arbitrary file write vulnerability exists in the API of HPE Networking Fabric Composer and could allow an authenticated administrative user to escalate privileges. Successful exploitation of this vulnerability may enable the attacker to execute arbitrary system commands with root privileges on the underlying operating 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. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| 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. |
| A weakness has been identified in RightNow-AI OpenFang up to 0.6.9. This vulnerability affects the function shell_exec of the file crates/openfang-runtime/src/tool_runner.rs. This manipulation causes uncontrolled memory allocation. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way. |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix netfs_read_folio() to wait on writeback
Fix netfs_read_folio() to wait for an ongoing writeback to complete so that
it can trust the dirty flag and whatever is attached to folio->private
(folio->private may get cleaned up by the collector before it clears the
writeback flag). |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix folio->private handling in netfs_perform_write()
Under some circumstances, netfs_perform_write() doesn't correctly
manipulate folio->private between NULL, NETFS_FOLIO_COPY_TO_CACHE, pointing
to a group and pointing to a netfs_folio struct, leading to potential
multiple attachments of private data with associated folio ref leaks and
also leaks of netfs_folio structs or netfs_group refs.
Fix this by consolidating the place at which a folio is marked uptodate in
one place and having that look at what's attached to folio->private and
decide how to clean it up and then set the new group. Also, the content
shouldn't be flushed if group is NULL, even if a group is specified in the
netfs_group parameter, as that would be the case for a new folio. A
filesystem should always specify netfs_group or never specify netfs_group.
The Sashiko auto-review tool noted that it was theoretically possible that
the fpos >= ctx->zero_point section might leak if it modified a streaming
write folio. This is unlikely, but with a network filesystem, third party
changes can happen. It also pointed out that __netfs_set_group() would
leak if called multiple times on the same folio from the "whole folio
modify section". |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix leak of request in netfs_write_begin() error handling
Fix netfs_write_begin() to not leak our ref on the request in the event
that we get an error from netfs_wait_for_read(). |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix early put of sink folio in netfs_read_gaps()
Fix netfs_read_gaps() to release the sink page it uses after waiting for
the request to complete. The way the sink page is used is that an
ITER_BVEC-class iterator is created that has the gaps from the target folio
at either end, but has the sink page tiled over the middle so that a single
read op can fill in both gaps.
The bug was found by KASAN detecting a UAF on the generic/075 xfstest in
the cifsd kernel thread that handles reception of data from the TCP socket:
BUG: KASAN: use-after-free in _copy_to_iter+0x48a/0xa20
Write of size 885 at addr ffff888107f92000 by task cifsd/1285
CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy)
Call Trace:
dump_stack_lvl+0x5d/0x80
print_report+0x17f/0x4f1
kasan_report+0x100/0x1e0
kasan_check_range+0x10f/0x1e0
__asan_memcpy+0x3c/0x60
_copy_to_iter+0x48a/0xa20
__skb_datagram_iter+0x2c9/0x430
skb_copy_datagram_iter+0x6e/0x160
tcp_recvmsg_locked+0xce0/0x1130
tcp_recvmsg+0xeb/0x300
inet_recvmsg+0xcf/0x3a0
sock_recvmsg+0xea/0x100
cifs_readv_from_socket+0x3a6/0x4d0 [cifs]
cifs_read_iter_from_socket+0xdd/0x130 [cifs]
cifs_readv_receive+0xaad/0xb10 [cifs]
cifs_demultiplex_thread+0x1148/0x1740 [cifs]
kthread+0x1cf/0x210 |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix potential deadlock in write-through mode
Fix netfs_advance_writethrough() to always unlock the supplied folio and to
mark it dirty if it isn't yet written to the end. Unfortunately, it can't
be marked for writeback until the folio is done with as that may cause a
deadlock against mmapped reads and writes.
Even though it has been marked dirty, premature writeback can't occur as
the caller is holding both inode->i_rwsem (which will prevent concurrent
truncation, fallocation, DIO and other writes) and ictx->wb_lock (which
will cause flushing to wait and writeback to skip or wait).
Note that this may be easier to deal with once the queuing of folios is
split from the generation of subrequests. |
