| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A crafted NTFS image can cause an out-of-bounds access in ntfs_decompress in NTFS-3G < 2021.8.22. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64/sme: Set new vector length before reallocating
As part of fixing the allocation of the buffer for SVE state when changing
SME vector length we introduced an immediate reallocation of the SVE state,
this is also done when changing the SVE vector length for consistency.
Unfortunately this reallocation is done prior to writing the new vector
length to the task struct, meaning the allocation is done with the old
vector length and can lead to memory corruption due to an undersized buffer
being used.
Move the update of the vector length before the allocation to ensure that
the new vector length is taken into account.
For some reason this isn't triggering any problems when running tests on
the arm64 fixes branch (even after repeated tries) but is triggering
issues very often after merge into mainline. |
| In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix memory corruption when FW resources change during ifdown
bnxt_set_dflt_rings() assumes that it is always called before any TC has
been created. So it doesn't take bp->num_tc into account and assumes
that it is always 0 or 1.
In the FW resource or capability change scenario, the FW will return
flags in bnxt_hwrm_if_change() that will cause the driver to
reinitialize and call bnxt_cancel_reservations(). This will lead to
bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc
may be greater than 1. This will cause bp->tx_ring[] to be sized too
small and cause memory corruption in bnxt_alloc_cp_rings().
Fix it by properly scaling the TX rings by bp->num_tc in the code
paths mentioned above. Add 2 helper functions to determine
bp->tx_nr_rings and bp->tx_nr_rings_per_tc. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: intel-thc-hid: intel-quicki2c: Fix ACPI dsd ICRS/ISUB length
The QuickI2C ACPI _DSD methods return ICRS and ISUB data with a
trailing byte, making the actual length is one more byte than the
structs defined.
It caused stack-out-of-bounds and kernel crash:
kernel: BUG: KASAN: stack-out-of-bounds in quicki2c_acpi_get_dsd_property.constprop.0+0x111/0x1b0 [intel_quicki2c]
kernel: Write of size 12 at addr ffff888106d1f900 by task kworker/u33:2/75
kernel:
kernel: CPU: 3 UID: 0 PID: 75 Comm: kworker/u33:2 Not tainted 6.16.0+ #3 PREEMPT(voluntary)
kernel: Workqueue: async async_run_entry_fn
kernel: Call Trace:
kernel: <TASK>
kernel: dump_stack_lvl+0x76/0xa0
kernel: print_report+0xd1/0x660
kernel: ? __pfx__raw_spin_lock_irqsave+0x10/0x10
kernel: ? __kasan_slab_free+0x5d/0x80
kernel: ? kasan_addr_to_slab+0xd/0xb0
kernel: kasan_report+0xe1/0x120
kernel: ? quicki2c_acpi_get_dsd_property.constprop.0+0x111/0x1b0 [intel_quicki2c]
kernel: ? quicki2c_acpi_get_dsd_property.constprop.0+0x111/0x1b0 [intel_quicki2c]
kernel: kasan_check_range+0x11c/0x200
kernel: __asan_memcpy+0x3b/0x80
kernel: quicki2c_acpi_get_dsd_property.constprop.0+0x111/0x1b0 [intel_quicki2c]
kernel: ? __pfx_quicki2c_acpi_get_dsd_property.constprop.0+0x10/0x10 [intel_quicki2c]
kernel: quicki2c_get_acpi_resources+0x237/0x730 [intel_quicki2c]
[...]
kernel: </TASK>
kernel:
kernel: The buggy address belongs to stack of task kworker/u33:2/75
kernel: and is located at offset 48 in frame:
kernel: quicki2c_get_acpi_resources+0x0/0x730 [intel_quicki2c]
kernel:
kernel: This frame has 3 objects:
kernel: [32, 36) 'hid_desc_addr'
kernel: [48, 59) 'i2c_param'
kernel: [80, 224) 'i2c_config'
ACPI DSD methods return:
\_SB.PC00.THC0.ICRS Buffer 000000003fdc947b 001 Len 0C = 0A 00 80 1A 06 00 00 00 00 00 00 00
\_SB.PC00.THC0.ISUB Buffer 00000000f2fcbdc4 001 Len 91 = 00 00 00 00 00 00 00 00 00 00 00 00
Adding reserved padding to quicki2c_subip_acpi_parameter/config. |
| In the Linux kernel, the following vulnerability has been resolved:
perf: Avoid undefined behavior from stopping/starting inactive events
Calling pmu->start()/stop() on perf events in PERF_EVENT_STATE_OFF can
leave event->hw.idx at -1. When PMU drivers later attempt to use this
negative index as a shift exponent in bitwise operations, it leads to UBSAN
shift-out-of-bounds reports.
The issue is a logical flaw in how event groups handle throttling when some
members are intentionally disabled. Based on the analysis and the
reproducer provided by Mark Rutland (this issue on both arm64 and x86-64).
The scenario unfolds as follows:
1. A group leader event is configured with a very aggressive sampling
period (e.g., sample_period = 1). This causes frequent interrupts and
triggers the throttling mechanism.
2. A child event in the same group is created in a disabled state
(.disabled = 1). This event remains in PERF_EVENT_STATE_OFF.
Since it hasn't been scheduled onto the PMU, its event->hw.idx remains
initialized at -1.
3. When throttling occurs, perf_event_throttle_group() and later
perf_event_unthrottle_group() iterate through all siblings, including
the disabled child event.
4. perf_event_throttle()/unthrottle() are called on this inactive child
event, which then call event->pmu->start()/stop().
5. The PMU driver receives the event with hw.idx == -1 and attempts to
use it as a shift exponent. e.g., in macros like PMCNTENSET(idx),
leading to the UBSAN report.
The throttling mechanism attempts to start/stop events that are not
actively scheduled on the hardware.
Move the state check into perf_event_throttle()/perf_event_unthrottle() so
that inactive events are skipped entirely. This ensures only active events
with a valid hw.idx are processed, preventing undefined behavior and
silencing UBSAN warnings. The corrected check ensures true before
proceeding with PMU operations.
The problem can be reproduced with the syzkaller reproducer: |
| NVIDIA DGX Spark GB10 contains a vulnerability in SROOT firmware, where an attacker could cause an out-of-bound write. A successful exploit of this vulnerability might lead to code execution, data tampering, denial of service, information disclosure, or escalation of privileges. |
| NVIDIA DGX Spark GB10 contains a vulnerability in SROOT firmware where an attacker could cause an out-of-bound write. A successful exploit of this vulnerability might lead to code execution, data tampering, denial of service, or escalation of privileges. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: intel-thc-hid: intel-thc: Fix incorrect pointer arithmetic in I2C regs save
Improper use of secondary pointer (&dev->i2c_subip_regs) caused
kernel crash and out-of-bounds error:
BUG: KASAN: slab-out-of-bounds in _regmap_bulk_read+0x449/0x510
Write of size 4 at addr ffff888136005dc0 by task kworker/u33:5/5107
CPU: 3 UID: 0 PID: 5107 Comm: kworker/u33:5 Not tainted 6.16.0+ #3 PREEMPT(voluntary)
Workqueue: async async_run_entry_fn
Call Trace:
<TASK>
dump_stack_lvl+0x76/0xa0
print_report+0xd1/0x660
? __pfx__raw_spin_lock_irqsave+0x10/0x10
? kasan_complete_mode_report_info+0x26/0x200
kasan_report+0xe1/0x120
? _regmap_bulk_read+0x449/0x510
? _regmap_bulk_read+0x449/0x510
__asan_report_store4_noabort+0x17/0x30
_regmap_bulk_read+0x449/0x510
? __pfx__regmap_bulk_read+0x10/0x10
regmap_bulk_read+0x270/0x3d0
pio_complete+0x1ee/0x2c0 [intel_thc]
? __pfx_pio_complete+0x10/0x10 [intel_thc]
? __pfx_pio_wait+0x10/0x10 [intel_thc]
? regmap_update_bits_base+0x13b/0x1f0
thc_i2c_subip_pio_read+0x117/0x270 [intel_thc]
thc_i2c_subip_regs_save+0xc2/0x140 [intel_thc]
? __pfx_thc_i2c_subip_regs_save+0x10/0x10 [intel_thc]
[...]
The buggy address belongs to the object at ffff888136005d00
which belongs to the cache kmalloc-rnd-12-192 of size 192
The buggy address is located 0 bytes to the right of
allocated 192-byte region [ffff888136005d00, ffff888136005dc0)
Replaced with direct array indexing (&dev->i2c_subip_regs[i]) to ensure
safe memory access. |
| Heap-based Buffer Overflow, Out-of-bounds Write vulnerability in Avast Antivirus on MacOS of a crafted Mach-O file may allow Local Execution of Code or Denial of Service of antivirus protection.
This issue affects Antivirus: from 15.7 before 3.9.2025. |
| A weakness has been identified in mruby 3.4.0. This vulnerability affects the function ary_fill_exec of the file mrbgems/mruby-array-ext/src/array.c. Executing manipulation of the argument start/length can lead to out-of-bounds write. The attack needs to be launched locally. The exploit has been made available to the public and could be exploited. This patch is called 93619f06dd378db6766666b30c08978311c7ec94. It is best practice to apply a patch to resolve this issue. |
| An out-of-bounds write vulnerability exists in the XML parser functionality of GCC Productions Inc. Fade In 4.2.0. A specially crafted .fadein file can lead to an out-of-bounds write. An attacker can provide a malicious file to trigger this vulnerability. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c
The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can
lead to the use of wrong `CIDR_POS(c)` for calculating array offsets,
which can lead to integer underflow. As a result, it leads to slab
out-of-bound access.
This patch adds back the IP_SET_HASH_WITH_NET0 macro to
ip_set_hash_netportnet to address the issue. |
| In the Linux kernel, the following vulnerability has been resolved:
efi: stmm: Fix incorrect buffer allocation method
The communication buffer allocated by setup_mm_hdr() is later on passed
to tee_shm_register_kernel_buf(). The latter expects those buffers to be
contiguous pages, but setup_mm_hdr() just uses kmalloc(). That can cause
various corruptions or BUGs, specifically since commit 9aec2fb0fd5e
("slab: allocate frozen pages"), though it was broken before as well.
Fix this by using alloc_pages_exact() instead of kmalloc(). |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info()
The function mpi3mr_get_all_tgt_info() has four issues:
1) It calculates valid entry length in alltgt_info assuming the header part
of the struct mpi3mr_device_map_info would equal to sizeof(u32). The
correct size is sizeof(u64).
2) When it calculates the valid entry length kern_entrylen, it excludes one
entry by subtracting 1 from num_devices.
3) It copies num_device by calling memcpy(). Substitution is enough.
4) It does not specify the calculated length to sg_copy_from_buffer().
Instead, it specifies the payload length which is larger than the
alltgt_info size. It causes "BUG: KASAN: slab-out-of-bounds".
Fix the issues by using the correct header size, removing the subtraction
from num_devices, replacing the memcpy() with substitution and specifying
the correct length to sg_copy_from_buffer(). |
| Out-of-bounds write in the PCX image codec in QNX SDP versions 8.0, 7.1 and 7.0 could allow an unauthenticated attacker to cause a denial-of-service condition or execute code in the context of the process using the image codec. |
| A memory corruption vulnerability in Palo Alto Networks PAN-OS software allows an unauthenticated attacker to crash PAN-OS due to a crafted packet through the data plane, resulting in a denial of service (DoS) condition. Repeated attempts to trigger this condition will result in PAN-OS entering maintenance mode. |
| Zenitel TCIV-3+ is vulnerable to an out-of-bounds write
vulnerability, which could allow a remote attacker to crash the device. |
| A flaw was found in GIMP. An integer overflow vulnerability exists in the GIMP "Despeckle" plug-in. The issue occurs due to unchecked multiplication of image dimensions, such as width, height, and bytes-per-pixel (img_bpp), which can result in allocating insufficient memory and subsequently performing out-of-bounds writes. This issue could lead to heap corruption, a potential denial of service (DoS), or arbitrary code execution in certain scenarios. |
| A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input. |
| In Ashlar-Vellum Cobalt, Xenon, Argon, Lithium, and Cobalt Share versions prior to 12.6.1204.204, the affected applications lack proper validation of user-supplied data when parsing CO files. This could lead to an out-of-bounds write. An attacker could leverage this vulnerability to execute arbitrary code in the context of the current process. |
