| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v3-its: Avoid truncating memory addresses
On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem
allocations to be backed by addresses physical memory above the 32-bit
address limit, as found while experimenting with larger VMSPLIT
configurations.
This caused the qemu virt model to crash in the GICv3 driver, which
allocates the 'itt' object using GFP_KERNEL. Since all memory below
the 4GB physical address limit is in ZONE_DMA in this configuration,
kmalloc() defaults to higher addresses for ZONE_NORMAL, and the
ITS driver stores the physical address in a 32-bit 'unsigned long'
variable.
Change the itt_addr variable to the correct phys_addr_t type instead,
along with all other variables in this driver that hold a physical
address.
The gicv5 driver correctly uses u64 variables, while all other irqchip
drivers don't call virt_to_phys or similar interfaces. It's expected that
other device drivers have similar issues, but fixing this one is
sufficient for booting a virtio based guest. |
| In the Linux kernel, the following vulnerability has been resolved:
ipv4: ip_gre: make ipgre_header() robust
Analog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")
Over the years, syzbot found many ways to crash the kernel
in ipgre_header() [1].
This involves team or bonding drivers ability to dynamically
change their dev->needed_headroom and/or dev->hard_header_len
In this particular crash mld_newpack() allocated an skb
with a too small reserve/headroom, and by the time mld_sendpack()
was called, syzbot managed to attach an ipgre device.
[1]
skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0
kernel BUG at net/core/skbuff.c:213 !
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Workqueue: mld mld_ifc_work
RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213
Call Trace:
<TASK>
skb_under_panic net/core/skbuff.c:223 [inline]
skb_push+0xc3/0xe0 net/core/skbuff.c:2641
ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897
dev_hard_header include/linux/netdevice.h:3436 [inline]
neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618
NF_HOOK_COND include/linux/netfilter.h:307 [inline]
ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247
NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318
mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855
mld_send_cr net/ipv6/mcast.c:2154 [inline]
mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693
process_one_work kernel/workqueue.c:3257 [inline]
process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340
worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421
kthread+0x711/0x8a0 kernel/kthread.c:463
ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 |
| Buffer Overflow vulnerability in WEINVEIW CO.,LTD EBPro v.6.10.01.510_20251022 allows a remote attacker to execute arbitrary code via the UtilityManagerEx.exe component |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: pci-epf: reject too-short SGL segments
The host controls an SGL segment's length. A nonzero length smaller than
one SGL descriptor makes nr_descs zero, so
nvmet_pci_epf_get_sgl_segment() reads the type byte of sgls[-1] outside
the allocated buffer. If that byte contains a segment descriptor type,
the function also copies the preceding 16 bytes and returns a negative
descriptor count.
The read was reproduced in 3/3 KASAN boots with only the host transfer
mocked by a KUnit test:
BUG: KASAN: slab-out-of-bounds in nvmet_pci_epf_get_sgl_segment
Read of size 1 by task kunit_try_catch
Call Trace:
nvmet_pci_epf_get_sgl_segment
nvmet_pci_epf_short_sgl_test
Kernel panic - not syncing: KASAN: panic_on_warn set ...
Reject segments that cannot hold one descriptor before allocating or
transferring their contents. |
| Improper Neutralization of Special Elements Used in a Template Engine vulnerability in Drupal Webform allows Code Injection. This issue affects Webform versions: from 0.0.0 to 6.2.12, from 6.3.0 to 6.3.1. |
| Vulnerability in the MySQL Server, MySQL Cluster product of Oracle MySQL (component: Server: Security: Encryption). Supported versions that are affected are MySQL Server: 9.7.0-9.7.3, 26.7.0-26.7.1; MySQL Cluster: 9.7.0-9.7.3 and 26.7.0-26.7.1. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server, MySQL Cluster. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server, MySQL Cluster and unauthorized read access to a subset of MySQL Server, MySQL Cluster accessible data. CVSS 3.1 Base Score 5.5 (Confidentiality and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:H). |
| Vitest is a Vite-native testing framework for JavaScript and TypeScript projects. From 2.1.0-beta.7 until 4.1.12 and 5.0.3, an unauthenticated non-browser WebSocket client that can reach a development server using interceptorPlugin can register a manual mock whose attacker-controlled url createManualModuleSource inserts unescaped into generated module source. When the developer browser loads the affected module, attacker-controlled JavaScript executes on the development-server origin. This issue is fixed in versions 4.1.12 and 5.0.3. |
| A stack-based buffer overflow vulnerability in the password functionality could allow an unauthenticated attacker to achieve code execution when the SafeEnhancement feature is enabled. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
1) XSA-437 (CVE-2023-34321) addressed issues with overflows in
calculations involved in guests flushing caches through
GNTTABOP_cache_flush. Unfortunately the fix there introduced a
calculation which may underflow, resulting in a loop which would - at
least on 64-bit Arm - take excessively long, and which would likely
eventually crash the hypervisor.
This is CVE-2026-102699.
2) GNTTABOP_cache_flush may be issued on memory mapped from another
domain using the grant table interface. However there was no
restriction to disallow the use of invalidate-without-clean against
read-only grant mappings, which may corrupt the granted memory.
This is CVE-2026-102702. |
| A stack-based buffer overflow vulnerability in the log message functionality could allow an unauthenticated attacker to achieve code execution. |
| A stack-based buffer overflow vulnerability in the Cookie parsing methods could allow an unauthenticated attacker to achieve code execution when the SafeEnhancement feature is enabled. |
| A stack-based buffer overflow vulnerability in the upload functionality could allow an authenticated attacker to achieve code execution. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
1) XSA-437 (CVE-2023-34321) addressed issues with overflows in
calculations involved in guests flushing caches through
GNTTABOP_cache_flush. Unfortunately the fix there introduced a
calculation which may underflow, resulting in a loop which would - at
least on 64-bit Arm - take excessively long, and which would likely
eventually crash the hypervisor.
This is CVE-2026-102699.
2) GNTTABOP_cache_flush may be issued on memory mapped from another
domain using the grant table interface. However there was no
restriction to disallow the use of invalidate-without-clean against
read-only grant mappings, which may corrupt the granted memory.
This is CVE-2026-102702. |
| In the Linux kernel, the following vulnerability has been resolved:
net: usb: catc: bound the RX packet length in catc_rx_done()
catc_rx_done() walks a multi-packet URB, reading a two-byte length from
each packet header. Its bound, pkt_len > urb->actual_length, ignores the
header offset and compares against the whole transfer rather than the
bytes left from pkt_start, so a crafted packet header makes
skb_copy_to_linear_data() read past the buffer.
A length below ETH_HLEN is also accepted, including zero, and
eth_type_trans() then reads a MAC header from the uninitialised tailroom
of a shorter skb. The is_f5u011 branch takes its length straight from
the transfer, so a zero-length URB reaches the same path.
Track the bytes remaining from the current packet, and reject a header
that does not fit, a length past what is left, and a length below an
Ethernet header.
A transfer shorter than an Ethernet header, including a zero-length one,
previously became a runt skb passed to netif_rx() and counted as
received; it is now counted in rx_length_errors and ends the walk. |
| Integer overflow in OpenModSim (<=1.11.0), leading to denial of service |
| Stack-based buffer overflow in Microsoft Exchange Online allows an authorized attacker to execute code over a network. |
| In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc()
nfc_llcp_recv_hdlc() reads the sequence byte skb->data[2], via
nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path
only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it
with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs
-- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb
tailroom. The byte becomes N(R)/N(S); a peer can already set those with
a well-formed PDU, so this is acting on uninitialised memory, not new
peer control.
Guard the read with pskb_may_pull(), as commit 95674f506c63 ("nfc: llcp:
reject PDUs shorter than the LLCP header") did for the two-byte header,
so the sequence byte is present and linear before it is read. RR and RNR
PDUs are LLCP_HEADER_SIZE + LLCP_SEQUENCE_SIZE bytes and an I PDU is
longer, so no valid frame is rejected; a truncated PDU is malformed, so
return without a DM reply. |
| 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/bridge: samsung-dsim: fix TE GPIO lifetime for host attach
When the Exynos DSI driver was generalized into samsung-dsim, the TE
GPIO acquisition was switched from gpiod_get_optional() to
devm_gpiod_get_optional() while keeping the matching gpiod_put() calls.
That combination is wrong for a managed descriptor.
However, dropping the puts and keeping the managed get is also wrong:
samsung_dsim_register_te_irq() runs from the DSI host attach callback,
and host detach/reattach can happen without destroying the device that
owns the managed action. A second attach would then request the GPIO
again without having released it.
Switch back to a non-managed gpiod_get_optional() and keep the explicit
gpiod_put() on the request_irq() error path and in
samsung_dsim_unregister_te_irq().
[Luca: remove unnecessary comment] |
| 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] |
