| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Heap-based buffer overflow in Microsoft Office Access allows an unauthorized attacker to execute code over a network. |
| Dislocker through 0.7.3 contains an integer underflow vulnerability in get_vmk() and get_fvek() that allows attackers to trigger out-of-bounds heap reads via crafted datum sizes. Attackers can supply a malicious BitLocker volume image with a datum_size smaller than the 36-byte AES-CCM header, causing hexdump() to over-read and crash dislocker. |
| Out-of-bounds read in DNS Server allows an authorized attacker to deny service over a network. |
| Out-of-bounds read in DNS Server allows an authorized attacker to deny service over a network. |
| Out-of-bounds read in DNS Server allows an authorized attacker to deny service over a network. |
| Out-of-bounds read in DNS Server allows an authorized attacker to deny service over a network. |
| Out-of-bounds read in DNS Server allows an authorized attacker to deny service over a network. |
| Out-of-bounds read in DNS Server allows an unauthorized attacker to deny service over a network. |
| Heap-based buffer overflow in Windows Kernel allows an authorized attacker to elevate privileges locally. |
| Photoshop Desktop is affected by a Heap-based Buffer Overflow vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code over a network. |
| Stack-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code over a network. |
| In DragonFly BSD through 6.4.2 before 4bb22ff, the ARP input handlers arpintr() and in_arpinput() (sys/netinet/if_ether.c) do not validate the hardware address length (ar_hln) and protocol address length (ar_pln) fields of incoming ARP packets. in_arpreply() then uses these attacker-controlled values as memcpy lengths when copying from kernel buffers that are only 6 and 4 bytes long, resulting in an out-of-bounds read of kernel heap and stack memory that is copied into the ARP reply sent back to the requester. An unauthenticated attacker on the adjacent network can use a single crafted ARP request to disclose up to roughly 250 bytes of each type of kernel memory, including kernel pointers. This is expected to be fixed in the 6.6 stable release when that is available. |
| Nix before 2.35.3 and Lix before 2.95.4 have an integer overflow and resultant out-of-bounds write when evaluating untrusted expressions because list allocation is mishandled. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btintel_pcie: fix tx_handle bounds off-by-one
Valid indices into txq->urbd0s/tfds/bufs are 0..txq->count-1, so
tfd_index == txq->count is already out of range. Change the guard in
btintel_pcie_msix_tx_handle() from '> txq->count' to '>= txq->count'.
This issue was reported by Claude Mythos. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: Fix UDP length overflow with PMTU discover and big MTU
This commit bounds cork->base.fragsize to IP_MAX_MTU to avoid a
possible overflow of UDP length that triggers a WARN in
udp_set_len_short when setsockopt IP_MTU_DISCOVER is set to
IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an
unusually large MTU.
Steps to reproduce:
1. Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will
be set to that MTU in ip_setup_cork.
2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be
set to device MTU (cork->fragsize) in __ip_append_data, rather than
to IP_MAX_MTU.
3. Send 65528 bytes of payload (+8 bytes of UDP header, +20 bytes of
IPv4 header). Device MTU allows it (it's only one byte bigger than
IP_MAX_MTU + IPv4 header, and the device MTU is bigger than that).
4. The UDP length in the built packet is 65536, which overflows the
16-bit length field and triggers the WARN in udp_set_len_short.
Note: IP_PMTUDISC_DO with IPv4 is safe, because ip_dst_mtu_maybe_forward
always clamps at IP_MAX_MTU, unlike ip6_dst_mtu_maybe_forward.
The Fixes tag points at the first commit where I could reproduce the
overflow with IPv4 and IP_PMTUDISC_PROBE. |
| Improper validation of specified type of input in .NET Framework allows an unauthorized attacker to perform tampering over a network. |
| Out-of-bounds read in Microsoft Office Excel allows an unauthorized attacker to disclose information over a network. |
| In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186
Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290
CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xca/0x5f0 mm/kasan/report.c:482
kasan_report+0xca/0x100 mm/kasan/report.c:595
hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186
hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738
vfs_listxattr+0xbe/0x140 fs/xattr.c:493
listxattr+0xee/0x190 fs/xattr.c:924
filename_listxattr fs/xattr.c:958 [inline]
path_listxattrat+0x143/0x360 fs/xattr.c:988
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe0e9fae16d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3
RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000
RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000
</TASK>
Allocated by task 14290:
kasan_save_stack+0x24/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__do_kmalloc_node mm/slub.c:4333 [inline]
__kmalloc_noprof+0x219/0x540 mm/slub.c:4345
kmalloc_noprof include/linux/slab.h:909 [inline]
hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21
hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697
vfs_listxattr+0xbe/0x140 fs/xattr.c:493
listxattr+0xee/0x190 fs/xattr.c:924
filename_listxattr fs/xattr.c:958 [inline]
path_listxattrat+0x143/0x360 fs/xattr.c:988
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
When hfsplus_uni2asc is called from hfsplus_listxattr,
it actually passes in a struct hfsplus_attr_unistr*.
The size of the corresponding structure is different from that of hfsplus_unistr,
so the previous fix (94458781aee6) is insufficient.
The pointer on the unicode buffer is still going beyond the allocated memory.
This patch introduces two warpper functions hfsplus_uni2asc_xattr_str and
hfsplus_uni2asc_str to process two unicode buffers,
struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively.
When ustrlen value is bigger than the allocated memory size,
the ustrlen value is limited to an safe size. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix oob access in cgroup local storage
Lonial reported that an out-of-bounds access in cgroup local storage
can be crafted via tail calls. Given two programs each utilizing a
cgroup local storage with a different value size, and one program
doing a tail call into the other. The verifier will validate each of
the indivial programs just fine. However, in the runtime context
the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the
BPF program as well as any cgroup local storage flavor the program
uses. Helpers such as bpf_get_local_storage() pick this up from the
runtime context:
ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx);
storage = ctx->prog_item->cgroup_storage[stype];
if (stype == BPF_CGROUP_STORAGE_SHARED)
ptr = &READ_ONCE(storage->buf)->data[0];
else
ptr = this_cpu_ptr(storage->percpu_buf);
For the second program which was called from the originally attached
one, this means bpf_get_local_storage() will pick up the former
program's map, not its own. With mismatching sizes, this can result
in an unintended out-of-bounds access.
To fix this issue, we need to extend bpf_map_owner with an array of
storage_cookie[] to match on i) the exact maps from the original
program if the second program was using bpf_get_local_storage(), or
ii) allow the tail call combination if the second program was not
using any of the cgroup local storage maps. |
