| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A stack-based buffer overflow vulnerability in Fortinet FortiOS 7.6.0 through 7.6.3, FortiOS 7.4.0 through 7.4.8, FortiOS 7.2 all versions, FortiOS 7.0 all versions, FortiOS 6.4 all versions allows attacker to execute unauthorized code or commands via specially crafted packets |
| Certain HP LaserJet Pro, HP LaserJet Enterprise, and HP LaserJet Managed Printers may potentially be vulnerable to Remote Code Execution and Elevation of Privilege when processing a PostScript print job. |
| Certain HP LaserJet Pro, HP LaserJet Enterprise, and HP LaserJet Managed Printers may potentially be vulnerable to Remote Code Execution and Elevation of Privilege when processing a PostScript print job. |
| Certain HP DesignJet print products are potentially vulnerable to information disclosure related to accessing memory out-of-bounds when using the general-purpose gateway (GGW) over port 9220. |
| A stack-based buffer overflow vulnerability in Fortinet FortiOS 7.6.0 through 7.6.3, FortiOS 7.4.0 through 7.4.8, FortiOS 7.2 all versions, FortiOS 7.0 all versions, FortiOS 6.4 all versions, FortiOS 6.2 all versions, FortiOS 6.0 all versions, FortiSASE 25.3.b allows attacker to execute unauthorized code or commands via specially crafted packets |
| zlib versions up to and including 1.3.1.2 include a global buffer overflow in the untgz utility located under contrib/untgz. The vulnerability is limited to the standalone demonstration utility and does not affect the core zlib compression library. The flaw occurs when a user executes the untgz command with an excessively long archive name supplied via the command line, leading to an out-of-bounds write in a fixed-size global buffer. |
| A stack-based buffer overflow vulnerability [CWE-121] vulnerability in Fortinet FortiCamera 2.1.0 through 2.1.3, FortiCamera 2.0 all versions, FortiCamera 1.1 all versions, FortiMail 7.6.0 through 7.6.2, FortiMail 7.4.0 through 7.4.4, FortiMail 7.2.0 through 7.2.7, FortiMail 7.0.0 through 7.0.8, FortiNDR 7.6.0, FortiNDR 7.4.0 through 7.4.7, FortiNDR 7.2.0 through 7.2.4, FortiNDR 7.0.0 through 7.0.6, FortiRecorder 7.2.0 through 7.2.3, FortiRecorder 7.0.0 through 7.0.5, FortiRecorder 6.4.0 through 6.4.5, FortiVoice 7.2.0, FortiVoice 7.0.0 through 7.0.6, FortiVoice 6.4.0 through 6.4.10 allows a remote unauthenticated attacker to execute arbitrary code or commands via sending HTTP requests with specially crafted hash cookie. |
| There is a Stack overflow Vulnerability in the device Search and Discovery feature of Hikvision NVR/DVR/CVR/IPC models. If exploited, an attacker on the same local area network (LAN) could cause the device to malfunction by sending specially crafted packets to an unpatched device. |
| There is a Stack overflow Vulnerability in the device Search and Discovery feature of Hikvision Access Control Products. If exploited, an attacker on the same local area network (LAN) could cause the device to malfunction by sending specially crafted packets to an unpatched device. |
| Improper Validation of Array Index (CWE-129) in Packetbeat’s MongoDB protocol parser can allow an attacker to cause Overflow Buffers (CAPEC-100) through specially crafted network traffic. This requires an attacker to send a malformed payload to a monitored network interface where MongoDB protocol parsing is enabled. |
| Buffer overflow vulnerability in function dcputchar in decompile.c in libming 0.4.8. |
| Buffer overflow vulnerability in function strcat in asan_interceptors.cpp in libming 0.4.8. |
| A stack-based buffer overflow exists in the GoAhead-Webs HTTP daemon on KuWFi 4G LTE AC900 devices with firmware 1.0.13. The /goform/formMultiApnSetting handler uses sprintf() to copy the user-supplied pincode parameter into a fixed 132-byte stack buffer with no bounds checks. This allows an attacker to corrupt adjacent stack memory, crash the web server, and (under certain conditions) may enable arbitrary code execution. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
Some Viridian hypercalls can specify a mask of vCPU IDs as an input, in
one of three formats. Xen has boundary checking bugs with all three
formats, which can cause out-of-bounds reads and writes while processing
the inputs.
* CVE-2025-58147. Hypercalls using the HV_VP_SET Sparse format can
cause vpmask_set() to write out of bounds when converting the bitmap
to Xen's format.
* CVE-2025-58148. Hypercalls using any input format can cause
send_ipi() to read d->vcpu[] out-of-bounds, and operate on a wild
vCPU pointer. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
Some Viridian hypercalls can specify a mask of vCPU IDs as an input, in
one of three formats. Xen has boundary checking bugs with all three
formats, which can cause out-of-bounds reads and writes while processing
the inputs.
* CVE-2025-58147. Hypercalls using the HV_VP_SET Sparse format can
cause vpmask_set() to write out of bounds when converting the bitmap
to Xen's format.
* CVE-2025-58148. Hypercalls using any input format can cause
send_ipi() to read d->vcpu[] out-of-bounds, and operate on a wild
vCPU pointer. |
| Heap-based buffer overflow in Windows DWM Core Library allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows Routing and Remote Access Service (RRAS) allows an unauthorized attacker to execute code over a network. |
| Heap-based buffer overflow in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally. |
| libcoap versions up to and including 4.3.5, prior to commit 30db3ea, contain a stack-based buffer overflow in address resolution when attacker-controlled hostname data is copied into a fixed 256-byte stack buffer without proper bounds checking. A remote attacker can trigger a crash and potentially achieve remote code execution depending on compiler options and runtime memory protections. Exploitation requires the proxy logic to be enabled (i.e., the proxy request handling code path in an application using libcoap). |
| In the Linux kernel, the following vulnerability has been resolved:
i40e: remove read access to debugfs files
The 'command' and 'netdev_ops' debugfs files are a legacy debugging
interface supported by the i40e driver since its early days by commit
02e9c290814c ("i40e: debugfs interface").
Both of these debugfs files provide a read handler which is mostly useless,
and which is implemented with questionable logic. They both use a static
256 byte buffer which is initialized to the empty string. In the case of
the 'command' file this buffer is literally never used and simply wastes
space. In the case of the 'netdev_ops' file, the last command written is
saved here.
On read, the files contents are presented as the name of the device
followed by a colon and then the contents of their respective static
buffer. For 'command' this will always be "<device>: ". For 'netdev_ops',
this will be "<device>: <last command written>". But note the buffer is
shared between all devices operated by this module. At best, it is mostly
meaningless information, and at worse it could be accessed simultaneously
as there doesn't appear to be any locking mechanism.
We have also recently received multiple reports for both read functions
about their use of snprintf and potential overflow that could result in
reading arbitrary kernel memory. For the 'command' file, this is definitely
impossible, since the static buffer is always zero and never written to.
For the 'netdev_ops' file, it does appear to be possible, if the user
carefully crafts the command input, it will be copied into the buffer,
which could be large enough to cause snprintf to truncate, which then
causes the copy_to_user to read beyond the length of the buffer allocated
by kzalloc.
A minimal fix would be to replace snprintf() with scnprintf() which would
cap the return to the number of bytes written, preventing an overflow. A
more involved fix would be to drop the mostly useless static buffers,
saving 512 bytes and modifying the read functions to stop needing those as
input.
Instead, lets just completely drop the read access to these files. These
are debug interfaces exposed as part of debugfs, and I don't believe that
dropping read access will break any script, as the provided output is
pretty useless. You can find the netdev name through other more standard
interfaces, and the 'netdev_ops' interface can easily result in garbage if
you issue simultaneous writes to multiple devices at once.
In order to properly remove the i40e_dbg_netdev_ops_buf, we need to
refactor its write function to avoid using the static buffer. Instead, use
the same logic as the i40e_dbg_command_write, with an allocated buffer.
Update the code to use this instead of the static buffer, and ensure we
free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on
multiple devices, and allows us to remove the now unused static buffer
along with removing the read access. |
