| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| ION-DTN versions before 4.2.0 contain an out-of-bounds read vulnerability in the decodeSdnv function that allows unauthenticated remote attackers to read memory by sending truncated SDNV values. Attackers can send a UDP datagram to the LTP link service input port with a truncated SDNV to trigger reads up to nine bytes past buffer boundaries and underflow byte counters. |
| A flaw was found in the AFP backend in gvfs. When mounting a share, a malicious AFP server can cause the DSI read path to process a length that exceeds the size requested by the client. The function does not verify the server-provided length against the pre-sized reply buffer, causing the operation to access past the intended boundaries. This issue allows a malicious server to overflow a heap buffer and crash the gvfsd-afp process, resulting in a denial of service. |
| A double stack-based buffer overflow was found in the BlueZ AVRCP controller implementation. A nearby BR/EDR peripheral can send a crafted AVRCP player-settings response that supplies an attacker-controlled attribute count, causing avrcp_list_player_attributes_rsp() and avrcp_get_current_player_value() in profiles/audio/avrcp.c to write attacker-controlled data past fixed-size stack buffers, potentially leading to a crash or code execution in the bluetoothd daemon. |
| node-forge through 1.4.0 fails to validate element count in nested DigestAlgorithm sequences during RSA PKCS#1 v1.5 signature verification. Attackers can embed garbage bytes inside the DigestAlgorithm sequence to forge valid signatures for arbitrary messages using low-exponent RSA keys. This is an incomplete fix for CVE-2026-33894. |
| A potential security vulnerability has been identified in the HP Support
Assistant for versions prior to 9.53.2.0. The vulnerability
could potentially allow a local attacker to escalate
privileges due to insufficient access controls. |
| A maliciously constructed mail header could lead to a one byte read past the end of a buffer. This vulnerability was fixed in Thunderbird 155, Thunderbird 140.15, and Thunderbird 153.2. |
| Buffer overflow in GPU in Google Chrome on on Windows prior to 152.0.7977.75 allowed a remote attacker who had compromised the renderer process to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Buffer Overflow vulnerability in Shenzhen Jixiang Tengda Technology Co., Ltd. Tenda A18 v.15.13.07.09 allows a remote attacker to execute arbitrary code via the fromSetCmdlineRun function |
| A denial-of-service security issue exists within FactoryTalk® Historian Machine Edition. A network adjacent attacker who is authenticated could send crafted requests to the web interface, resulting in buffer overflow conditions that may cause the device to crash and become unresponsive. |
| There is an out of bounds write vulnerability due to improper bounds checking resulting in a large destination address when parsing a DSB file with Digilent DASYLab. This vulnerability may result in arbitrary code execution. Successful exploitation requires an attacker to get a user to open a specially crafted DSB file. The vulnerability affects all versions of DASYLab. |
| In the Linux kernel, the following vulnerability has been resolved:
hwmon: (pmbus/adm1266) reject implausible blackbox record_count
adm1266_nvmem_read_blackbox() loops over a record_count that comes
straight from byte 3 of the BLACKBOX_INFO response. The destination
buffer is data->dev_mem, sized for the nvmem cell's declared 2048
bytes (ADM1266_BLACKBOX_MAX_RECORDS * ADM1266_BLACKBOX_SIZE = 32 * 64).
A device that reports a record_count greater than 32 -- whether due
to firmware bugs, bus corruption, or a non-responsive slave returning
0xff -- would walk read_buff past the end of the dev_mem allocation
on the trailing iterations.
Cap record_count at ADM1266_BLACKBOX_MAX_RECORDS (introduced here)
before entering the loop and return -EIO on any larger value, so a
malformed BLACKBOX_INFO response cannot drive the loop out of bounds. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler
The OTG branch of composite_setup() falls back to the first
configuration when none is selected:
if (cdev->config)
config = cdev->config;
else
config = list_first_entry(&cdev->configs,
struct usb_configuration, list);
if (!config)
goto done;
...
memcpy(req->buf, config->descriptors[0], value);
list_first_entry() never returns NULL. On an empty list it returns
container_of() of the list head. So the "if (!config)" check is dead.
When cdev->configs is empty, config points at the head inside struct
usb_composite_dev. config->descriptors[0] reads whatever sits at that
offset. The memcpy copies up to w_length bytes of it into the response
buffer.
cdev->configs can be empty in two cases. One is a teardown race on
gadget unbind with a control transfer in flight. The other is a driver
that sets is_otg before it adds a config. A reproducer that holds
cdev->configs empty triggers a KASAN fault in this branch.
Use list_first_entry_or_null() so the existing check does its job. |
| In the Linux kernel, the following vulnerability has been resolved:
net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()
kalmia_rx_fixup() computes usb_packet_length = skb->len - (2 *
KALMIA_HEADER_LENGTH) as a u16, guarded only by a pre-loop check that
skb->len is at least KALMIA_HEADER_LENGTH, which is 6. A device can
deliver a short bulk-IN frame with skb->len in the 6 to 11 range, or
leave a short trailing remainder on a later loop iteration. Either case
underflows usb_packet_length to about 65530.
That bypasses the usb_packet_length < ether_packet_length truncation path.
The device-supplied ether_packet_length, a le16 up to 65535 read from
header_start[2], then drives a memcmp() and the following skb_trim() and
skb_pull() past the end of the rx buffer. The rx buffer is hard_mtu * 10,
which is 14000 bytes. That is an out of bounds read.
Require both the start and end framing headers to be present before
subtracting them, on every loop iteration. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: misc: usbio: bound bulk IN response length to the received transfer
usbio_bulk_msg() copies bpkt_len = le16_to_cpu(bpkt->len) bytes out of
the bulk IN buffer (usbio->rxbuf, allocated with size usbio->rxbuf_len)
into the caller's buffer. bpkt_len is fully controlled by the device
and is only checked against ibuf_len; ibuf_len in turn is checked
against usbio->txbuf_len, not against rxbuf_len:
if ((obuf_len > (usbio->txbuf_len - sizeof(*bpkt))) ||
(ibuf_len > (usbio->txbuf_len - sizeof(*bpkt))))
return -EMSGSIZE;
txbuf_len and rxbuf_len are taken independently from the bulk OUT and
bulk IN endpoint wMaxPacketSize in usbio_probe(). A malicious or
malfunctioning device that advertises a large bulk OUT endpoint and a
small bulk IN endpoint (e.g. by claiming one of the quirk-free IDs such
as the Lattice NX33U, 0x2ac1:0x20cb) therefore makes ibuf_len, and
hence the device-supplied bpkt_len, exceed rxbuf_len. memcpy() then
reads up to txbuf_len - rxbuf_len bytes past the end of the rxbuf slab
object. The over-read bytes are handed back to the i2c layer and on to
user space through i2c-dev, disclosing adjacent slab memory; with KASAN
this is reported as a slab-out-of-bounds read.
The number of bytes actually received is already known: act equals the
URB actual_length and is bounded by rxbuf_len. Reject any response
that claims more payload than was received, mirroring the existing
"act < sizeof(*bpkt)" check just above.
The control path (usbio_ctrl_msg()) is not affected: it uses a single
buffer (ctrlbuf) for both directions, so its analogous copy can never
leave the allocation.
Found by code review. The out-of-bounds read was confirmed under
AddressSanitizer with a faithful userspace model of usbio_bulk_msg()'s
receive path (an rxbuf_len-sized buffer, the same act/ibuf_len/bpkt_len
checks and the memcpy). A USB raw-gadget + dummy_hcd reproducer is
also available. |
| In the Linux kernel, the following vulnerability has been resolved:
partitions: aix: bound the pp_count scan to the ppe array
aix_partition() reads the physical volume descriptor into a fixed-size
struct pvd and then scans its physical-partition-extent array:
int numpps = be16_to_cpu(pvd->pp_count);
...
for (i = 0; i < numpps; i += 1) {
struct ppe *p = pvd->ppe + i;
...
lp_ix = be16_to_cpu(p->lp_ix);
pvd points at a single kmalloc()'d struct pvd whose ppe[] member holds a
fixed ARRAY_SIZE(pvd->ppe) (1016) entries, but the loop runs up to the
on-disk pp_count. pp_count is an unvalidated __be16 read straight from
the descriptor, so a crafted AIX image with pp_count larger than 1016
drives the loop to read pvd->ppe[i] past the end of the allocation (up
to 65535 entries, ~2 MB out of bounds).
The partition scan runs without mounting anything, when a block device
with a crafted AIX/IBM partition table appears (an attacker-supplied
image attached with losetup -P, or a device auto-scanned by udev), via
msdos_partition() -> aix_partition().
Clamp the scan to the number of entries the ppe[] array can hold. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix heap buffer overflow in rtw_cfg80211_set_wpa_ie()
supplicant_ie is a 256-byte array in struct security_priv. The WPA and
WPA2 IE copy paths use:
memcpy(padapter->securitypriv.supplicant_ie, &pwpa[0], wpa_ielen + 2);
where wpa_ielen is the raw IE length field (u8, 0-255). When a local user
supplies a connect request via nl80211 with a crafted WPA IE of length 255,
wpa_ielen + 2 equals 257, overflowing the 256-byte buffer by one byte into
the adjacent last_mic_err_time field.
rtw_parse_wpa_ie() does not prevent this: its length consistency check
compares *(wpa_ie+1) against (u8)(wpa_ie_len-2), which is (u8)(255) == 255
when wpa_ie_len = 257, so the check passes silently.
Add explicit bounds checks for both the WPA and WPA2 paths before the
memcpy, rejecting any IE whose total size (wpa_ielen + 2) exceeds the
supplicant_ie buffer. |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix netfs_read_to_pagecache() to pause on subreq failure
Fix netfs_read_to_pagecache() so that it pauses the generation of new
subrequests if an already-issued subrequest fails. |
| async-tar is a tar archive reading/writing library for async Rust. Prior to version 0.6.1, async-tar mis-applies a buffered PAX size extension to an intermediary extension header (a GNU longname L, a GNU longlink K, or a PAX x/g header) instead of to the next file entry. POSIX requires a PAX extended-header record set to describe the next file entry, never an intervening extension header. Because poll_next_raw (src/archive.rs) threads the buffered PAX records into the size computation of whatever raw header it reads next — and that header can be an intermediary L — the stream cursor is advanced by an attacker-chosen amount when the L body is consumed. The parser then desyncs relative to a POSIX-correct tar parser (e.g. GNU tar), reading subsequent bytes at the wrong block boundary. This issue has been patched in version 0.6.1. |
| Out-of-bounds Write and Improper Validation of Array Index vulnerability in Samsung Open Source TizenFX Samsung/TizenFX allows Overflow Buffers. |
| Error in handling the PlatformLangCodes UEFI variable could cause a buffer overflow, leading to resource exhaustion and failure. |
