| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btintel_pcie: validate device-supplied DMA indices
In btintel_pcie_msix_rx_handle(), the driver processes RX completion
descriptors (urbd1) written by the PCIe device into DMA-coherent memory.
urbd1->frbd_tag (a 16-bit field fully controlled by the device firmware
via DMA) is used directly as an array index into rxq->bufs[] without any
bounds check. rxq->bufs[] has only BTINTEL_PCIE_RX_DESCS_COUNT (64)
entries, while frbd_tag can be any value 0-65535. A malicious or
malfunctioning device can write an out-of-range frbd_tag, causing the
driver to dereference an out-of-bounds data_buf pointer.
Additionally, cr_hia is read from a DMA-shared index array also writable
by the device; if the device sets cr_hia >= rxq->count, the while-loop
never terminates because cr_tia is wrapped via modulo rxq->count and can
never equal an out-of-range cr_hia.
Add bounds validation for cr_hia and frbd_tag in the RX path, and cr_hia
in the TX path. Log invalid values with bt_dev_err before returning. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/clk: fix list cursor use after loop in nvkm_clk_ustate_update
If list_for_each_entry() exits without hitting a break then "pstate" is
not a valid pstate pointer. Introduce a "found" variable instead.
The check is reachable from userspace: nvkm_clk_ustate_update() takes the
pstate id straight from the 'pstate' debugfs file, so requesting an id
that is not in clk->states - or any id at all when the perf tables are
broken and the list is empty - makes the pstate->pstate != req test
dereference the list head cast to a struct nvkm_pstate, which is an
out-of-bounds read.
[Francesco: rebased on drm-misc-next, expanded the commit message] |
| Mongoose is an embedded web server and network library. Prior to 7.23, the built-in TLS stack selected by MG_TLS_BUILTIN in src/tls_builtin.c accepts a TLS 1.3 record whose decrypted size is exactly the 16-byte authentication tag with no plaintext or ContentType byte. In mg_tls_recv_record(), the msgsz length check permits that record and the recv_len calculation underflows to SIZE_MAX, so a later handshake step treats stale buffer contents as a trusted message with an effectively unbounded length. An unauthenticated malicious TLS peer can trigger a heap out-of-bounds read before certificate or Finished validation, causing a remote denial of service. This issue is fixed in version 7.23. |
| Mongoose is an embedded web server and network library. Prior to 7.23, the built-in TLS certificate parser selected by MG_TLS_BUILTIN fails to verify that a long-form DER element length fits within the remaining certificate buffer. In mg_der_to_tlv() and mg_der_next(), a peer-controlled length can advance the parser beyond the certificate and underflow the remaining uint32_t length, causing mg_tls_parse_cert_der() to continue walking an invalid pointer. An unauthenticated malicious TLS server, or a client presenting a certificate to a server configured for client certificates, can trigger an out-of-bounds read and denial of service during the handshake. This issue is fixed in version 7.23. |
| Mongoose is an embedded web server and network library. Prior to 7.23, ppp_handle_ipv6cp() in src/l2_ppp.c trusts the 16-bit IPv6CP len field without checking it against the received payload size. On a PPP or PPPoE link using MG_ENABLE_TCPIP and MG_ENABLE_IPV6, an unauthenticated adjacent peer can complete the required LCP exchange and send a short Configure-Request with an oversized length, causing ppp_tx_frame() to read beyond recv_queue.buf and write beyond tx.buf. The same length misuse can also expose adjacent heap bytes in a reply or hang the event loop through find_opt(). This issue is fixed in version 7.23. |
| In the Linux kernel, the following vulnerability has been resolved:
xsk: Use a 32-bit compare in xsk_map_gen_lookup
xsk_map_gen_lookup() loads a u32 key and compares it with max_entries
using BPF_JMP_IMM. BPF immediates are sign-extended to 64 bits, so a
max_entries value of 0x80000000 or higher becomes a threshold larger
than every zero-extended 32-bit key. An out-of-range index then skips
the bounds check and the generated lookup reads past xsk_map[].
Compare with BPF_JMP32_IMM so the check stays in 32-bit unsigned range. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: amd_sfh: Validate PCI BAR size before mapping
The amd_sfh driver maps PCI BAR 2 using pcim_iomap_regions() and
subsequently accesses MMIO registers at offsets up to 0x10958 (e.g.,
AMD_P2C_MSG3 at 0x1068C). However, the driver never validates that the BAR
size is large enough to cover these accesses. If the driver is bound to a
device with a smaller BAR 2, this leads to an out-of-bounds memory access
and a page fault during the probe function.
For example, a page fault can occur when reading from privdata->mmio +
AMD_P2C_MSG3 in mp2_select_ops():
BUG: unable to handle page fault for address: ffffc9000390368c
PGD 100000067 P4D 100000067 PUD 1012c1067 PMD 105b64067 PTE 0
Oops: Oops: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline]
RIP: 0010:mp2_select_ops drivers/hid/amd-sfh-hid/amd_sfh_pcie.c:282
[inline]
RIP: 0010:amd_mp2_pci_probe+0x337/0x5f0
drivers/hid/amd-sfh-hid/amd_sfh_pcie.c:487
Call Trace:
<TASK>
local_pci_probe drivers/pci/pci-driver.c:332 [inline]
pci_call_probe drivers/pci/pci-driver.c:394 [inline]
__pci_device_probe drivers/pci/pci-driver.c:455 [inline]
pci_device_probe+0x431/0xc90 drivers/pci/pci-driver.c:489
Fix this by verifying that the length of BAR 2 is at least 128KB before
attempting to map it. Since the maximum accessed offset is 0x10958, and PCI
BAR sizes are powers of 2, any legitimate hardware will have a BAR size of
at least 128KB. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/uv: Prevent potential out-of-bounds read
When the system has more than 85 secrets, the uv_secret_list struct
array only holds up to 85 items per page, resulting in an out of bounds
read in find_secret_in_page if the targeted secret is in the next page
or not stored at all.
Fix this by looping over the number of stored secrets which is the
per sub-list count of stored secrets and not the overall count. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: proximity: aw96103: validate firmware data length
The firmware parser reads a length from the binary header and then uses
it to walk six-byte register/value entries. A truncated firmware image
can make the parser read beyond the copied firmware buffer. A value
smaller than the four-byte count field also underflows, producing a very
large length.
Read the little-endian field with get_unaligned_le32(), as previously
proposed by David Lechner. Validate the header size, reject an
underflowed length, ensure the resulting payload is contained in the
firmware image, and require it to contain whole register/value entries. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: bnep: fix out-of-bounds reads on short RX/TX frames and control fallthrough
Fix multiple out-of-bounds reads in Bluetooth BNEP frame processing:
1. In bnep_rx_frame() and bnep_ctrl_frame() (net/bluetooth/bnep/core.c),
use pskb_may_pull() to verify the BNEP header, control type byte,
filter count, and extension headers exist before reading them, and
return 0 after handling BNEP_CONTROL instead of falling through to
Ethernet frame submission when no extension headers follow.
2. In bnep_net_xmit() (net/bluetooth/bnep/netdev.c), verify skb->len >=
ETH_HLEN with pskb_may_pull() before reading the 14-byte Ethernet
header to prevent an out-of-bounds heap read and infoleak on short
AF_PACKET TX frames. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Preserve packet pointer class displacement in regsafe()
regsafe() maps packet pointer IDs between states and checks that each
current register range is a subset of the corresponding explored
register range. It does not, however, preserve the displacement between
registers that share a packet pointer ID.
This is unsound because packet range is shared by ID. A bounds check on
one class member updates every member, and a later access can consume the
range through another member. Commit 022ac0750883 ("bpf: use reg->var_off
instead of reg->off for pointers") folded the fixed pointer offset into
r64 and removed the old off equality check, so two individually narrower
registers can prune even when their displacement has changed. The
explored path can then license an out-of-bounds packet access on the
pruned path.
Require matching range bases for packet pointers with an ID. Together
with the existing ID mapping, this preserves the displacement between
members of each packet-pointer class without adding per-ID state.
Packet pointers without an ID remain unaffected. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix out-of-bounds read of rtt_min in sock_ops
A sockops prog reading skops->rtt_min never checks the sk type: on the
tcp_conn_request() path sock_ops->sk is a request_sock (non-full), and the
ctx rewrite casts it to a tcp_sock (full) and reads rtt_min past the end of
the request_sock, returning dirty adjacent memory.
SEC("sockops")
int prog(struct bpf_sock_ops *skops)
{
switch (skops->op) {
case BPF_SOCK_OPS_RWND_INIT:
leak = skops->rtt_min; /* reads the request_sock OOB */
...
}
}
For instance one such read returned rtt_min=0xffff8881, the high half of a
leaked kernel pointer.
Guarding that cast is exactly what SOCK_OPS_GET_FIELD() does -- it checks
is_locked_tcp_sock and returns 0 when sock_ops->sk is not a locked full
socket. Every other tcp_sock field in sock_ops goes through it; rtt_min is
the only one open-coded, so it skips the check.
Read rtt_min through SOCK_OPS_GET_FIELD() too. rtt_min is a bit special:
it is a struct minmax and we only want the current min, so pass
rtt_min.s[0].v. That is equivalent to the old hand-computed offset
offsetof(struct tcp_sock, rtt_min) + sizeof_field(struct minmax_sample, t)
(s[0] sits at rtt_min + 0 and .v at + sizeof(.t), i.e. what minmax_get()
returns), so the loaded field is unchanged and only the full-sock guard is
added. The two BUILD_BUG_ON()s that protected the hand-computed offset
are no longer needed.
Before patch:
0: r1 = *(u64 *)(r1 +0) ; r1 = skops->sk
1: r1 = *(u32 *)(r1 +2324) ; ((tcp_sock *)sk)->rtt_min.s[0].v
After patch:
0: *(u64 *)(r1 +56) = r9
1: r9 = *(u8 *)(r1 +50) ; is_locked_tcp_sock
2: if r9 == 0 goto pc+4 ; not a locked full sock -> 0
3: r9 = *(u64 *)(r1 +56)
4: r1 = *(u64 *)(r1 +0) ; r1 = skops->sk
5: r1 = *(u32 *)(r1 +2324) ; rtt_min.s[0].v
6: goto pc+2
7: r9 = *(u64 *)(r1 +56)
8: r1 = 0 |
| A corrupted file may cause out-of-bounds read in HPE NonStop SQL/MX EXE under certain conditions, potentially leading to information disclosure, process termination, CPU halt, or data corruption. |
| Out of bounds read in Focus in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Out of bounds read in FileSystem in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Out of bounds read in GetUserMedia in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| llama.cpp builds b4882 before b8487 contain an out-of-bounds read vulnerability in the recurrent memory state restore path that allows attackers with write access to the slot save directory to read memory past the end of the allocated cells array. Attackers can craft a malicious slot file with an oversized seq_id value to trigger an out-of-bounds read that leaks heap data including pointer values into server logs, defeating ASLR protections and facilitating further exploitation. |
| Out of bounds read in Installer in Google Chrome on on Mac prior to 156.0.8078.47 allowed a remote attacker to potentially read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Out of bounds read in Payments in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Out of bounds read in SiteIsolation in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to read memory inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
