| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| NULL Pointer Dereference vulnerability in visualfc liteide (liteidex/src/3rdparty/libvterm/src modules). This vulnerability is associated with program files screen.C, state.C, vterm.C.
This issue affects liteide: before x38.4. |
| NULL Pointer Dereference vulnerability in abcz316 SKRoot-linuxKernelRoot (testRoot/jni/utils modules). This vulnerability is associated with program files cJSON.Cpp.
This issue affects SKRoot-linuxKernelRoot. |
| Out-of-bounds Write, Divide By Zero, NULL Pointer Dereference, Use of Uninitialized Resource, Out-of-bounds Read, Reachable Assertion vulnerability in cadaver turso3d.This issue affects . |
| Issue summary: PBMAC1 parameters in PKCS#12 files are missing validation
which can trigger a stack-based buffer overflow, invalid pointer or NULL
pointer dereference during MAC verification.
Impact summary: The stack buffer overflow or NULL pointer dereference may
cause a crash leading to Denial of Service for an application that parses
untrusted PKCS#12 files. The buffer overflow may also potentially enable
code execution depending on platform mitigations.
When verifying a PKCS#12 file that uses PBMAC1 for the MAC, the PBKDF2
salt and keylength parameters from the file are used without validation.
If the value of keylength exceeds the size of the fixed stack buffer used
for the derived key (64 bytes), the key derivation will overflow the buffer.
The overflow length is attacker-controlled. Also, if the salt parameter is
not an OCTET STRING type this can lead to invalid or NULL pointer
dereference.
Exploiting this issue requires a user or application to process
a maliciously crafted PKCS#12 file. It is uncommon to accept untrusted
PKCS#12 files in applications as they are usually used to store private
keys which are trusted by definition. For this reason the issue was assessed
as Moderate severity.
The FIPS modules in 3.6, 3.5 and 3.4 are not affected by this issue, as
PKCS#12 processing is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5 and 3.4 are vulnerable to this issue.
OpenSSL 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue as they do
not support PBMAC1 in PKCS#12. |
| In GnuPG before 2.5.17, a long signature packet length causes parse_signature to return success with sig->data[] set to a NULL value, leading to a denial of service (application crash). |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Harden uplink netdev access against device unbind
The function mlx5_uplink_netdev_get() gets the uplink netdevice
pointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can
be removed and its pointer cleared when unbound from the mlx5_core.eth
driver. This results in a NULL pointer, causing a kernel panic.
BUG: unable to handle page fault for address: 0000000000001300
at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core]
Call Trace:
<TASK>
mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core]
esw_offloads_enable+0x593/0x910 [mlx5_core]
mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core]
mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core]
devlink_nl_eswitch_set_doit+0x60/0xd0
genl_family_rcv_msg_doit+0xe0/0x130
genl_rcv_msg+0x183/0x290
netlink_rcv_skb+0x4b/0xf0
genl_rcv+0x24/0x40
netlink_unicast+0x255/0x380
netlink_sendmsg+0x1f3/0x420
__sock_sendmsg+0x38/0x60
__sys_sendto+0x119/0x180
do_syscall_64+0x53/0x1d0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
Ensure the pointer is valid before use by checking it for NULL. If it
is valid, immediately call netdev_hold() to take a reference, and
preventing the netdevice from being freed while it is in use. |
| Null pointer dereference in Windows Local Security Authority Subsystem Service (LSASS) allows an unauthorized attacker to deny service over a network. |
| In the Linux kernel, the following vulnerability has been resolved:
net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer
Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from
device property") rfkill_find_type() gets called with the possibly
uninitialized "const char *type_name;" local variable.
On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"
acpi_device, the rfkill->type is set based on the ACPI acpi_device_id:
rfkill->type = (unsigned)id->driver_data;
and there is no "type" property so device_property_read_string() will fail
and leave type_name uninitialized, leading to a potential crash.
rfkill_find_type() does accept a NULL pointer, fix the potential crash
by initializing type_name to NULL.
Note likely sofar this has not been caught because:
1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device
2. The stack happened to contain NULL where type_name is stored |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked()
When
9770b428b1a2 ("crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown")
moved the error messages dumping so that they don't need to be issued by
the callers, it missed the case where __sev_firmware_shutdown() calls
__sev_platform_shutdown_locked() with a NULL argument which leads to
a NULL ptr deref on the shutdown path, during suspend to disk:
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 983 Comm: hib.sh Not tainted 6.17.0-rc4+ #1 PREEMPT(voluntary)
Hardware name: Supermicro Super Server/H12SSL-i, BIOS 2.5 09/08/2022
RIP: 0010:__sev_platform_shutdown_locked.cold+0x0/0x21 [ccp]
That rIP is:
00000000000006fd <__sev_platform_shutdown_locked.cold>:
6fd: 8b 13 mov (%rbx),%edx
6ff: 48 8b 7d 00 mov 0x0(%rbp),%rdi
703: 89 c1 mov %eax,%ecx
Code: 74 05 31 ff 41 89 3f 49 8b 3e 89 ea 48 c7 c6 a0 8e 54 a0 41 bf 92 ff ff ff e8 e5 2e 09 e1 c6 05 2a d4 38 00 01 e9 26 af ff ff <8b> 13 48 8b 7d 00 89 c1 48 c7 c6 18 90 54 a0 89 44 24 04 e8 c1 2e
RSP: 0018:ffffc90005467d00 EFLAGS: 00010282
RAX: 00000000ffffff92 RBX: 0000000000000000 RCX: 0000000000000000
^^^^^^^^^^^^^^^^
and %rbx is nice and clean.
Call Trace:
<TASK>
__sev_firmware_shutdown.isra.0
sev_dev_destroy
psp_dev_destroy
sp_destroy
pci_device_shutdown
device_shutdown
kernel_power_off
hibernate.cold
state_store
kernfs_fop_write_iter
vfs_write
ksys_write
do_syscall_64
entry_SYSCALL_64_after_hwframe
Pass in a pointer to the function-local error var in the caller.
With that addressed, suspending the ccp shows the error properly at
least:
ccp 0000:47:00.1: sev command 0x2 timed out, disabling PSP
ccp 0000:47:00.1: SEV: failed to SHUTDOWN error 0x0, rc -110
SEV-SNP: Leaking PFN range 0x146800-0x146a00
SEV-SNP: PFN 0x146800 unassigned, dumping non-zero entries in 2M PFN region: [0x146800 - 0x146a00]
...
ccp 0000:47:00.1: SEV-SNP firmware shutdown failed, rc -16, error 0x0
ACPI: PM: Preparing to enter system sleep state S5
kvm: exiting hardware virtualization
reboot: Power down
Btw, this driver is crying to be cleaned up to pass in a proper I/O
struct which can be used to store information between the different
functions, otherwise stuff like that will happen in the future again. |
| The Tapo C220 v1 and C520WS v2 cameras’ HTTP service does not safely handle POST requests containing an excessively large Content-Length header. The resulting failed memory allocation triggers a NULL pointer dereference, causing the main service process to crash. An unauthenticated attacker can repeatedly crash the service, causing temporary denial of service. The device restarts automatically, and repeated requests can keep it unavailable. |
| Issue summary: Processing a malformed PKCS#12 file can trigger a NULL pointer
dereference in the PKCS12_item_decrypt_d2i_ex() function.
Impact summary: A NULL pointer dereference can trigger a crash which leads to
Denial of Service for an application processing PKCS#12 files.
The PKCS12_item_decrypt_d2i_ex() function does not check whether the oct
parameter is NULL before dereferencing it. When called from
PKCS12_unpack_p7encdata() with a malformed PKCS#12 file, this parameter can
be NULL, causing a crash. The vulnerability is limited to Denial of Service
and cannot be escalated to achieve code execution or memory disclosure.
Exploiting this issue requires an attacker to provide a malformed PKCS#12 file
to an application that processes it. For that reason the issue was assessed as
Low severity according to our Security Policy.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue. |
| Issue summary: If an application using the SSL_CIPHER_find() function in
a QUIC protocol client or server receives an unknown cipher suite from
the peer, a NULL dereference occurs.
Impact summary: A NULL pointer dereference leads to abnormal termination of
the running process causing Denial of Service.
Some applications call SSL_CIPHER_find() from the client_hello_cb callback
on the cipher ID received from the peer. If this is done with an SSL object
implementing the QUIC protocol, NULL pointer dereference will happen if
the examined cipher ID is unknown or unsupported.
As it is not very common to call this function in applications using the QUIC
protocol and the worst outcome is Denial of Service, the issue was assessed
as Low severity.
The vulnerable code was introduced in the 3.2 version with the addition
of the QUIC protocol support.
The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue,
as the QUIC implementation is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.
OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue. |
| In the Linux kernel, the following vulnerability has been resolved:
can: gs_usb: fix time stamp counter initialization
If the gs_usb device driver is unloaded (or unbound) before the
interface is shut down, the USB stack first calls the struct
usb_driver::disconnect and then the struct net_device_ops::ndo_stop
callback.
In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more
RX'ed CAN frames are send from the USB device to the host. Later in
gs_can_close() a reset control message is send to each CAN channel to
remove the controller from the CAN bus. In this race window the USB
device can still receive CAN frames from the bus and internally queue
them to be send to the host.
At least in the current version of the candlelight firmware, the queue
of received CAN frames is not emptied during the reset command. After
loading (or binding) the gs_usb driver, new URBs are submitted during
the struct net_device_ops::ndo_open callback and the candlelight
firmware starts sending its already queued CAN frames to the host.
However, this scenario was not considered when implementing the
hardware timestamp function. The cycle counter/time counter
infrastructure is set up (gs_usb_timestamp_init()) after the USBs are
submitted, resulting in a NULL pointer dereference if
timecounter_cyc2time() (via the call chain:
gs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() ->
gs_usb_skb_set_timestamp()) is called too early.
Move the gs_usb_timestamp_init() function before the URBs are
submitted to fix this problem.
For a comprehensive solution, we need to consider gs_usb devices with
more than 1 channel. The cycle counter/time counter infrastructure is
setup per channel, but the RX URBs are per device. Once gs_can_open()
of _a_ channel has been called, and URBs have been submitted, the
gs_usb_receive_bulk_callback() can be called for _all_ available
channels, even for channels that are not running, yet. As cycle
counter/time counter has not set up, this will again lead to a NULL
pointer dereference.
Convert the cycle counter/time counter from a "per channel" to a "per
device" functionality. Also set it up, before submitting any URBs to
the device.
Further in gs_usb_receive_bulk_callback(), don't process any URBs for
not started CAN channels, only resubmit the URB. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k. |
| A NULL Pointer Dereference vulnerability in the flow daemon (flowd) of Juniper Networks Junos OS on SRX Series allows an attacker causing specific, valid control traffic to be sent out of a Dual-Stack (DS) Lite tunnel to crash the flowd process, resulting in a Denial of Service (DoS). Continuous triggering of specific control traffic will create a sustained Denial of Service (DoS) condition.
On all SRX platforms, when specific, valid control traffic needs to be sent out of a DS-Lite tunnel, a segmentation fault occurs within the flowd process, resulting in a network outage until the flowd process restarts.
This issue affects Junos OS on SRX Series:
* All versions before 21.2R3-S9,
* from 21.4 before 21.4R3-S9,
* from 22.2 before 22.2R3-S5,
* from 22.4 before 22.4R3-S6,
* from 23.2 before 23.2R2-S3,
* from 23.4 before 23.4R2. |
| A NULL Pointer Dereference vulnerability in the
packet forwarding engine (pfe) of Juniper Networks Junos OS on MX304, MX with MPC10/11/LC9600, and EX9200 with EX9200-15C allows a locally authenticated attacker with low privileges to cause a Denial of Service (DoS).
In a VPLS or Junos Fusion scenario, the execution of specific show commands will cause all FPCs hosting VPLS sessions or connecting to satellites to crash and restart.
This issue affects Junos on MX304, MX with MPC10/11/LC9600 and EX9200 with EX9200-15C:
* All version before 21.2R3-S1,
* 21.3 versions before 21.3R3,
* 21.4 versions before 21.4R2. |
| A NULL Pointer Dereference vulnerability in the Packet Forwarding Engine (pfe) of Juniper Networks Junos OS allows a local, low-privileged attacker to cause a Denial-of-Service (DoS).
When a specific command is executed, the pfe crashes. This will cause traffic forwarding to be interrupted until the system self-recovers. Repeated execution will create a sustained DoS condition.
This issue only affects MX Series devices with Line cards MPC1-MPC9.
This issue affects:
Junos OS on MX Series:
* All versions before 21.4R3-S9,
* from 22.2 before 22.2R3-S5,
* from 22.3 before 22.3R3-S4,
* from 22.4 before 22.4R3-S2,
* from 23.2 before 23.2R2-S1,
* from 23.4 before 23.4R2. |
| In Alinto SOPE SOGo 2.0.2 through 5.12.2, sope-core/NGExtensions/NGHashMap.m allows a NULL pointer dereference and SOGo crash via a request in which a parameter in the query string is a duplicate of a parameter in the POST body. |
| In Deark before 1.5.8, a specially crafted input file can cause a NULL pointer dereference in the dbuf_write function (src/deark-dbuf.c). |
| iccDEV provides libraries and tools for interacting with, manipulating, and applying ICC color management profiles. Versions 2.3.1.1 and below have Undefined Behavior and Null Pointer Deference in CIccTagXmlFloatNum<>::ParseXml(). This occurs when user-controllable input is unsafely incorporated into ICC profile data or other structured binary blobs. Successful exploitation may allow an attacker to perform DoS, manipulate data, bypass application logic and Code Execution. This issue has been fixed in version 2.3.1.2. |
