| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An unauthenticated remote attacker may trigger a NULL pointer dereference in the affected CODESYS Control runtime systems by sending specially crafted communication requests, potentially leading to a denial-of-service (DoS) condition. |
| Asterisk is an open source private branch exchange and telephony toolkit. In versions up to and including 18.26.2, between 20.00.0 and 20.15.0, 20.7-cert6, 21.00.0, 22.00.0 through 22.5.0, there is a remote DoS and possible RCE condition in `asterisk/res/res_stir_shaken /verification.c` that can be exploited when an attacker can set an arbitrary Identity header, or STIR/SHAKEN is enabled, with verification set in the SIP profile associated with the endpoint to be attacked. This is fixed in versions 18.26.3, 20.7-cert6, 20.15.1, 21.10.1 and 22.5.1. |
| A null pointer dereference vulnerability exists in the IOMap64.sys driver of ASUS AI Suite 3. The vulnerability can be triggered by a specially crafted input, which may lead to a system crash (BSOD). Refer to the '
Security Update for for AI Suite 3
' section on the ASUS Security Advisory for more information. |
| Null pointer dereference in some Zoom Workplace Apps for Windows may allow an authenticated user to conduct a denial of service via network access. |
| Null pointer dereference in some Zoom Workplace Apps for Windows may allow an authenticated user to conduct a denial of service via network access. |
| A vulnerability has been found in GNU Binutils 2.44 and classified as problematic. This vulnerability affects the function bfd_elf_get_str_section of the file bfd/elf.c of the component BFD Library. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The name of the patch is db856d41004301b3a56438efd957ef5cabb91530. It is recommended to apply a patch to fix this issue. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: support non-r10 register spill/fill to/from stack in precision tracking
Use instruction (jump) history to record instructions that performed
register spill/fill to/from stack, regardless if this was done through
read-only r10 register, or any other register after copying r10 into it
*and* potentially adjusting offset.
To make this work reliably, we push extra per-instruction flags into
instruction history, encoding stack slot index (spi) and stack frame
number in extra 10 bit flags we take away from prev_idx in instruction
history. We don't touch idx field for maximum performance, as it's
checked most frequently during backtracking.
This change removes basically the last remaining practical limitation of
precision backtracking logic in BPF verifier. It fixes known
deficiencies, but also opens up new opportunities to reduce number of
verified states, explored in the subsequent patches.
There are only three differences in selftests' BPF object files
according to veristat, all in the positive direction (less states).
File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)
-------------------------------------- ------------- --------- --------- ------------- ---------- ---------- -------------
test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%)
xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%)
xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%)
Note, I avoided renaming jmp_history to more generic insn_hist to
minimize number of lines changed and potential merge conflicts between
bpf and bpf-next trees.
Notice also cur_hist_entry pointer reset to NULL at the beginning of
instruction verification loop. This pointer avoids the problem of
relying on last jump history entry's insn_idx to determine whether we
already have entry for current instruction or not. It can happen that we
added jump history entry because current instruction is_jmp_point(), but
also we need to add instruction flags for stack access. In this case, we
don't want to entries, so we need to reuse last added entry, if it is
present.
Relying on insn_idx comparison has the same ambiguity problem as the one
that was fixed recently in [0], so we avoid that.
[0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/ |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs
There are some cases, such as the one uncovered by Commit 46d4efcccc68
("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails")
where
msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL);
is called on gpu->pdev == NULL, as the GPU device has not been fully
initialized yet.
Turns out that there's more than just the aforementioned path that
causes this to happen (e.g. the case when there's speedbin data in the
catalog, but opp-supported-hw is missing in DT).
Assigning msm_gpu->pdev earlier seems like the least painful solution
to this, therefore do so.
Patchwork: https://patchwork.freedesktop.org/patch/602742/ |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix null ptr access msm_ioctl_gem_submit()
Fix the below null pointer dereference in msm_ioctl_gem_submit():
26545.260705: Call trace:
26545.263223: kref_put+0x1c/0x60
26545.266452: msm_ioctl_gem_submit+0x254/0x744
26545.270937: drm_ioctl_kernel+0xa8/0x124
26545.274976: drm_ioctl+0x21c/0x33c
26545.278478: drm_compat_ioctl+0xdc/0xf0
26545.282428: __arm64_compat_sys_ioctl+0xc8/0x100
26545.287169: el0_svc_common+0xf8/0x250
26545.291025: do_el0_svc_compat+0x28/0x54
26545.295066: el0_svc_compat+0x10/0x1c
26545.298838: el0_sync_compat_handler+0xa8/0xcc
26545.303403: el0_sync_compat+0x188/0x1c0
26545.307445: Code: d503201f d503201f 52800028 4b0803e8 (b8680008)
26545.318799: Kernel panic - not syncing: Oops: Fatal exception |
| Acrobat Reader versions 24.001.30235, 20.005.30763, 25.001.20521 and earlier are affected by a NULL Pointer Dereference vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to crash the application, causing a disruption in service. Exploitation of this issue requires user interaction in that a victim must open a malicious file. |
| A vulnerability was found in HDF5 up to 1.14.6 and classified as problematic. This issue affects the function H5O__cache_chk_serialize of the file src/H5Ocache.c. The manipulation leads to null pointer dereference. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. |
| cJSON v1.7.16 was discovered to contain a segmentation violation via the function cJSON_SetValuestring at cJSON.c. |
| DaveGamble/cJSON cJSON 1.7.8 is affected by: Improper Check for Unusual or Exceptional Conditions. The impact is: Null dereference, so attack can cause denial of service. The component is: cJSON_GetObjectItemCaseSensitive() function. The attack vector is: crafted json file. The fixed version is: 1.7.9 and later. |
| FFmpeg git master before commit fd1772 was discovered to contain a NULL pointer dereference via the component libavformat/mov.c. |
| In the Linux kernel, the following vulnerability has been resolved:
thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR
In some case, the GDDV returns a package with a buffer which has
zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).
Then the data_vault_read() got NULL point dereference problem when
accessing the 0x10 value in data_vault.
[ 71.024560] BUG: kernel NULL pointer dereference, address:
0000000000000010
This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or
NULL value in data_vault. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Atom Integrated System Info v2_2 for DCN35
New request from KMD/VBIOS in order to support new UMA carveout
model. This fixes a null dereference from accessing
Ctx->dc_bios->integrated_info while it was NULL.
DAL parses through the BIOS and extracts the necessary
integrated_info but was missing a case for the new BIOS
version 2.3. |
| Upon investigtion upstream maintainers discovered this was not a real issue. See the references for more details. See: https://gitlab.gnome.org/GNOME/libsoup/-/issues/430#note_2494090. |
| A NULL Pointer Dereference vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, network-based attacker to cause impact to the availability of the device.
When static route points to a reject next hop and a gNMI query is processed for that static route, rpd crashes and restarts.
This issue affects:
Junos OS: * all versions before 21.2R3-S9,
* 21.4 versions before 21.4R3-S10,
* 22.2 versions before 22.2R3-S6,
* 22.4 versions before 22.4R3-S6,
* 23.2 versions before 23.2R2-S3,
* 23.4 versions before 23.4R2-S4,
* 24.2 versions before 24.2R1-S2, 24.2R2;
Junos OS Evolved:
* all versions before 22.4R3-S7-EVO,
* 23.2-EVO
versions before 23.2R2-S3-EVO,
* 23.4-EVO versions before 23.4R2-S4-EVO,
* 24.2-EVO versions before 24.2R2-EVO. |
| Null pointer dereference vulnerability in the application exit cause module
Impact: Successful exploitation of this vulnerability may affect function stability. |
| After Effects versions 25.2, 24.6.6 and earlier are affected by a NULL Pointer Dereference vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to crash the application, causing disruption to services. Exploitation of this issue requires user interaction in that a victim must open a malicious file. |
