| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Foxit PDF Reader Annotation Use of Uninitialized Variable Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit PDF Reader. 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 handling of Annotation objects. The issue results from the lack of proper initialization of a pointer prior to accessing it. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the current process. Was ZDI-CAN-14395. |
| Kofax Power PDF printf Uninitialized Variable Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Kofax Power PDF. 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 handling of util objects. The issue results from the lack of proper initialization of memory prior to accessing it. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-20566. |
| OpenJPEG is an open-source JPEG 2000 codec. In OpenJPEG 2.5.3 and earlier, a call to opj_jp2_read_header may lead to OOB heap memory write when the data stream p_stream is too short and p_image is not initialized. |
| OpenCV is an Open Source Computer Vision Library. Versions prior to 4.12.0 have an uninitialized pointer variable on stack that may lead to arbitrary heap buffer write when reading crafted JPEG images. Version 4.12.0 fixes the vulnerability. |
| The Honeywell Experion PKS contains an Uninitialized Variable in the common Epic Platform Analyzer (EPA) communications. An attacker could potentially exploit this vulnerability, leading to a Communication Channel Manipulation, which results in a dereferencing of an uninitialized pointer leading to a denial of service.
Honeywell recommends updating to the most recent version of
Honeywell Experion PKS: 520.2 TCU9 HF1and 530.1 TCU3 HF1. The affected Experion PKS products are
C300 PCNT02, EHB, EHPM, ELMM, Classic ENIM, ETN, FIM4, FIM8, PGM, and RFIM. The Experion PKS versions affected are from 520.1 through 520.2 TCU9 and from 530 through 530 TCU3. |
| A vulnerability in the SSL/TLS handler of Cisco Adaptive Security Appliance (ASA) Software could allow an unauthenticated, remote attacker to cause the affected device to reload unexpectedly, leading to a denial of service (DoS) condition.
The vulnerability is due to improper error handling on established SSL/TLS connections. An attacker could exploit this vulnerability by establishing an SSL/TLS connection with the affected device and then sending a malicious SSL/TLS message within that connection. A successful exploit could allow the attacker to cause the device to reload.Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability. |
| A vulnerability was found in pkcs15-init in OpenSC. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs.
Insufficient or missing checking of return values of functions leads to unexpected work with variables that have not been initialized. |
| A vulnerability was found in OpenSC, OpenSC tools, PKCS#11 module, minidriver, and CTK. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs.
Insufficient or missing checking of return values of functions leads to unexpected work with variables that have not been initialized. |
| A vulnerability was found in OpenSC, OpenSC tools, PKCS#11 module, minidriver, and CTK. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs.
The following problems were caused by insufficient control of the response APDU buffer and its length when communicating with the card. |
| A vulnerability was found in OpenSC, OpenSC tools, PKCS#11 module, minidriver, and CTK.
The problem is missing initialization of variables expected to be initialized (as arguments to other functions, etc.). |
| On 64-bit platforms IonMonkey-JIT only wrote 32 bits of the 64-bit return value space on the stack. Baseline-JIT, however, read the entire 64 bits. This vulnerability affects Firefox < 141, Firefox ESR < 115.26, Firefox ESR < 128.13, Firefox ESR < 140.1, Thunderbird < 141, Thunderbird < 128.13, and Thunderbird < 140.1. |
| Use of Uninitialized Variable vulnerability exists in the JT file reading procedure in SOLIDWORKS eDrawings on Release SOLIDWORKS Desktop 2025. This vulnerability could allow an attacker to execute arbitrary code while opening a specially crafted JT file. |
| A local code execution vulnerability exists in the Rockwell Automation Arena® due to an uninitialized pointer. The flaw is result of improper validation of user-supplied data. If exploited a threat actor can disclose information and execute arbitrary code on the system. To exploit the vulnerability a legitimate user must open a malicious DOE file. |
| A local code execution vulnerability exists in the Rockwell Automation Arena® due to an uninitialized pointer. The flaw is result of improper validation of user-supplied data. If exploited a threat actor can disclose information and execute arbitrary code on the system. To exploit the vulnerability a legitimate user must open a malicious DOE file. |
| A local code execution vulnerability exists in the Rockwell Automation Arena® due to an uninitialized pointer. The flaw is result of improper validation of user-supplied data. If exploited a threat actor can disclose information and execute arbitrary code on the system. To exploit the vulnerability a legitimate user must open a malicious DOE file. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8195: Add platform entry for ETDM1_OUT_BE dai link
Commit e70b8dd26711 ("ASoC: mediatek: mt8195: Remove afe-dai component
and rework codec link") removed the codec entry for the ETDM1_OUT_BE
dai link entirely instead of replacing it with COMP_EMPTY(). This worked
by accident as the remaining COMP_EMPTY() platform entry became the codec
entry, and the platform entry became completely empty, effectively the
same as COMP_DUMMY() since snd_soc_fill_dummy_dai() doesn't do anything
for platform entries.
This causes a KASAN out-of-bounds warning in mtk_soundcard_common_probe()
in sound/soc/mediatek/common/mtk-soundcard-driver.c:
for_each_card_prelinks(card, i, dai_link) {
if (adsp_node && !strncmp(dai_link->name, "AFE_SOF", strlen("AFE_SOF")))
dai_link->platforms->of_node = adsp_node;
else if (!dai_link->platforms->name && !dai_link->platforms->of_node)
dai_link->platforms->of_node = platform_node;
}
where the code expects the platforms array to have space for at least one entry.
Add an COMP_EMPTY() entry so that dai_link->platforms has space. |
| In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when devlink reload during initialization
The devlink reload process will access the hardware resources,
but the register operation is done before the hardware is initialized.
So, processing the devlink reload during initialization may lead to kernel
crash.
This patch fixes this by registering the devlink after
hardware initialization. |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-msm: pervent access to suspended controller
Generic sdhci code registers LED device and uses host->runtime_suspended
flag to protect access to it. The sdhci-msm driver doesn't set this flag,
which causes a crash when LED is accessed while controller is runtime
suspended. Fix this by setting the flag correctly. |
| In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()
Under certain kernel configurations when building with Clang/LLVM, the
compiler does not generate a return or jump as the terminator
instruction for ip_vs_protocol_init(), triggering the following objtool
warning during build time:
vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()
At runtime, this either causes an oops when trying to load the ipvs
module or a boot-time panic if ipvs is built-in. This same issue has
been reported by the Intel kernel test robot previously.
Digging deeper into both LLVM and the kernel code reveals this to be a
undefined behavior problem. ip_vs_protocol_init() uses a on-stack buffer
of 64 chars to store the registered protocol names and leaves it
uninitialized after definition. The function calls strnlen() when
concatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCE
strnlen() performs an extra step to check whether the last byte of the
input char buffer is a null character (commit 3009f891bb9f ("fortify:
Allow strlen() and strnlen() to pass compile-time known lengths")).
This, together with possibly other configurations, cause the following
IR to be generated:
define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 {
%1 = alloca [64 x i8], align 16
...
14: ; preds = %11
%15 = getelementptr inbounds i8, ptr %1, i64 63
%16 = load i8, ptr %15, align 1
%17 = tail call i1 @llvm.is.constant.i8(i8 %16)
%18 = icmp eq i8 %16, 0
%19 = select i1 %17, i1 %18, i1 false
br i1 %19, label %20, label %23
20: ; preds = %14
%21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23
...
23: ; preds = %14, %11, %20
%24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24
...
}
The above code calculates the address of the last char in the buffer
(value %15) and then loads from it (value %16). Because the buffer is
never initialized, the LLVM GVN pass marks value %16 as undefined:
%13 = getelementptr inbounds i8, ptr %1, i64 63
br i1 undef, label %14, label %17
This gives later passes (SCCP, in particular) more DCE opportunities by
propagating the undef value further, and eventually removes everything
after the load on the uninitialized stack location:
define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 {
%1 = alloca [64 x i8], align 16
...
12: ; preds = %11
%13 = getelementptr inbounds i8, ptr %1, i64 63
unreachable
}
In this way, the generated native code will just fall through to the
next function, as LLVM does not generate any code for the unreachable IR
instruction and leaves the function without a terminator.
Zero the on-stack buffer to avoid this possible UB. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_IDLETIMER: fix panic that occurs when timer_type has garbage value
Currently, when the rule related to IDLETIMER is added, idletimer_tg timer
structure is initialized by kmalloc on executing idletimer_tg_create
function. However, in this process timer->timer_type is not defined to
a specific value. Thus, timer->timer_type has garbage value and it occurs
kernel panic. So, this commit fixes the panic by initializing
timer->timer_type using kzalloc instead of kmalloc.
Test commands:
# iptables -A OUTPUT -j IDLETIMER --timeout 1 --label test
$ cat /sys/class/xt_idletimer/timers/test
Killed
Splat looks like:
BUG: KASAN: user-memory-access in alarm_expires_remaining+0x49/0x70
Read of size 8 at addr 0000002e8c7bc4c8 by task cat/917
CPU: 12 PID: 917 Comm: cat Not tainted 5.14.0+ #3 79940a339f71eb14fc81aee1757a20d5bf13eb0e
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
dump_stack_lvl+0x6e/0x9c
kasan_report.cold+0x112/0x117
? alarm_expires_remaining+0x49/0x70
__asan_load8+0x86/0xb0
alarm_expires_remaining+0x49/0x70
idletimer_tg_show+0xe5/0x19b [xt_IDLETIMER 11219304af9316a21bee5ba9d58f76a6b9bccc6d]
dev_attr_show+0x3c/0x60
sysfs_kf_seq_show+0x11d/0x1f0
? device_remove_bin_file+0x20/0x20
kernfs_seq_show+0xa4/0xb0
seq_read_iter+0x29c/0x750
kernfs_fop_read_iter+0x25a/0x2c0
? __fsnotify_parent+0x3d1/0x570
? iov_iter_init+0x70/0x90
new_sync_read+0x2a7/0x3d0
? __x64_sys_llseek+0x230/0x230
? rw_verify_area+0x81/0x150
vfs_read+0x17b/0x240
ksys_read+0xd9/0x180
? vfs_write+0x460/0x460
? do_syscall_64+0x16/0xc0
? lockdep_hardirqs_on+0x79/0x120
__x64_sys_read+0x43/0x50
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f0cdc819142
Code: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
RSP: 002b:00007fff28eee5b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f0cdc819142
RDX: 0000000000020000 RSI: 00007f0cdc032000 RDI: 0000000000000003
RBP: 00007f0cdc032000 R08: 00007f0cdc031010 R09: 0000000000000000
R10: 0000000000000022 R11: 0000000000000246 R12: 00005607e9ee31f0
R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 |
