| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: validate TX status rate metadata
minstrel_ht_tx_status() converts the HT/VHT rate reported in a TX status
into a group and rate index and uses those to index the minstrel_ht rate
tables. The existing validation only checked that an entry was present
and had tries recorded; it did not check that the reported MCS, spatial
stream count and bandwidth are representable by the tables, so malformed
metadata passed to minstrel_ht_get_stats() or
minstrel_ht_ri_get_stats() could be used as an out-of-bounds index.
Validate the rate metadata in the common TX status path instead of only
in minstrel_ht, since the values are used by more than rate control.
The legacy ieee80211_tx_rate array and the rate_info based entries are
sanitized in ieee80211_tx_status_ext() and ieee80211_tx_rate_update()
before any consumer runs: an entry that does not describe a valid rate
for its encoding is dropped. minstrel_ht keeps the checks that depend
on its own tables, i.e. the supported number of spatial streams, the MCS
group size and the supported bandwidths.
This does not take away the driver's responsibility to report sane
values, it only prevents a single bad report from corrupting mac80211
state. No WARN_ON() is added: with panic_on_warn a driver bug would
otherwise turn into a denial of service. |
| Dimension is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. |
| The Okta Credential Provider for Windows does not validate a serialized credential buffer before interpreting it as a Kerberos logon structure. The buffer size and packed string offsets are not checked. Processing a malformed buffer can cause the credential provider process to terminate unexpectedly or lead to out-of-bounds memory reads and writes, which may result in the disclosure of adjacent process memory into local system logs. |
| A buffer overflow vulnerability in HPE NonStop RDMA SERVICES NSK may cause out-of-bounds memory write, which may result in memory corruption. |
| bincookie is a header-only binarycookies parser. Prior to 0.1.9, bincookie_init_file() in bincookie.h allocates a buffer using the actual .binarycookies file length but trusts the file-controlled num_pages field as the loop bound for byte-swapping page_sizes entries. A crafted file can make the loop read and write beyond the heap allocation, and related unvalidated page sizes and cookie_offsets can drive additional out-of-bounds accesses in page and cookie iteration. Applications that parse an attacker-supplied binarycookies file may crash or suffer heap corruption that can potentially enable code execution. This issue is fixed in version 0.1.9. |
| libInstPatch through 1.1.7 contains a heap out-of-bounds write vulnerability in the SoundFont 2 loader because ipatch_sf2_gen_is_valid() does not range-check generator IDs before the validity mask test. Attackers can supply crafted SF2 files with out-of-range pgen or igen generator IDs to write attacker-chosen values past the zone genarray, corrupting heap memory and crashing Swami or other consumers. |
| libsmi through 0.5.0 contains an out-of-bounds write vulnerability in smiValueAsString() in lib/smi.c that allows attackers to overflow a fixed 1024-byte static buffer through hex rendering of OCTET STRING values. Attackers can supply a crafted MIB with an OCTET STRING DEFVAL of 512 or more octets and a leading 0x00 byte to corrupt adjacent library globals and crash smidump or other consumers. |
| OpenJPH through 0.32.0 contains a heap out-of-bounds write vulnerability in the HTJ2K cleanup-pass decoder that allows attackers to corrupt memory via one-row codeblocks. Attackers can supply a crafted .j2c or .jph codestream with small precinct sizes, causing the decoder to write a second row past the codeblock buffer, resulting in memory corruption and crashes. |
| libTiMidity through 0.2.8 contains a stack out-of-bounds write vulnerability in the SoundFont loader that allows attackers to corrupt stack memory via unchecked generator operators in parse_gen. Attackers can supply a crafted .sf2 file with out-of-range pgen/igen operator values to write chosen 16-bit values near the stack Layer object, causing crashes and stack memory corruption. |
| libTiMidity through 0.2.8 contains an out-of-bounds access vulnerability in init_soundfont() in src/sndfont.c that allows attackers to corrupt memory by supplying unvalidated SF2 preset header bank and preset values. Attackers can craft a .sf2 file whose bank or preset indexes past the 128-entry tonebank or drumset arrays, causing heap memory reads, writes, and application crashes. |
| A maliciously crafted PDF file, when parsed through Autodesk Revit, can force an Out-of-Bounds Write vulnerability. A malicious actor may leverage this vulnerability to cause a crash, cause data corruption, or execute arbitrary code in the context of the current process. |
| A flaw was found in GIMP. When processing a specially crafted GIMPressionist preset file, the plug-in does not properly validate vector indices before writing into fixed-size arrays. This can lead to an out-of-bounds write, corrupting memory. An attacker could exploit this by convincing a user to load a malicious preset file, potentially causing a crash or enabling arbitrary code execution. |
| A flaw was found in GIMP. When processing a specially crafted lighting preset file, the Lighting Effects filter does not properly validate the number of light sources. This can lead to an out-of-bounds write, corrupting memory. An attacker could exploit this by convincing a user to open a malicious preset file, potentially causing a crash or enabling arbitrary code execution. |
| A flaw was found in GIMP's ICO file loader. When processing an ICO file containing an embedded PNG image, an integer overflow can occur during the calculation of the required buffer size. This leads to an undersized buffer being allocated, causing a heap-based buffer overflow when the decoded pixel data is written. A remote attacker could exploit this by crafting a malicious ICO file, which, when opened, could lead to arbitrary code execution or a crash. |
| A maliciously crafted MODEL file, when parsed through certain Autodesk products, can force an Out-of-Bounds Write vulnerability. A malicious actor may leverage this vulnerability to cause a crash, cause data corruption, or execute arbitrary code in the context of the current process. |
| A maliciously crafted X_T file, when parsed through certain Autodesk products, can force an Out-of-Bounds Write vulnerability. A malicious actor may leverage this vulnerability to cause a crash, cause data corruption, or execute arbitrary code in the context of the current process. |
| ExLlamaV3’s EXL3 loader uses an untrusted, model-supplied index to select a CUDA kernel without first verifying that the index is within bounds. A malicious model can force the code to read and invoke an out‑of‑range function pointer, resulting in a reproducible crash. Under specific conditions involving certain host memory layouts, it may be possible for an attacker to exploit this vulnerability to achieve controlled indirect kernel dispatch during model load. |
| A remote code execution vulnerability was found in libaom, the reference AV1 codec implementation. Insufficient bounds validation in the AV1 encoder's SVC (Scalable Video Coding) layer ID control allows an attacker to supply crafted video frame pixels that overlap with internal encoder layer context structures. In fork-based video processing services, an attacker can use this to hijack the cyclic refresh map pointer, brute-force the process base address via a crash oracle, and redirect control flow to achieve arbitrary command execution. Exploitation requires the target service to use libaom with SVC encoding enabled and accept attacker-supplied video frames. |
| An arbitrary address write vulnerability was found in libaom, the reference AV1 codec implementation. A missing bounds check in the SVC (Scalable Video Coding) layer ID control function allows an attacker to inject an arbitrary pointer into the cyclic refresh map field via crafted image pixel values. The encoder then writes approximately 1,200 bytes at the attacker-controlled address. This is fully deterministic and does not require a separate information leak. An attacker who can supply frames to a network-facing libaom encoder with SVC enabled could exploit this for denial of service or potential code execution. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf, arm64: set up the frame pointer for the exception callback
A program acting as exception boundary saves all callee-saved registers,
so build_prologue() takes the exception_cb path and never calls
push_callee_regs(). That is the only place find_used_callee_regs() runs,
and with it the only place ctx->fp_used is set, so the callback prologue
does not emit the
mov x25, sp
that points BPF_REG_FP at the frame the callback runs on. x25 keeps
whatever it held when bpf_throw() was called. If the throw came from a
subprogram that uses its own BPF stack, that is the subprogram's frame
pointer, and since the subprogram never returns it never restores x25
either.
Stack accesses through BPF_REG_FP are rewritten to be stack pointer
relative, so those still land in the callback's own frame. Materializing
the register does not: a callback that passes the address of a local
variable to a helper hands over an address in the dead subprogram's
frame. That address is below the callback's stack pointer by then, and
the helper's own call chain covers it, so the helper can write over its
own return address. 0x1234 below is the value the helper was asked to
store:
pc : 0x1234
lr : 0x1234
Call trace:
0x1234 (P)
bpf_test_run+0x188/0x3e0
bpf_prog_test_run_skb+0x47c/0x998
__sys_bpf+0xbdc/0xdd8
Kernel panic - not syncing: Oops: Fatal exception in interrupt
Set ctx->fp_used on the exception callback path so that the existing code
further down sets x25 from the stack pointer. The epilogue restores it
from the main program's save area along with the other callee-saved
registers, as it already does. x86 sets the frame pointer for the
callback from the argument it is passed, and powerpc computes it from
the stack pointer. |