| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Integer overflow or wraparound in Windows Device Health Attestation (DHA) allows an unauthorized attacker to execute code over a network. |
| jxl-oxide is a pure Rust implementation of a JPEG XL decoder. Prior to jxl-grid 0.6.2, decoding a crafted JPEG XL image on a 32-bit platform can overflow length calculations in AlignedGrid::with_alloc_tracker and related grid and subgrid arithmetic. A 65536 x 65536 frame can pass the frame-area limit while overflowing the usize element count, causing modular, VarDCT, or filter rendering paths to allocate a backing buffer smaller than the logical grid. A tiny bitstream-controlled cropped frame combined with a huge canvas or requested region can also reach the vulnerable composition path in crates/jxl-render/src/blend.rs through ordinary render_frame(). Later mutable subgrid and raw-pointer operations can then perform attacker-controlled out-of-bounds writes, causing memory corruption, denial of service, or arbitrary code execution. This issue is fixed in jxl-grid version 0.6.2. |
| libvips is a fast image processing library with low memory needs. The EXIF decoder within libvips versions before and including 8.18.1 was not verifying the range of EXIF tag groups before passing data to libexif, leading to a possible null pointer dereference and crash. This has been patched in version 8.18.2. |
| libvips is a fast image processing library with low memory needs. The `tiffload` operation in libvips versions before and including 8.18.1 could incorrectly determine the number of channels in a JPEG or JPEG2000-encoded tile within a TIFF image, leading to a possible buffer overflow. This has been patched in version 8.18.2. |
| A heap-based buffer overflow vulnerability was identified in TP-Link Tapo C100/C101 v5, C520WS v2.6 in the HTTP POST body parsing logic due to missing validation of remaining buffer capacity after dynamic allocation, due to insufficient boundary validation when handling externally supplied HTTP input.
An attacker
on the same network segment could trigger heap memory corruption conditions by
sending crafted payloads that cause write operations beyond allocated buffer
boundaries. Successful exploitation
causes a Denial-of-Service (DoS) condition, causing the device’s process to
crash or become unresponsive. |
| In Audio HAL, there is a possible out of bounds write due to a heap buffer overflow. This could lead to local denial of service with User execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS10960023 (Note: For MT6880, MT6890, MT6980D, MT6988, MT6990) / AUTO00851189 (Note: For MT2735, MT3737); Issue ID: MSV-7586. |
| Improper input validation in MPEG4 codec in libsavsvc.so prior to SMR Aug-2026 Release 1 allows local attackers to write out-of-bounds memory. |
| In the Linux kernel, the following vulnerability has been resolved:
perf/x86/amd/brs: Fix kernel address leakage
A user-only branch stack can contain branches that originate from
the kernel. As a result, kernel addresses are exposed to user space
even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors
supporting X86_FEATURE_BRS (Zen 3 only), perf can still report entries
such as SYSRET/interrupt returns for which the branch-from addresses
are in the kernel.
E.g.
$ perf record -j any,u -c 4000 -e branch-brs -o - -- \
perf bench syscall basic --loop 1000 | \
perf script -i - -F brstack|tr ' ' '\n'| \
grep -E '0x[89a-f][0-9a-f]{15}'
...
0xffffffff810001c4/0x72e2e32955eb/-/-/-/0//-
0xffffffff810001c4/0x72e2d94a9821/-/-/-/0//-
0xffffffff810001c4/0x72e2d94ffa1b/-/-/-/0//-
...
BRS provides no hardware branch filtering, so privilege level
filtering is performed entirely in software. However, amd_brs_match_plm()
only validates the branch-to address against the requested privilege
levels. For branches from the kernel to user space, the branch-from
address is left unchecked and is leaked. Extend the software filter to
also validate the branch-from address, so that any branch record whose
branch-from address is in the kernel is dropped when
PERF_SAMPLE_BRANCH_USER is requested. |
| In the Linux kernel, the following vulnerability has been resolved:
mips: sched: Fix CPUMASK_OFFSTACK memory corruption
This patch addresses a critical memory management flaw. When
CONFIG_CPUMASK_OFFSTACK is enabled, cpumask_var_t is a pointer.
Consequently, sizeof(new_mask) evaluates to the pointer size, causing
copy_from_user() to clobber the mask pointer. Furthermore, the old
logic performed copy_from_user() before allocating the mask.
Fix this by allocating new_mask first. To handle variable-sized user
masks correctly, use cpumask_size() to truncate overly large user masks
or pad undersized masks with zeros before copying the data directly into
the allocated buffer. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()
The `ims_pcu_process_data()` processes incoming URB data byte by byte.
However, it fails to check if the `read_pos` index exceeds
IMS_PCU_BUF_SIZE.
If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE,
`read_pos` will increment indefinitely. Moreover, since `read_pos` is
located immediately after `read_buf`, the attacker can overwrite
`read_pos` itself to arbitrarily control the index.
This manipulated `read_pos` is subsequently used in
`ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a
heap buffer overflow.
Specifically, an attacker can overwrite the `cmd_done.wait.head` located
at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`.
Consequently, when the driver calls `complete(&pcu->cmd_done)`, it
triggers a control flow hijack by using the manipulated pointer.
Fix this by adding a bounds check for `read_pos` before writing to
`read_buf`. If the packet is too long, discard it, log a warning,
and reset the parser state.
[dtor: factor out resetting packet state, reset checksum as well] |
| A vulnerability was detected in Open Asset Import Library Assimp 17c12da. This affects the function Assimp::MDLImporter::AddBonesToNodeGraph_3DGS_MDL7 of the file code/AssetLib/MDL/MDLLoader.cpp of the component Node Parser. The manipulation of the argument bones_num results in heap-based buffer overflow. The attack can be executed remotely. The exploit is now public and may be used. The project was informed of the problem early through an issue report but has not responded yet. |
| A heap-based out-of-bounds write vulnerability exists in S2OPC 1.7.3 in server-side EventFilter handling during CreateMonitoredItems processing. This allows a remote attacker to execute arbitrary code. |
| hashcat master branch builds after v7.1.2 contain a heap buffer overflow vulnerability in the KeePass AESKDF/KDBX v4 module (module 34301) that allows attackers to corrupt adjacent heap memory by supplying an oversized ninth hash field token. The module accepts up to 600 hex characters for the ninth token field but decodes it into a fixed 256-byte buffer with no length check, allowing a maximal input to write up to 44 bytes past the buffer boundary into adjacent esalt fields and heap chunk metadata, potentially enabling heap corruption or memory access violations. |
| When compute mode is enabled on a standalone mongod instance, insufficient validation of externally sourced BSON data during aggregation pipeline processing can result in memory corruption, potentially leading to process termination or other unintended behavior. This configuration is non-default and requires explicit enablement at startup. |
| Heap-based buffer overflow in Windows Telephony Service allows an authorized attacker to elevate privileges locally. |
| A security flaw has been discovered in Open Asset Import Library Assimp 17c12da. Impacted is the function Assimp::Compression::decompressBlock of the file code/Common/Compression.cpp of the component File Parser. Performing a manipulation results in heap-based buffer overflow. The attack may be initiated remotely. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet. |
| Heap-based buffer overflow in Windows DNS allows an authorized attacker to elevate privileges locally. |
| In the Linux kernel, the following vulnerability has been resolved:
binder: cache secctx size before release zeroes it
binder_transaction() bounds the scatter-gather buffer area with
sg_buf_end_offset and subtracts the aligned LSM context size because
the secctx is written at the tail of that area. The subtraction reads
lsmctx.len, but that field has already been cleared by the time the
line runs:
security_secid_to_secctx(secid, &lsmctx) /* lsmctx.len set */
lsmctx_aligned_size = ALIGN(lsmctx.len, sizeof(u64))
extra_buffers_size += lsmctx_aligned_size
...
security_release_secctx(&lsmctx) /* memset zeroes len */
...
sg_buf_end_offset = sg_buf_offset + extra_buffers_size
- ALIGN(lsmctx.len, sizeof(u64)) /* ALIGN(0,8) */
security_release_secctx() does memset(cp, 0, sizeof(*cp)), so lsmctx.len
reads back as 0 and the subtraction contributes nothing, leaving
sg_buf_end_offset too large by the aligned secctx size on every
transaction to a txn_security_ctx node.
Each BINDER_TYPE_PTR object then derives buf_left = sg_buf_end_offset -
sg_buf_offset as the sole upper bound on its copy, so the inflated end
offset lets the copy run into the bytes that already hold the secctx.
The aligned size must therefore be cached before release rather than
re-read from the now-cleared field. Fix by caching it in
lsmctx_aligned_size at function scope when it is first computed and
subtracting lsmctx_aligned_size instead of re-reading lsmctx.len after
release. Reuse the same value for the earlier buf_offset computation. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ife: require ETH_HLEN to be pullable in ife_decode()
ife decode may return after making only the outer IFE header and
metadata pullable. The caller then passes the decapsulated packet to
eth_type_trans(), which expects the inner Ethernet header to be
accessible from the linear data area.
With a malformed IFE frame, the inner Ethernet header may still be
shorter than ETH_HLEN in the linear area, which can lead to a crash in
the original code.
Fix this by extending the pull check in ife_decode() so that the inner
Ethernet header is also guaranteed to be pullable before returning. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet-auth: reject short AUTH_RECEIVE buffers
nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length
after checking only that it is nonzero and matches the transfer length.
In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF
initiator reach the fixed-size DH-HMAC-CHAP response builders with a
kmalloc() buffer shorter than the response, so nvmet_auth_success1() and
nvmet_auth_failure1() write past the allocation; both only WARN_ON the
short length and then format the message anyway.
Impact: A remote NVMe-oF initiator with access to an auth-enabled target
can trigger a 16-byte heap out-of-bounds write via a one-byte
AUTH_RECEIVE allocation length.
Compute the minimum response length for the current DH-HMAC-CHAP step in
nvmet_auth_receive_data_len() and report a zero data length when the
host-supplied allocation length is shorter, so the existing zero-length
check in nvmet_execute_auth_receive() rejects the command before any
builder runs. The SUCCESS1 minimum is sizeof(struct
nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the
response hash is written into the rval[] flexible-array tail, so the
minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its
existing variable-length guard in nvmet_auth_challenge().
This is reachable only when in-band DH-HMAC-CHAP authentication is
configured on the target. |
