| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page
nvmet_execute_disc_get_log_page() validates only the dword alignment
of the host-supplied Log Page Offset (lpo). The 64-bit offset is then
added to a small kzalloc'd buffer that holds the discovery log page
and the result is passed straight to nvmet_copy_to_sgl(), which
memcpy()s data_len bytes out to the host with no source-side bound
check:
u64 offset = nvmet_get_log_page_offset(req->cmd); /* 64-bit host */
size_t data_len = nvmet_get_log_page_len(req->cmd); /* 32-bit host */
...
if (offset & 0x3) { ... } /* only check */
...
alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);
buffer = kzalloc(alloc_len, GFP_KERNEL);
...
status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);
The Discovery controller is unauthenticated -- nvmet_host_allowed()
returns true unconditionally for the discovery subsystem -- so the call
is reachable pre-authentication by any TCP/RDMA/FC peer that can reach
the nvmet target. With a discovery log page of ~1 KiB, an attacker
requesting up to 4 KiB starting at offset == alloc_len reads the next
slab page out and gets its content returned over the fabric (an
empirical run on a default nvmet-tcp loopback target leaked 81
canonical kernel pointers in one Get Log Page response). Pointing the
offset at unmapped kernel memory faults the in-kernel memcpy and
crashes (or panics, on panic_on_oops=1) the target host instead.
The attacker-controlled source-side offset pattern
"nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique
to nvmet_execute_disc_get_log_page in the entire nvmet codebase: every
other Get Log Page handler in admin-cmd.c either ignores lpo (and
silently starts every response at offset 0) or tracks a local
destination offset with a fixed source pointer.
Validate the host-supplied offset against the log page size, cap the
copy length to what is actually available, and zero-fill any remainder
of the host transfer buffer. The zero-fill matches the existing
short-response pattern in nvmet_execute_get_log_changed_ns()
(admin-cmd.c) and prevents leaking transport SGL contents when the
host asks for more bytes than the log page contains. |
| In the Linux kernel, the following vulnerability has been resolved:
udf: validate sparing table length as an entry count, not a byte count
udf_load_sparable_map() accepts a sparing table when
sizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize
is false, i.e. it treats reallocationTableLen as a number of BYTES that
must fit in the block. But the table is walked as an array of 8-byte
sparingEntry elements:
for (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) {
struct sparingEntry *entry = &st->mapEntry[i];
... entry->origLocation ...
}
in udf_get_pblock_spar15() and udf_relocate_blocks(). A
reallocationTableLen of N therefore passes the check whenever
sizeof(*st) + N <= blocksize, yet the consumers index
sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the
block. On a crafted UDF image this is an out-of-bounds read in
udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the
same length to udf_update_tag(), whose crc_itu_t() reads far past the
block, and its memmove() through st->mapEntry[] is an out-of-bounds
write.
Validate reallocationTableLen as the entry count it is, with
struct_size(). |
| In the Linux kernel, the following vulnerability has been resolved:
udf: validate VAT header length against the VAT inode size
udf_load_vat() takes the virtual partition's start offset straight from
the on-disk VAT 2.0 header without checking it against the VAT inode
size:
map->s_type_specific.s_virtual.s_start_offset =
le16_to_cpu(vat20->lengthHeader);
map->s_type_specific.s_virtual.s_num_entries =
(sbi->s_vat_inode->i_size -
map->s_type_specific.s_virtual.s_start_offset) >> 2;
lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds
the VAT inode size, the s_num_entries subtraction underflows to a huge
count, which defeats the "block > s_num_entries" bound in
udf_get_pblock_virt15(); and on the ICB-inline path that function reads
((__le32 *)(iinfo->i_data + s_start_offset))[block]
so a large s_start_offset indexes past the inode's in-ICB data. Mounting
a crafted UDF image with a virtual (VAT) partition then triggers an
out-of-bounds read.
Reject a VAT whose header length does not leave room for at least one
entry within the VAT inode. |
| In the Linux kernel, the following vulnerability has been resolved:
net: af_key: initialize alg_key_len for IPComp states
pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by
allocating x->calg and copying only the algorithm name:
x->calg = kmalloc_obj(*x->calg);
if (!x->calg) {
err = -ENOMEM;
goto out;
}
strcpy(x->calg->alg_name, a->name);
x->props.calgo = sa->sadb_sa_encrypt;
Unlike the authentication (x->aalg) and encryption (x->ealg) branches of
the same function, the compression branch never initializes
calg->alg_key_len. IPComp carries no key and the allocation only
reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field
is left containing uninitialized slab data.
calg->alg_key_len is later used as a length by xfrm_algo_clone() when an
IPComp state is cloned during XFRM_MSG_MIGRATE:
xfrm_state_migrate()
xfrm_state_clone_and_setup()
x->calg = xfrm_algo_clone(orig->calg);
kmemdup(orig, xfrm_alg_len(orig));
where xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8. With
a non-zero garbage alg_key_len, kmemdup() reads past the end of the
68-byte calg object. Adding an IPComp SA via PF_KEY and then migrating
it triggers (net-next, KASAN, init_on_alloc=0):
BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60
Read of size 4164 at addr ff11000025a74980 by task diag2/9287
CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1
Call Trace:
<TASK>
dump_stack_lvl+0x10e/0x1f0
print_report+0xf7/0x600
kasan_report+0xe4/0x120
kasan_check_range+0x105/0x1b0
__asan_memcpy+0x23/0x60
kmemdup_noprof+0x44/0x60
xfrm_state_migrate+0x70a/0x1da0
xfrm_migrate+0x753/0x18a0
xfrm_do_migrate+0xb47/0xf10
xfrm_user_rcv_msg+0x411/0xb50
netlink_rcv_skb+0x158/0x420
xfrm_netlink_rcv+0x71/0x90
netlink_unicast+0x584/0x850
netlink_sendmsg+0x8b0/0xdc0
____sys_sendmsg+0x9f7/0xb90
___sys_sendmsg+0x134/0x1d0
__sys_sendmsg+0x16d/0x220
do_syscall_64+0x116/0x7d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
Allocated by task 9287:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0xaa/0xb0
pfkey_add+0x2652/0x2ea0
pfkey_process+0x6d0/0x830
pfkey_sendmsg+0x42c/0x850
__sys_sendto+0x461/0x4b0
__x64_sys_sendto+0xe0/0x1c0
do_syscall_64+0x116/0x7d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ff11000025a74980
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 0 bytes inside of
allocated 68-byte region [ff11000025a74980, ff11000025a749c4)
Depending on the uninitialized value the same field can instead request
an oversized kmemdup() allocation and make the migration clone fail.
The XFRM netlink path is not affected: verify_one_alg() rejects an
XFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via
XFRM_MSG_NEWSA is always self-consistent.
Initialize calg->alg_key_len to 0, matching the aalg/ealg branches. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl()
Two IE parsing loops are missing the header bounds checks before they
dereference pIE->length:
- issue_assocreq() walks pmlmeinfo->network.ies to build the
association request. If the stored IE data ends with only an
element_id byte and no length byte, pIE->length is read one byte
past the end of the buffer.
- join_cmd_hdl() walks pnetwork->ies during station join and has
the same problem under the same conditions.
Both buffers are filled from AP beacon and probe-response frames, so a
malicious AP that sends a truncated final IE can trigger the issue.
Apply the two-guard pattern established in update_beacon_info():
1. Break if fewer than sizeof(*pIE) bytes remain.
2. Break if the IE's declared data extends past the buffer end. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop
The IE parsing loop in update_beacon_info() advances by
(pIE->length + 2) each iteration but only guards on i < len.
When a malicious AP sends a Beacon whose last IE has only one byte
remaining in the frame (the element_id byte lands at len-1), the loop
reads pIE->length from one byte past the allocated receive buffer.
Additionally, even when the header bytes are in bounds, pIE->length
itself can extend the data window beyond len, passing a truncated IE
to the handler functions.
Add two guards at the top of the loop body:
1. Break if fewer than sizeof(*pIE) bytes remain (can't read header).
2. Break if the IE's declared data extends past len.
Also replace i += (pIE->length + 2) with i += sizeof(*pIE) + pIE->length
for consistency with the sizeof(*pIE) guards added above. |
| In the Linux kernel, the following vulnerability has been resolved:
hwrng: virtio: clamp device-reported used.len at copy_data()
random_recv_done() stores the device-reported used.len directly into
vi->data_avail. copy_data() then indexes vi->data[] using
vi->data_idx (advanced by previous copy_data() calls) and issues a
memcpy() without re-validating either value against the posted
buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32
or 64).
A malicious or buggy virtio-rng backend can set used.len beyond
sizeof(vi->data), steering the memcpy() past the end of the inline
array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes
those bytes into the guest RNG, and guest root can also observe
them directly via /dev/hwrng.
Concrete impact is inside the guest:
- Memory-safety / hardening: any virtio-rng backend that
over-reports used.len causes the driver to read past vi->data
into unrelated slab contents. hwrng_fillfn() is a kernel thread
that runs as soon as the device is probed; no guest userspace
interaction is required to first-trigger the OOB.
- Cross-boundary leak (confidential-compute threat model): a
malicious hypervisor cooperating with a malicious or compromised
guest root userspace can use /dev/hwrng as a leak channel for
guest-kernel heap data. The host sets a large used.len, guest
root reads /dev/hwrng, and the returned bytes contain guest
kernel slab contents that were adjacent to vi->data. In
practice, confidential-compute guests (SEV-SNP, TDX) usually
disable virtio-rng entirely, so this path is narrow, but the
fix is still worth carrying because the underlying
memory-safety bug contaminates the guest RNG on any host.
KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend
has been patched to report used.len = 0x10000:
BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0
Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52
Call Trace:
__asan_memcpy+0x23/0x60
virtio_read+0x394/0x5d0
hwrng_fillfn+0xb2/0x470
kthread+0x2cc/0x3a0
Allocated by task 1:
probe_common+0xa5/0x660
virtio_dev_probe+0x549/0xbc0
The buggy address belongs to the object at ffff88800ae0b800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 0 bytes to the right of
allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)
Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer
overflow in USB transport layer"), which hardened
usb9pfs_rx_complete() against unchecked device-reported length in
the USB 9p transport.
With the clamp at point of use and array_index_nospec() in place,
the same harness boots cleanly: copy_data() returns zero for the
bogus report, the device-supplied bytes after data_idx are
discarded, and the driver issues a fresh request. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: gyro: bmg160: bail out when bandwidth/filter is not in table
bmg160_get_filter() walks bmg160_samp_freq_table[] looking for the entry
matching the bw_bits value read from the chip:
for (i = 0; i < ARRAY_SIZE(bmg160_samp_freq_table); ++i) {
if (bmg160_samp_freq_table[i].bw_bits == bw_bits)
break;
}
*val = bmg160_samp_freq_table[i].filter;
If no entry matches, i ends up equal to the array size and the next line
reads one slot past the end. bmg160_set_filter() has the same shape, driven
by 'val' instead of bw_bits.
smatch flags both:
drivers/iio/gyro/bmg160_core.c:204 bmg160_get_filter() error:
buffer overflow 'bmg160_samp_freq_table' 7 <= 7
drivers/iio/gyro/bmg160_core.c:222 bmg160_set_filter() error:
buffer overflow 'bmg160_samp_freq_table' 7 <= 7
Return -EINVAL when no entry matches.
The set_filter() path is reachable from userspace via the sysfs
in_anglvel_filter_low_pass_3db_frequency interface, so userspace can
trivially trigger the out-of-bounds read with a value that is not in
bmg160_samp_freq_table[].filter. |
| Coturn is a free open source implementation of TURN and STUN Server. From 4.5.2 through 4.14.0, when Coturn is started with --acme-redirect <URL> and exposes a plaintext-TCP listener, an unauthenticated remote client can send a single ordinary HTTP GET request and receive a 301 response whose Location header contains up to ~870 bytes of adjacent process heap memory. The leaked region is a recycled network receive buffer that is reused without being zeroed, so on a busy server it can contain data from other clients' requests (TURN credentials, OAuth tokens, relayed payloads). Root cause is a signed→unsigned conversion. This issue is fixed in version 4.15.0. |
| An out-of-bounds read flaw was found in Samba's Kerberos Key Distribution Center's (KDC) password change (kpasswd) service. When processing malformed ASN.1-encoded Kerberos password change request, Samba server miscalculates the structure size and attempts to read up to six bytes beyond the end of the allocated buffer. While this out-of-bounds read typically results in a harmless decryption failure, if the read hits unmapped memory, it causes the KDC process to crash. An authenticated attacker can send a specially crafted kpasswd request containing malformed ASN.1 data to trigger the out-of-bounds read, which may cause the KDC process to terminate, resulting in a denial of service. |
| Inappropriate implementation in Frame in Google Chrome prior to 151.0.7922.72 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: Low) |
| Out of bounds read in Dawn in Google Chrome prior to 151.0.7922.72 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: Low) |
| A crafted IEC 60870-5-104 I-frame with a declared object count exceeding
what fits in the ASDU body causes InformationObject_ParseObjectAddress
to read one byte past the end of the heap-allocated message buffer. |
| The GOOSE parser contains an off-by-one boundary-handling flaw that can
be triggered by a single unauthenticated Layer-2 multicast frame on the
process bus. When specific GOOSE message fields are processed, the
parser advances its internal buffer position incorrectly, resulting in a
heap out-of-bounds read. On affected platforms, this condition reliably
terminates the subscriber process and causes a denial-of-service. |
| Out of bounds read in WebXR in Google Chrome prior to 151.0.7922.72 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: Medium) |
| facil.io 0.7.5 through 0.7.6 contains a denial-of-service vulnerability in the HTTP/1.1 chunked transfer encoding parser that allows unauthenticated remote attackers to crash the server by sending a negative chunk size value. Attackers can send a single POST request with a Transfer-Encoding: chunked header containing a leading minus sign in the chunk size field, causing the parser in http1_parser.h to compute a large positive integer from the negated value, corrupting internal state and moving the read pointer into unmapped memory resulting in a fault. |
| facil.io 0.6.0 through 0.7.6 contains an integer underflow vulnerability in the multipart MIME body parser that allows unauthenticated remote attackers to crash the server process by sending a crafted Content-Disposition header with an empty field name. Attackers can trigger a uint32_t wraparound in http_mime_parser.h causing an out-of-bounds memory read past the name pointer, resulting in a bus fault that crashes the handling worker with a single POST request. |
| Out of bounds read in WebGL in Google Chrome prior to 151.0.7922.72 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: Medium) |
| Out of bounds read in Skia in Google Chrome on Mac prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: High) |
| A crafted IEC 60870-5-104 I-frame with TypeID 104 (C_TS_NA_1) and an
inflated object count causes TestCommand_getFromBuffer to read one byte
past the end of the heap-allocated message buffer. |
