| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An integer overflow was addressed with improved input validation. This issue is fixed in iOS 18.7.10 and iPadOS 18.7.10, iOS 26.6 and iPadOS 26.6, macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6. Processing a maliciously crafted image may lead to arbitrary code execution. |
| An integer overflow was addressed with improved input validation. This issue is fixed in iOS 18.7.10 and iPadOS 18.7.10, iOS 26.6 and iPadOS 26.6, macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6, watchOS 26.6. A malicious app may be able to break out of its sandbox. |
| An integer overflow was addressed with improved input validation. This issue is fixed in iOS 18.7.10 and iPadOS 18.7.10, iOS 26.6 and iPadOS 26.6, macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6, tvOS 26.6, visionOS 26.6, watchOS 26.6. An app may be able to cause unexpected system termination. |
| Integer overflow or wraparound in Windows Installer allows an authorized attacker to elevate privileges locally. |
| New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to 1.0.0-rc.18, user-controlled image n, video seconds and duration, max_tokens, max_completion_tokens, maxOutputTokens, audio duration, and billing-expression quantities can overflow conversions in common/quota_math.go and related settlement paths, allowing a low-privileged account with positive balance or an active subscription to turn a negative charge into account credit and potentially drain upstream funds. This issue is fixed in version 1.0.0-rc.18. |
| In the Linux kernel, the following vulnerability has been resolved:
batman-adv: tt: prevent TVLV OOB check overflow
A TT unicast TVLV contains the number of VLANs stored in it. This number is
an u16 and gets multiplied by the size of the struct
batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16
used to store the tt_vlan_len. All additional safety checks to prevent
out-of-bounds access of the TVLV buffer are invalid due to this overflow.
Using size_t prevents this overflow and ensures that the safety checks
compare against the actual buffer requirements. |
| Integer overflow or wraparound in Windows DNS allows an authorized attacker to elevate privileges locally. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: bpf: Fix hid_bpf_get_data() range check
hid_bpf_get_data() returns a pointer into the HID-BPF context data when
the caller-provided offset and size fit inside ctx->allocated_size.
The current check adds rdwr_buf_size and offset before comparing the
result against ctx->allocated_size. Since both values are unsigned, a
very large size can wrap the sum below ctx->allocated_size and make the
helper return a pointer even though the requested range is not contained
in the backing buffer.
Use check_add_overflow() to reject wrapped range ends before comparing
the requested range end against ctx->allocated_size. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix integer overflow in radeon_align_pitch()
radeon_align_pitch() has the same kind of overflow issue as the old
amdgpu helper: both the alignment round-up add and the final
'aligned * cpp' calculation can overflow signed int.
If that wraps, radeon_mode_dumb_create() can end up returning an
invalid pitch or creating a zero-sized dumb buffer.
Fix this by using check_add_overflow() for the alignment round-up and
check_mul_overflow() for the final pitch calculation, returning 0 on
overflow. Also reject zero pitch and size in
radeon_mode_dumb_create().
Found via AST-based call-graph analysis using sqry. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: Correct data type for scan index to avoid infinite loop
A kernel soft lockup was observed during Wi-Fi scanning on the 6GHz band.
The CPU becomes stuck in rtw89_hw_scan_add_chan_ax for over 20 seconds,
leading to a system panic.
RIP points to 0f b6 c3 (movzbl %bl, %eax), which zero-extends
the low 8 bits of RBX into RAX.
RBX (the counter i) has reached a huge value: 0x137466a1.
watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u16:4:6124]
Workqueue: events_unbound cfg80211_wiphy_work [cfg80211]
RIP: 0010:rtw89_hw_scan_add_chan_ax+0xb3/0x6e0 [rtw89_core]
Code: a0 48 89 45 a8 44 89 6d 9c 44 89 75 98 eb 29 66 66 2e 0f 1f
84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 c3 01
<0f> b6 c3 41 3b 44 24 74 0f 83 0b 02 00 00 0f b6 c3 48 8d 14 80 49
RSP: 0018:ffffcb48cbaa39f8 EFLAGS: 00000202
RAX: 0000000000000005 RBX: 00000000137466a1 RCX: 0000000000000000
RDX: ffff89ffc9d851a8 RSI: 0000000000004f0d RDI: 0000000096af0130
RBP: ffffcb48cbaa3a60 R08: 0000000000000000 R09: ffff8a00b7502080
R10: ffff8a00b75ff600 R11: 0000000000000000 R12: ffff89ffc7553870
R13: ffff8a00b7ac8f19 R14: ffff8a00b75020d8 R15: ffff89ffc3d54d80
FS: 0000000000000000(0000) GS:ffff8a014f962000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007558d7f9f4c4 CR3: 0000000178040001 CR4: 00000000001706f0
Call Trace:
<TASK>
rtw89_hw_scan_prep_chan_list_ax+0x8a/0x400 [rtw89_core]
rtw89_hw_scan_start+0x546/0x8a0 [rtw89_core]
? rtw89_fw_h2c_default_cmac_tbl+0x13c/0x1f0 [rtw89_core]
rtw89_ops_hw_scan+0xae/0x120 [rtw89_core]
drv_hw_scan+0xbb/0x180 [mac80211]
__ieee80211_start_scan+0x2fc/0x750 [mac80211]
ieee80211_request_scan+0xe/0x20 [mac80211]
ieee80211_scan+0x123/0x190 [mac80211]
rdev_scan+0x40/0x110 [cfg80211]
cfg80211_scan_6ghz+0x5a1/0xa30 [cfg80211]
By objdump with source:
for (i = 0; i < req->n_6ghz_params; i++) {
5fbc0: 83 c3 01 add $0x1,%ebx --> i++
5fbc3: 0f b6 c3 movzbl %bl,%eax --> get counter
fbc6: 41 3b 44 24 74 cmp 0x74(%r12),%eax
* RBX: 00000000137466a1 -> %bl = a1 -> EAX = 000000a1 (161) |
| In the Linux kernel, the following vulnerability has been resolved:
ntfs: harden runlist realloc size calculations
Add a shared helper to safely convert runlist element counts to byte sizes
using overflow checks, and use it in both ntfs_rl_realloc() and
ntfs_rl_realloc_nofail(). |
| Integer overflow or wraparound in Windows HTTP.sys allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows Universal Disk Format File System Driver (UDFS) allows an unauthorized attacker to execute code with a physical attack. |
| Heap-based buffer overflow in Windows HTTP.sys allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Reliable Multicast Transport Driver (RMCAST) allows an unauthorized attacker to execute code over an adjacent network. |
| Heap-based buffer overflow in Windows Storage Port Driver allows an authorized attacker to elevate privileges locally. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet-rdma: handle inline data with a nonzero offset
nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset
into the per-command inline scatterlist. The bounds check admits any
offset with off + len <= inline_data_size, but the mapping still assumes
the data begins in the first inline page:
sg->offset = off;
sg->length = min_t(int, len, PAGE_SIZE - off);
When a port is configured with inline_data_size > PAGE_SIZE (settable up
to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size]
makes "PAGE_SIZE - off" underflow, so sg->length is set to ~4 GiB and
the block backend reads far past the first inline page. num_pages(len)
also ignores the offset, so an in-bounds offset whose [off, off+len)
span crosses a page boundary under-counts the scatterlist.
Map the offset properly: split it into a page index and an in-page
offset, start the scatterlist at that page, and size the page count from
page_off + len. Because the request scatterlist may now start at
inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL
identity test in nvmet_rdma_release_rsp() to a range test; otherwise the
persistent inline scatterlist is mistaken for an allocated one and
nvmet_req_free_sgls() frees an inline page (and warns in
free_large_kmalloc()). |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject negative const offsets for buffer pointers
The verifier rejects variable offsets for PTR_TO_TP_BUFFER and PTR_TO_BUF
accesses, but it currently accepts a constant negative offset produced by
pointer arithmetic.
Commit 022ac0750883 ("bpf: use reg->var_off instead of reg->off for
pointers") moved constant pointer offsets from reg->off to reg->var_off.
However, __check_buffer_access() continued to check only the instruction
offset. An access with reg->var_off equal to -8 and an instruction offset
of zero therefore passes verification.
For writable raw tracepoints, the access end is also calculated from the
unsigned reg->var_off.value. An eight-byte access starting at -8 wraps
the calculated end to zero, allowing the program to load and attach
without increasing max_tp_access.
After ensuring that reg->var_off is constant, calculate the effective
access start using signed arithmetic and reject it when it is negative.
Use the validated start to calculate the access end for both
PTR_TO_TP_BUFFER and PTR_TO_BUF. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: Fix division by zero in initialize_timer()
A userspace-driven ALSA timer (SND_UTIMER) lets an unprivileged user set
the backing snd_timer's hardware resolution to an arbitrary 64-bit value
via SNDRV_TIMER_IOCTL_CREATE. snd_utimer_create() only rejects zero.
When such a timer is bound to a sequencer queue, initialize_timer()
computes the tick period as
tmr->ticks = 1000000000 / (r * freq);
where r is that user-controlled resolution and freq is the sequencer
update rate in Hz, clamped to MIN_FREQUENCY..MAX_FREQUENCY (10..6250).
A resolution of 2^63 makes the 64-bit product r * freq wrap to zero for
any even freq, including DEFAULT_FREQUENCY (1000), so the division faults
with a divide-by-zero.
The division runs under tmr->lock with interrupts disabled, so the oops
leaves the spinlock held and hangs the CPU. It is reachable by an
unprivileged user with access to /dev/snd/timer and /dev/snd/seq.
Oops: divide error: 0000 [#1] SMP KASAN PTI
CPU: 7 UID: 1000 PID: 456 Comm: alsa_seq_utimer Not tainted 7.2.0-rc4+
RIP: 0010:initialize_timer.constprop.0+0x20a/0x2d0
snd_seq_timer_start+0x15e/0x2b0
snd_seq_control_queue+0x56f/0xba0
snd_seq_write+0x3e0/0x730
Reject an overflowing product with check_mul_overflow() and fall back to
a single tick, which also avoids feeding a wrapped-but-nonzero divisor
(e.g. 2^63 * 1000 mod 2^64 == 0, or other resolutions wrapping to a small
value) into the period computation. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()
On links faster than ~34 Gbps, where byte rate may exceed 2^32-1
(~ 4.3 GBps), the comparison result becomes incorrect because the
truncated value no longer reflects the actual estimator rate.
Fix by changing the local variables to u64. |
