| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory. |
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1376. |
| Out-of-bounds read in Windows Storage Spaces Controller allows an authorized attacker to disclose information locally. |
| An out-of-bounds read issue was addressed with improved input validation. This issue is fixed in macOS Golden Gate 27. Mounting a maliciously crafted exFAT volume may cause unexpected system termination or kernel memory disclosure. |
| A slab-out-of-bound read problem was found in brcmf_get_assoc_ies in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c in the Linux Kernel. This issue could occur when assoc_info->req_len data is bigger than the size of the buffer, defined as WL_EXTRA_BUF_MAX, leading to a denial of service. |
| Out of bounds read in WebGL in Google Chrome on on Android prior to 153.0.8010.47 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Critical) |
| A maliciously crafted TIF file, when parsed through certain Autodesk products during image import, can cause an Out-of-Bounds Read in the image handling library. A malicious actor can leverage this vulnerability to cause a denial of service |
| Improper state validation in Skia in Google Chrome prior to 153.0.8010.47 allowed a remote attacker who had compromised the renderer process to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| XML::LibXML versions through 2.0210 for Perl read out-of-bounds heap memory when parsing XML node names containing truncated UTF-8 byte sequences.
A node name ending in the middle of a multi byte UTF-8 sequence causes the parser to read past the end of the input string into adjacent heap memory.
Any Perl process that passes attacker controlled strings to XML::LibXML's DOM node-name methods can reach this path on the default API. The likely consequence is a crash, causing denial of service. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath
When cifs_sanitize_prepath is called with an empty string or a string
containing only delimiters (e.g., "/"), the current logic attempts to
check *(cursor2 - 1) before cursor2 has advanced. This results in an
out-of-bounds read.
This patch adds an early exit check after stripping prepended
delimiters. If no path content remains, the function returns NULL.
The bug was identified via manual audit and verified using a
standalone test case compiled with AddressSanitizer, which
triggered a SEGV on affected inputs. |
| Imager versions from 0.45_02 before 1.035 for Perl read outside the EXIF block via unchecked start offsets in tiff_load_ifd.
tiff_load_ifd() validates an IFD entry's data by checking that `entry->offset + entry->size` stays within the EXIF block, and never checks the start offset itself. Where that sum is not the real end of the data, the check passes with the entry starting outside the block.
Through 1.032 `entry->offset` is a plain int, so on the usual two's-complement implementations an offset with the high bit set converts to negative and the sum can land back inside the block. From 1.033 the field is a size_t and the addition wraps only where size_t is 32 bits. The IFD's own start offset is checked the same way and wraps where unsigned long is 32 bits, which includes 64-bit Windows.
Any caller of Imager->read() on an attacker-supplied image may receive EXIF tags holding bytes from outside the block, or crash the process. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/gud: NUL-terminate TV mode names read from the device
gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from
the USB device and passes pointers into it to
drm_mode_create_tv_properties_legacy(), which calls strlen() on each one.
Nothing guarantees the device NUL-terminates a name, so strlen() can run
past the end of a slot and, for the last mode, past the end of the
allocation.
Terminate each name at the end of its slot before use. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: clamp the isolation index for rings outside a partition
adev->isolation[] has one slot per partition, but a ring that is not
assigned to one keeps AMDGPU_XCP_NO_PARTITION, which is ~0, so indexing
the array with it is out of bounds. SDMA submissions hit this on both
the isolation enforcement and the VM flush path and trip UBSAN.
Fall back to the first slot the way the cleaner shader path already
does, and stop taking the address before the ring type check that makes
it relevant. |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: afs: validate v2 image info bounds
The AFS v2 parser uses footer[8] to locate the image information block
inside the current erase block, then uses the image information
region_count to walk entries from a fixed local array. The footer offset
and region count come from flash contents and are not checked against the
erase block or the local image-info array before use.
Reject v2 entries whose image information offset would underflow the
erase block calculation, and reject region counts that cannot fit in the
local image-info array before walking region entries. |
| In the Linux kernel, the following vulnerability has been resolved:
LoongArch: BPF: Refactor jump offset calculation in tail call
The old macro-based jmp_offset calculation derives the jump distance
from a stale prior-pass code stride, which can lead to wrong branch
offsets and soft lockups under extra JIT passes.
Fix this by calculating the offset directly on the absolute target:
"ctx->offset[insn + 1] - ctx->idx".
To avoid a false 16-bit range check abort during size estimation, add
a "ctx->image == NULL" guard to inject a safe dummy offset. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: rmi: fix OOB access with undersized RMI reports
The hid-rmi driver sizes its writeReport/readReport buffer purely from
the report descriptor supplied by the device, with no minimum bound:
data->input_report_size = hid_report_len(input_report);
data->output_report_size = hid_report_len(output_report);
alloc_size = data->output_report_size + data->input_report_size;
data->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL);
data->readReport = data->writeReport + data->output_report_size;
but then reads and writes fixed offsets into it. A device declaring a
1-byte output and a 1-byte input report makes hid_report_len() return 2
for each, so alloc_size is 4, while rmi_set_page() -- reached
unconditionally at probe time through rmi_input_configured() -- stores
writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since
readReport lives at writeReport + output_report_size, those stores also
corrupt the window the next reply is parsed out of.
The read path is worse: the copy length comes from readReport[1], which
the device fills in and can be up to 255, and the copy starts at
&readReport[2] with no regard for input_report_size, so it runs past the
end of the allocation into adjacent slab objects. This does not even
need a lying device -- rmi_f01_probe() issues a fixed 21-byte register
read, so any device declaring an input report smaller than 23 bytes
reads out of bounds even when it answers truthfully. Those bytes become
the register values the RMI core acts on: rmi_f01_probe() prints them to
the kernel log as the product id and exports them through the mode 0444
sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends
them back to the device as the interrupt mask, so an undersized report
descriptor leaks heap contents both to unprivileged userspace and to the
device itself.
The write path has no bound either: rmi_hid_write_block() copies an
unbounded len to &writeReport[4], and the largest caller a device can
drive at probe time is rmi_driver_set_irq_bits(), whose length is
derived from the interrupt source counts the device declares in its Page
Description Table.
Finally, the read loop cannot terminate on a zero-length reply: such a
reply copies nothing and advances neither bytes_read nor bytes_needed,
and because a reply did arrive the one second wait_event_timeout() does
not fire either, so a device answering 0 forever keeps the loop running
inside the probe worker with page_mutex held. khungtaskd does not
notice, because every reply wakes the task.
Reject reports too small for what the driver builds -- 6 output bytes
for the write reports and 3 input bytes for the read handshake -- at
probe time, clamp the write and the read copy to the report sizes the
device declared, and treat a zero-length reply as an error. A device
refused this way is started as an ordinary HID device, like one that
does not carry the RMI report ids at all.
RMI_DEVICE must not be left set in device_flags on that path, because
rmi_input_configured() would then run the RMI setup and reach
rmi_set_page(), which writes the writeReport buffer the refusal just
skipped allocating. The bit can arrive set: rmi_probe() copies
id->driver_data into device_flags before the report checks, and a bind
through the new_id sysfs attribute can supply driver_data with
RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so
RMI_DEVICE keeps meaning exactly "this probe validated the reports"; the
three jumps to start that predate this patch are covered as well.
The error path also clears RMI_READ_DATA_PENDING on its way out, because
that flag is what the wait at the top of the loop tests: leaving it set
would make every later wait_event_timeout() return immediately on the
stale reply and kill the read path for the rest of the device's life.
Clamping does not regress working hardware: the read loop already
handles
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
HID: wacom: validate report length in wacom_intuos_pro2_bt_irq
wacom_intuos_pro2_bt_irq() receives the wire report length in `len`
but never consults it before parsing. After the report-id gate it
unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by
features.type, a fixed chain of sub-parsers, none of which receive
`len`:
wacom_intuos_pro2_bt_pen(wacom);
if (type == INTUOSP2_BT || type == INTUOSP2S_BT) {
wacom_intuos_pro2_bt_touch(wacom);
wacom_intuos_pro2_bt_pad(wacom);
wacom_intuos_pro2_bt_battery(wacom);
} else {
wacom_intuos_gen3_bt_pad(wacom);
wacom_intuos_gen3_bt_battery(wacom);
}
Each sub-parser dereferences wacom->data at fixed offsets. The furthest
byte touched on each branch is:
INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285]
(the touchring byte), so the report must be at least 286 bytes;
INTUOSHT3_BT ("gen3"): wacom_intuos_gen3_bt_battery() reads data[45],
so the report must be at least 46 bytes.
features.type is selected from the VID/PID id_table entry and
wacom_setup_device_quirks() force-registers the pen/pad/touch inputs
for that type independent of the report descriptor, so a malicious or
malfunctioning paired/spoofed Bluetooth peripheral can advertise that
VID/PID and send an undersized report that still satisfies the
data[0] == 0x80/0x81 gate. The driver then reads past the received
report and forwards the bytes to userspace via evdev (MSC_SERIAL /
ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds
read with a concrete userspace read-back channel, and a true
out-of-bounds read on transports whose backing buffer is sized to the
(small) report descriptor rather than a fixed-size staging buffer.
This is the same class of bug commit 2f1763f62909 ("HID: wacom: fix
out-of-bounds read in wacom_intuos_bt_irq") already hardened in the
sibling wacom_intuos_bt_irq(), which guards each report id against its
minimum length before parsing.
Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject
reports shorter than the furthest offset the selected branch actually
dereferences, warn, and bail out. Because the whole pen/touch/pad/
battery chain runs unconditionally per branch, a single up-front check
against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT,
46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on
a short report also skips those calls for the same malformed report,
which is the safe, conservative behavior. |
| In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: return early from a zero-length flush
SYNC_BO does not constrain its size, so a request for zero bytes reaches
drm_clflush_virt_range(), which ends with an unconditional
clflushopt(end - 1). For an empty range that is the byte before the
mapping, and abo->mem.kva comes from vmap(), so the access lands in the
guard page below the vmalloc area and faults:
BUG: unable to handle page fault for address: ffffd16fbbc70fff
#PF: supervisor read access in kernel mode
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 7 UID: 1000 Comm: sync_bo_probe
RIP: 0010:drm_clflush_virt_range+0x3c/0x70
Call Trace:
amdxdna_drm_sync_bo_ioctl+0x124/0x430 [amdxdna]
drm_ioctl+0x301/0x4c0
__x64_sys_ioctl+0x115/0x2f0
do_syscall_64+0xa6/0x3d0
Any process that can open the render node can do this. Reproduced 3 of 3
times on a Strix Point NPU (1022:17f0), by calling SYNC_BO with size 0 on
an AMDXDNA_BO_SHARE object. The import arm takes the same request but
flushes the whole scatterlist, so it survives it.
Nothing needs flushing for an empty range, so answer before choosing a
path. |
| In the Linux kernel, the following vulnerability has been resolved:
media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure
rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(),
rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and
shares a single err: label that only unlocks the mutex and returns.
When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs()
itself returns -ENOMEM after alloc_stream_bufs() has already succeeded,
the URBs and/or the coherent DMA stream buffers stay allocated while
streaming reports failure to vb2. Two latent defects follow on the next
VIDIOC_STREAMON:
1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num
to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently
leaking the coherent DMA memory allocated by the previous attempt.
2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only
increments it. After a second successful pass urbs_initialized can
exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks
from urbs_initialized - 1 down to 0 and reads past the end of
dev->urb_list[], passing garbage pointers to usb_free_urb().
Mirror the teardown that stop_streaming() already performs: on the error
path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs()
before unlocking. Both helpers are idempotent (free_urbs kills and zeros
urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the
buf_num counter), so partial-failure paths and the no-allocation paths
remain safe.
Issue identified by automated review of the INV-003 series at
https://sashiko.dev/ |
| Out-of-bounds read in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally. |
