| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The DEF CON 27 badge allows remote attackers to exploit a buffer overflow by sending an oversized packet via the NFMI (Near Field Magnetic Induction) protocol. |
| Buffer overflow in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access. |
| libmodbus v3.1.10 is vulnerable to Buffer Overflow via the modbus_write_bits function. This issue can be triggered when the function is fed with specially crafted input, which leads to out-of-bounds read and can potentially cause a crash or other unintended behaviors. |
| TOTOLINK LR350 V9.3.5u.6698_B20230810 was discovered to contain a stack overflow via the password parameter in the function loginAuth. |
| The Texas Instruments (TI) WiLink WL18xx MCP driver does not limit the number of information elements (IEs) of type XCC_EXT_1_IE_ID or XCC_EXT_2_IE_ID that can be parsed in a management frame. Using a specially crafted frame, a buffer overflow can be triggered that can potentially lead to remote code execution. This affects WILINK8-WIFI-MCP8 version 8.5_SP3 and earlier. |
| An issue was discovered in the Linux kernel before 5.13.3. lib/seq_buf.c has a seq_buf_putmem_hex buffer overflow. |
| A buffer overflow issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.3. An app may be able to cause unexpected system termination or write kernel memory. |
| A buffer overflow issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.3. An app may be able to cause unexpected system termination or write kernel memory. |
| A buffer overflow issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.3. An app may be able to cause unexpected system termination or write kernel memory. |
| In drivers/char/virtio_console.c in the Linux kernel before 5.13.4, data corruption or loss can be triggered by an untrusted device that supplies a buf->len value exceeding the buffer size. NOTE: the vendor indicates that the cited data corruption is not a vulnerability in any existing use case; the length validation was added solely for robustness in the face of anomalous host OS behavior |
| Buffer Overflow vulnerability in LibRaw::stretch() function in libraw\src\postprocessing\aspect_ratio.cpp. |
| An issue was discovered in drivers/net/ethernet/intel/igb/igb_main.c in the IGB driver in the Linux kernel before 6.5.3. A buffer size may not be adequate for frames larger than the MTU. |
| Buffer Overflow vulnerability in FreeImage_Load function in FreeImage Library 3.19.0(r1828) allows attackers to cuase a denial of service via crafted PFM file. |
| Buffer Overflow vulnerability in function LoadPixelDataRLE8 in PluginBMP.cpp in FreeImage 3.18.0 allows remote attackers to run arbitrary code and cause other impacts via crafted image file. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: clk-loongson2: Fix potential buffer overflow in flexible-array member access
Flexible-array member `hws` in `struct clk_hw_onecell_data` is annotated
with the `counted_by()` attribute. This means that when memory is
allocated for this array, the _counter_, which in this case is member
`num` in the flexible structure, should be set to the maximum number of
elements the flexible array can contain, or fewer.
In this case, the total number of elements for the flexible array is
determined by variable `clks_num` when allocating heap space via
`devm_kzalloc()`, as shown below:
289 struct loongson2_clk_provider *clp;
...
296 for (p = data; p->name; p++)
297 clks_num++;
298
299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num),
300 GFP_KERNEL);
So, `clp->clk_data.num` should be set to `clks_num` or less, and not
exceed `clks_num`, as is currently the case. Otherwise, if data is
written into `clp->clk_data.hws[clks_num]`, the instrumentation
provided by the compiler won't detect the overflow, leading to a
memory corruption bug at runtime.
Fix this issue by setting `clp->clk_data.num` to `clks_num`. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/oa: Fix overflow in oa batch buffer
By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch
buffer, this is not a problem if batch buffer is only used once but
oa reuses the batch buffer for the same metric and at each call
it appends a MI_BATCH_BUFFER_END, printing the warning below and then
overflowing.
[ 381.072016] ------------[ cut here ]------------
[ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed!
platform: LUNARLAKE subplatform: 1
graphics: Xe2_LPG / Xe2_HPG 20.04 step B0
media: Xe2_LPM / Xe2_HPM 20.00 step B0
tile: 0 VRAM 0 B
GT: 0 type 1
So here checking if batch buffer already have MI_BATCH_BUFFER_END if
not append it.
v2:
- simply fix, suggestion from Ashutosh
(cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a) |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: send: fix buffer overflow detection when copying path to cache entry
Starting with commit c0247d289e73 ("btrfs: send: annotate struct
name_cache_entry with __counted_by()") we annotated the variable length
array "name" from the name_cache_entry structure with __counted_by() to
improve overflow detection. However that alone was not correct, because
the length of that array does not match the "name_len" field - it matches
that plus 1 to include the NUL string terminator, so that makes a
fortified kernel think there's an overflow and report a splat like this:
strcpy: detected buffer overflow: 20 byte write of buffer size 19
WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50
CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1
Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018
RIP: 0010:__fortify_report+0x45/0x50
Code: 48 8b 34 (...)
RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246
RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027
RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8
RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd
R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400
R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8
FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0
Call Trace:
<TASK>
? __warn+0x12a/0x1d0
? __fortify_report+0x45/0x50
? report_bug+0x154/0x1c0
? handle_bug+0x42/0x70
? exc_invalid_op+0x1a/0x50
? asm_exc_invalid_op+0x1a/0x20
? __fortify_report+0x45/0x50
__fortify_panic+0x9/0x10
__get_cur_name_and_parent+0x3bc/0x3c0
get_cur_path+0x207/0x3b0
send_extent_data+0x709/0x10d0
? find_parent_nodes+0x22df/0x25d0
? mas_nomem+0x13/0x90
? mtree_insert_range+0xa5/0x110
? btrfs_lru_cache_store+0x5f/0x1e0
? iterate_extent_inodes+0x52d/0x5a0
process_extent+0xa96/0x11a0
? __pfx_lookup_backref_cache+0x10/0x10
? __pfx_store_backref_cache+0x10/0x10
? __pfx_iterate_backrefs+0x10/0x10
? __pfx_check_extent_item+0x10/0x10
changed_cb+0x6fa/0x930
? tree_advance+0x362/0x390
? memcmp_extent_buffer+0xd7/0x160
send_subvol+0xf0a/0x1520
btrfs_ioctl_send+0x106b/0x11d0
? __pfx___clone_root_cmp_sort+0x10/0x10
_btrfs_ioctl_send+0x1ac/0x240
btrfs_ioctl+0x75b/0x850
__se_sys_ioctl+0xca/0x150
do_syscall_64+0x85/0x160
? __count_memcg_events+0x69/0x100
? handle_mm_fault+0x1327/0x15c0
? __se_sys_rt_sigprocmask+0xf1/0x180
? syscall_exit_to_user_mode+0x75/0xa0
? do_syscall_64+0x91/0x160
? do_user_addr_fault+0x21d/0x630
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fae145eeb4f
Code: 00 48 89 (...)
RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f
RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004
RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927
R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8
R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004
</TASK>
Fix this by not storing the NUL string terminator since we don't actually
need it for name cache entries, this way "name_len" corresponds to the
actual size of the "name" array. This requires marking the "name" array
field with __nonstring and using memcpy() instead of strcpy() as
recommended by the guidelines at:
https://github.com/KSPP/linux/issues/90 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Fix potential integer overflow in page size calculation
Explicitly cast tbo->page_alignment to u64 before bit-shifting to
prevent overflow when assigning to min_page_size. |
| In the Linux kernel, the following vulnerability has been resolved:
kdb: Fix buffer overflow during tab-complete
Currently, when the user attempts symbol completion with the Tab key, kdb
will use strncpy() to insert the completed symbol into the command buffer.
Unfortunately it passes the size of the source buffer rather than the
destination to strncpy() with predictably horrible results. Most obviously
if the command buffer is already full but cp, the cursor position, is in
the middle of the buffer, then we will write past the end of the supplied
buffer.
Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()
calls plus explicit boundary checks to make sure we have enough space
before we start moving characters around. |
| In the Linux kernel, the following vulnerability has been resolved:
rcu: Fix buffer overflow in print_cpu_stall_info()
The rcuc-starvation output from print_cpu_stall_info() might overflow the
buffer if there is a huge difference in jiffies difference. The situation
might seem improbable, but computers sometimes get very confused about
time, which can result in full-sized integers, and, in this case,
buffer overflow.
Also, the unsigned jiffies difference is printed using %ld, which is
normally for signed integers. This is intentional for debugging purposes,
but it is not obvious from the code.
This commit therefore changes sprintf() to snprintf() and adds a
clarifying comment about intention of %ld format.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
