| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An Out-of-Bounds Read vulnerability in
the routing protocol daemon (rpd) of
Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, logically adjacent BGP peer sending a specifically malformed BGP packet to cause rpd to crash and restart, resulting in a Denial of Service (DoS). Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition.
This issue only affects systems configured in
either of two ways:
* systems with BGP traceoptions enabled
* systems with BGP family traffic-engineering (BGP-LS)
configured
and can be exploited from a directly connected and configured BGP peer.
This issue affects iBGP and eBGP
with
any address family
configured, and both IPv4 and IPv6 are affected by this vulnerability.
This issue affects:
Junos OS:
*
from 21.4 before 21.4R3-S9,
* from 22.2 before 22.2R3-S5,
* from 22.3 before 22.3R3-S4,
* from 22.4 before 22.4R3-S5,
* from 23.2 before 23.2R2-S3,
* from 23.4 before 23.4R2-S3,
* from 24.2 before 24.2R1-S2, 24.2R2;
Junos OS Evolved:
* from 21.4-EVO before 21.4R3-S9-EVO,
* from 22.2-EVO before 22.2R3-S5-EVO,
* from 22.3-EVO before 22.3R3-S4-EVO,
* from 22.4-EVO before 22.4R3-S5-EVO,
* from 23.2-EVO before 23.2R2-S3-EVO,
* from 23.4-EVO before 23.4R2-S2-EVO,
* from 24.2-EVO before 24.2R1-S2-EVO, 24.2R2-EVO.
This issue does not affect versions of Junos OS prior to 21.3R1.
This issue does not affect versions of Junos OS Evolved prior to 21.3R1-EVO.
This is a similar, but different vulnerability than the issue reported as CVE-2024-39516. |
| A heap-based buffer overflow vulnerability was found in ImageMagick in versions prior to 7.0.11-14 in ReadTIFFImage() in coders/tiff.c. This issue is due to an incorrect setting of the pixel array size, which can lead to a crash and segmentation fault. |
| In nDPI through 3.2, the OpenVPN dissector is vulnerable to a heap-based buffer over-read in ndpi_search_openvpn in lib/protocols/openvpn.c. |
| In nDPI through 3.2, the packet parsing code is vulnerable to a heap-based buffer over-read in ndpi_parse_packet_line_info in lib/ndpi_main.c. |
| mmstu.c in VideoLAN VLC media player before 3.0.22 allows an out-of-bounds read and denial of service via a crafted 0x01 response from an MMS server. |
| In jose4j before 0.9.6, an attacker can cause a Denial-of-Service (DoS) condition by crafting a malicious JSON Web Encryption (JWE) token with an exceptionally high compression ratio. When this token is processed by the server, it results in significant memory allocation and processing time during decompression. |
| In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset()
Patch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mount
time".
The first patch fixes a bug reported by syzbot, and the second one fixes
the remaining bug of the same kind. Although they are triggered by the
same super block data anomaly, I divided it into the above two because the
details of the issues and how to fix it are different.
Both are required to eliminate the shift-out-of-bounds issues at mount
time.
This patch (of 2):
If the block size exponent information written in an on-disk superblock is
corrupted, nilfs_sb2_bad_offset helper function can trigger
shift-out-of-bounds warning followed by a kernel panic (if panic_on_warn
is set):
shift exponent 38983 is too large for 64-bit type 'unsigned long long'
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:151 [inline]
__ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322
nilfs_sb2_bad_offset fs/nilfs2/the_nilfs.c:449 [inline]
nilfs_load_super_block+0xdf5/0xe00 fs/nilfs2/the_nilfs.c:523
init_nilfs+0xb7/0x7d0 fs/nilfs2/the_nilfs.c:577
nilfs_fill_super+0xb1/0x5d0 fs/nilfs2/super.c:1047
nilfs_mount+0x613/0x9b0 fs/nilfs2/super.c:1317
...
In addition, since nilfs_sb2_bad_offset() performs multiplication without
considering the upper bound, the computation may overflow if the disk
layout parameters are not normal.
This fixes these issues by inserting preliminary sanity checks for those
parameters and by converting the comparison from one involving
multiplication and left bit-shifting to one using division and right
bit-shifting. |
| An Out-of-Bounds Read vulnerability in
the routing protocol daemon (rpd) of
Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated network-based attacker sending a specifically malformed BGP packet to cause rpd to crash and restart, resulting in a Denial of Service (DoS). Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition.
This issue only affects systems configured in
either of two ways:
* systems with BGP traceoptions enabled
* systems with BGP traffic engineering
configured
This issue can affect iBGP and eBGP with
any address family
configured. The specific attribute involved is non-transitive, and will not propagate across a network.
This issue affects:
Junos OS:
* All versions before 21.4R3-S8,
* 22.2 before 22.2R3-S5,
* 22.3 before 22.3R3-S4,
* 22.4 before 22.4R3-S3,
* 23.2 before 23.2R2-S2,
* 23.4 before 23.4R2;
Junos OS Evolved:
* All versions before 21.4R3-S8-EVO,
* 22.2-EVO before 22.2R3-S5-EVO,
* 22.3-EVO before 22.3R3-S4-EVO,
* 22.4-EVO before 22.4R3-S3-EVO,
* 23.2-EVO before 23.2R2-S2-EVO,
* 23.4-EVO before 23.4R2-EVO. |
| GPAC v2.4.0 was discovered to contain an out-of-bounds read in the oggdmx_parse_tags function. |
| An out-of-bounds read in the GSF demuxer filter component of GPAC v2.4.0 allows attackers to cause a Denial of Service (DoS) via a crafted .gsf file. |
| An Out-of-bounds Read vulnerability in the advanced forwarding management process aftman of Juniper Networks Junos OS on MX Series with MPC10E, MPC11, MX10K-LC9600 line cards, MX304, and EX9200-15C, may allow an attacker to exploit a stack-based buffer overflow, leading to a reboot of the FPC.
Through code review, it was determined that the interface definition code for aftman could read beyond a buffer boundary, leading to a stack-based buffer overflow.
This issue affects Junos OS on MX Series and EX9200-15C:
* from 21.2 before 21.2R3-S1,
* from 21.4 before 21.4R3,
* from 22.1 before 22.1R2,
* from 22.2 before 22.2R2;
This issue does not affect:
* versions of Junos OS prior to 20.3R1;
* any version of Junos OS 20.4. |
| Multiple out-of-bounds read vulnerabilities were identified in a system component responsible for handling certain data buffers. Due to insufficient validation of maximum buffer size values, the process may attempt to read beyond the intended memory region. Under specific conditions, this can result in a crash of the affected process and a potential denial-of-service of the compromised process. |
| Multiple out-of-bounds read vulnerabilities were identified in a system component responsible for handling certain data buffers. Due to insufficient validation of maximum buffer size values, the process may attempt to read beyond the intended memory region. Under specific conditions, this can result in a crash of the affected process and a potential denial-of-service of the compromised process. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: core: config: Prevent OOB read in SS endpoint companion parsing
usb_parse_ss_endpoint_companion() checks descriptor type before length,
enabling a potentially odd read outside of the buffer size.
Fix this up by checking the size first before looking at any of the
fields in the descriptor. |
| In the Linux kernel, the following vulnerability has been resolved:
net: fix out-of-bounds access in ops_init
net_alloc_generic is called by net_alloc, which is called without any
locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It
is read twice, first to allocate an array, then to set s.len, which is
later used to limit the bounds of the array access.
It is possible that the array is allocated and another thread is
registering a new pernet ops, increments max_gen_ptrs, which is then used
to set s.len with a larger than allocated length for the variable array.
Fix it by reading max_gen_ptrs only once in net_alloc_generic. If
max_gen_ptrs is later incremented, it will be caught in net_assign_generic. |
| In the Linux kernel, the following vulnerability has been resolved:
bna: ensure the copied buf is NUL terminated
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
userspace to that buffer. Later, we use sscanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using sscanf. Fix this issue by using memdup_user_nul
instead of memdup_user. |
| In the Linux kernel, the following vulnerability has been resolved:
blk-iocost: avoid out of bounds shift
UBSAN catches undefined behavior in blk-iocost, where sometimes
iocg->delay is shifted right by a number that is too large,
resulting in undefined behavior on some architectures.
[ 186.556576] ------------[ cut here ]------------
UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23
shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long')
CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1
Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020
Call Trace:
<IRQ>
dump_stack_lvl+0x8f/0xe0
__ubsan_handle_shift_out_of_bounds+0x22c/0x280
iocg_kick_delay+0x30b/0x310
ioc_timer_fn+0x2fb/0x1f80
__run_timer_base+0x1b6/0x250
...
Avoid that undefined behavior by simply taking the
"delay = 0" branch if the shift is too large.
I am not sure what the symptoms of an undefined value
delay will be, but I suspect it could be more than a
little annoying to debug. |
| In the Linux kernel, the following vulnerability has been resolved:
binfmt_misc: fix shift-out-of-bounds in check_special_flags
UBSAN reported a shift-out-of-bounds warning:
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106
ubsan_epilogue+0xa/0x44 lib/ubsan.c:151
__ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322
check_special_flags fs/binfmt_misc.c:241 [inline]
create_entry fs/binfmt_misc.c:456 [inline]
bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654
vfs_write+0x11e/0x580 fs/read_write.c:582
ksys_write+0xcf/0x120 fs/read_write.c:637
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x4194e1
Since the type of Node's flags is unsigned long, we should define these
macros with same type too. |
| A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory. |
| Soda PDF Desktop PDF File Parsing Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Soda PDF Desktop. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.
The specific flaw exists within the parsing of PDF files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-27143. |
