CWE-476
AllowedNULL Pointer Dereference
Abstraction: Base · Status: Stable
The product dereferences a pointer that it expects to be valid but is NULL.
6348 vulnerabilities reference this CWE, most recent first.
GHSA-44PM-Q7MW-V83G
Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-02-12 18:30In the Linux kernel, the following vulnerability has been resolved:
net: wwan: iosm: fix NULL pointer dereference when removing device
In suspend and resume cycle, the removal and rescan of device ends up in NULL pointer dereference.
During driver initialization, if the ipc_imem_wwan_channel_init() fails to get the valid device capabilities it returns an error and further no resource (wwan struct) will be allocated. Now in this situation if driver removal procedure is initiated it would result in NULL pointer exception since unallocated wwan struct is dereferenced inside ipc_wwan_deinit().
ipc_imem_run_state_worker() to handle the called functions return value and to release the resource in failure case. It also reports the link down event in failure cases. The user space application can handle this event to do a device reset for restoring the device communication.
{
"affected": [],
"aliases": [
"CVE-2023-53561"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T16:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: iosm: fix NULL pointer dereference when removing device\n\nIn suspend and resume cycle, the removal and rescan of device ends\nup in NULL pointer dereference.\n\nDuring driver initialization, if the ipc_imem_wwan_channel_init()\nfails to get the valid device capabilities it returns an error and\nfurther no resource (wwan struct) will be allocated. Now in this\nsituation if driver removal procedure is initiated it would result\nin NULL pointer exception since unallocated wwan struct is dereferenced\ninside ipc_wwan_deinit().\n\nipc_imem_run_state_worker() to handle the called functions return value\nand to release the resource in failure case. It also reports the link\ndown event in failure cases. The user space application can handle this\nevent to do a device reset for restoring the device communication.",
"id": "GHSA-44pm-q7mw-v83g",
"modified": "2026-02-12T18:30:18Z",
"published": "2025-10-04T18:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53561"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60829145f1e2650b31ebe6a0ec70a9725b38fa2c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/862c6e3e26735247d8a4df41fa2421909c3f4d63"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ee44bacf462db3ec6e4f0dcfa7931e768670d77c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-44VJ-X828-CFMJ
Vulnerability from github – Published: 2025-03-11 18:32 – Updated: 2025-03-11 18:32Null pointer dereference in Windows Kernel Memory allows an authorized attacker to deny service locally.
{
"affected": [],
"aliases": [
"CVE-2025-24997"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-11T17:16:37Z",
"severity": "MODERATE"
},
"details": "Null pointer dereference in Windows Kernel Memory allows an authorized attacker to deny service locally.",
"id": "GHSA-44vj-x828-cfmj",
"modified": "2025-03-11T18:32:19Z",
"published": "2025-03-11T18:32:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24997"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-24997"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-44W9-25WR-FJWF
Vulnerability from github – Published: 2024-09-10 12:30 – Updated: 2024-09-10 12:30A vulnerability has been identified in SIMATIC CP 1242-7 V2 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-7 LTE (All versions < V3.5.20), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions < V3.5.20), SIMATIC HMI Comfort Panels (incl. SIPLUS variants) (All versions), SIMATIC IPC DiagBase (All versions), SIMATIC IPC DiagMonitor (All versions), SIMATIC WinCC Runtime Advanced (All versions), SIPLUS TIM 1531 IRC (6AG1543-1MX00-7XE0) (All versions < V2.4.8), TIM 1531 IRC (6GK7543-1MX00-0XE0) (All versions < V2.4.8). The web server of the affected devices do not properly handle the shutdown or reboot request, which could lead to the clean up of certain resources.
This could allow a remote attacker with elevated privileges to cause a denial of service condition in the system.
{
"affected": [],
"aliases": [
"CVE-2023-30755"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-10T10:15:05Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been identified in SIMATIC CP 1242-7 V2 (incl. SIPLUS variants) (All versions \u003c V3.5.20), SIMATIC CP 1243-1 (incl. SIPLUS variants) (All versions \u003c V3.5.20), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions \u003c V3.5.20), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions \u003c V3.5.20), SIMATIC CP 1243-7 LTE (All versions \u003c V3.5.20), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions \u003c V3.5.20), SIMATIC HMI Comfort Panels (incl. SIPLUS variants) (All versions), SIMATIC IPC DiagBase (All versions), SIMATIC IPC DiagMonitor (All versions), SIMATIC WinCC Runtime Advanced (All versions), SIPLUS TIM 1531 IRC (6AG1543-1MX00-7XE0) (All versions \u003c V2.4.8), TIM 1531 IRC (6GK7543-1MX00-0XE0) (All versions \u003c V2.4.8). The web server of the affected devices do not properly handle the shutdown or reboot request, which could lead to the clean up of certain resources. \n\nThis could allow a remote attacker with elevated privileges to cause a denial of service condition in the system.",
"id": "GHSA-44w9-25wr-fjwf",
"modified": "2024-09-10T12:30:37Z",
"published": "2024-09-10T12:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30755"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-423808.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-44WR-9XPQ-76V2
Vulnerability from github – Published: 2024-04-04 09:30 – Updated: 2024-10-31 21:31In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV
When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to NULL pointer exception:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000020847ad4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+) MSR: 800000000280b033 CR: 48288244 XER: 00000008 CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1 ... NIP _find_next_zero_bit+0x24/0x110 LR bitmap_find_next_zero_area_off+0x5c/0xe0 Call Trace: dev_printk_emit+0x38/0x48 (unreliable) iommu_area_alloc+0xc4/0x180 iommu_range_alloc+0x1e8/0x580 iommu_alloc+0x60/0x130 iommu_alloc_coherent+0x158/0x2b0 dma_iommu_alloc_coherent+0x3c/0x50 dma_alloc_attrs+0x170/0x1f0 mlx5_cmd_init+0xc0/0x760 [mlx5_core] mlx5_function_setup+0xf0/0x510 [mlx5_core] mlx5_init_one+0x84/0x210 [mlx5_core] probe_one+0x118/0x2c0 [mlx5_core] local_pci_probe+0x68/0x110 pci_call_probe+0x68/0x200 pci_device_probe+0xbc/0x1a0 really_probe+0x104/0x540 __driver_probe_device+0xb4/0x230 driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x130 driver_attach+0x34/0x50 bus_add_driver+0x16c/0x300 driver_register+0xa4/0x1b0 __pci_register_driver+0x68/0x80 mlx5_init+0xb8/0x100 [mlx5_core] do_one_initcall+0x60/0x300 do_init_module+0x7c/0x2b0
At the time of LPAR dump, before kexec hands over control to kdump kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT. For the SR-IOV case, default DMA window "ibm,dma-window" is removed from the FDT and DDW added, for the device.
Now, kexec hands over control to the kdump kernel.
When the kdump kernel initializes, PCI busses are scanned and IOMMU group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV case, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba, fixes the path where memory is pre-mapped (direct mapped) to the DDW. When TCEs are direct mapped, there is no need to initialize IOMMU tables.
iommu_table_setparms_lpar() only considers "ibm,dma-window" property when initiallizing IOMMU table. In the scenario where TCEs are dynamically allocated for SR-IOV, newly created IOMMU table is not initialized. Later, when the device driver tries to enter TCEs for the SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().
The fix is to initialize the IOMMU table with DDW property stored in the FDT. There are 2 points to remember:
1. For the dedicated adapter, kdump kernel would encounter both
default and DDW in FDT. In this case, DDW property is used to
initialize the IOMMU table.
2. A DDW could be direct or dynamic mapped. kdump kernel would
initialize IOMMU table and mark the existing DDW as
"dynamic". This works fine since, at the time of table
initialization, iommu_table_clear() makes some space in the
DDW, for some predefined number of TCEs which are needed for
kdump to succeed.
{
"affected": [],
"aliases": [
"CVE-2024-26745"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-04T09:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV\n\nWhen kdump kernel tries to copy dump data over SR-IOV, LPAR panics due\nto NULL pointer exception:\n\n Kernel attempted to read user page (0) - exploit attempt? (uid: 0)\n BUG: Kernel NULL pointer dereference on read at 0x00000000\n Faulting instruction address: 0xc000000020847ad4\n Oops: Kernel access of bad area, sig: 11 [#1]\n LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop\n CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12\n Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries\n NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c\n REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+)\n MSR: 800000000280b033 \u003cSF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE\u003e CR: 48288244 XER: 00000008\n CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1\n ...\n NIP _find_next_zero_bit+0x24/0x110\n LR bitmap_find_next_zero_area_off+0x5c/0xe0\n Call Trace:\n dev_printk_emit+0x38/0x48 (unreliable)\n iommu_area_alloc+0xc4/0x180\n iommu_range_alloc+0x1e8/0x580\n iommu_alloc+0x60/0x130\n iommu_alloc_coherent+0x158/0x2b0\n dma_iommu_alloc_coherent+0x3c/0x50\n dma_alloc_attrs+0x170/0x1f0\n mlx5_cmd_init+0xc0/0x760 [mlx5_core]\n mlx5_function_setup+0xf0/0x510 [mlx5_core]\n mlx5_init_one+0x84/0x210 [mlx5_core]\n probe_one+0x118/0x2c0 [mlx5_core]\n local_pci_probe+0x68/0x110\n pci_call_probe+0x68/0x200\n pci_device_probe+0xbc/0x1a0\n really_probe+0x104/0x540\n __driver_probe_device+0xb4/0x230\n driver_probe_device+0x54/0x130\n __driver_attach+0x158/0x2b0\n bus_for_each_dev+0xa8/0x130\n driver_attach+0x34/0x50\n bus_add_driver+0x16c/0x300\n driver_register+0xa4/0x1b0\n __pci_register_driver+0x68/0x80\n mlx5_init+0xb8/0x100 [mlx5_core]\n do_one_initcall+0x60/0x300\n do_init_module+0x7c/0x2b0\n\nAt the time of LPAR dump, before kexec hands over control to kdump\nkernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT.\nFor the SR-IOV case, default DMA window \"ibm,dma-window\" is removed from\nthe FDT and DDW added, for the device.\n\nNow, kexec hands over control to the kdump kernel.\n\nWhen the kdump kernel initializes, PCI busses are scanned and IOMMU\ngroup/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV\ncase, there is no \"ibm,dma-window\". The original commit: b1fc44eaa9ba,\nfixes the path where memory is pre-mapped (direct mapped) to the DDW.\nWhen TCEs are direct mapped, there is no need to initialize IOMMU\ntables.\n\niommu_table_setparms_lpar() only considers \"ibm,dma-window\" property\nwhen initiallizing IOMMU table. In the scenario where TCEs are\ndynamically allocated for SR-IOV, newly created IOMMU table is not\ninitialized. Later, when the device driver tries to enter TCEs for the\nSR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().\n\nThe fix is to initialize the IOMMU table with DDW property stored in the\nFDT. There are 2 points to remember:\n\n\t1. For the dedicated adapter, kdump kernel would encounter both\n\t default and DDW in FDT. In this case, DDW property is used to\n\t initialize the IOMMU table.\n\n\t2. A DDW could be direct or dynamic mapped. kdump kernel would\n\t initialize IOMMU table and mark the existing DDW as\n\t \"dynamic\". This works fine since, at the time of table\n\t initialization, iommu_table_clear() makes some space in the\n\t DDW, for some predefined number of TCEs which are needed for\n\t kdump to succeed.",
"id": "GHSA-44wr-9xpq-76v2",
"modified": "2024-10-31T21:31:44Z",
"published": "2024-04-04T09:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26745"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-452G-F7FP-9JF7
Vulnerability from github – Published: 2021-05-21 14:20 – Updated: 2024-10-30 23:13Impact
Calling TF operations with tensors of non-numeric types when the operations expect numeric tensors result in null pointer dereferences.
There are multiple ways to reproduce this, listing a few examples here:
import tensorflow as tf
import numpy as np
data = tf.random.truncated_normal(shape=1,mean=np.float32(20.8739),stddev=779.973,dtype=20,seed=64)
import tensorflow as tf
import numpy as np
data =
tf.random.stateless_truncated_normal(shape=1,seed=[63,70],mean=np.float32(20.8739),stddev=779.973,dtype=20)
import tensorflow as tf
import numpy as np
data = tf.one_hot(indices=[62,50],depth=136,on_value=np.int32(237),off_value=158,axis=856,dtype=20)
import tensorflow as tf
import numpy as np
data = tf.range(start=np.int32(214),limit=660,delta=129,dtype=20)
import tensorflow as tf
import numpy as np
data = tf.raw_ops.ResourceCountUpTo(resource=np.int32(30), limit=872, T=3)
import tensorflow as tf
import numpy as np
writer_array = np.array([1,2],dtype=np.int32)
writer_tensor = tf.convert_to_tensor(writer_array,dtype=tf.resource)
All these examples and similar ones have the same behavior: the conversion from Python array to C++ array is vulnerable to a type confusion:
int pyarray_type = PyArray_TYPE(array);
PyArray_Descr* descr = PyArray_DESCR(array);
switch (pyarray_type) {
...
case NPY_VOID:
// Quantized types are currently represented as custom struct types.
// PyArray_TYPE returns NPY_VOID for structs, and we should look into
// descr to derive the actual type.
// Direct feeds of certain types of ResourceHandles are represented as a
// custom struct type.
return PyArrayDescr_to_TF_DataType(descr, out_tf_datatype);
...
}
For the tensor types involved in the above example, the pyarray_type is NPY_VOID but the descr field is such that descr->field = NULL. Then PyArrayDescr_to_TF_DataType will trigger a null dereference:
Status PyArrayDescr_to_TF_DataType(PyArray_Descr* descr,
TF_DataType* out_tf_datatype) {
PyObject* key;
PyObject* value;
Py_ssize_t pos = 0;
if (PyDict_Next(descr->fields, &pos, &key, &value)) {
...
}
}
This is because the Python's PyDict_Next implementation would dereference the first argument.
Patches
We have patched the issue in GitHub commit 030af767d357d1b4088c4a25c72cb3906abac489.
The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.
For more information
Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.
Attribution
This vulnerability has been reported by members of the Aivul Team from Qihoo 360 as well as Ye Zhang and Yakun Zhang of Baidu X-Team.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-29513"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-18T23:42:09Z",
"nvd_published_at": "2021-05-14T20:15:00Z",
"severity": "LOW"
},
"details": "### Impact\nCalling TF operations with tensors of non-numeric types when the operations expect numeric tensors result in null pointer dereferences.\n\nThere are multiple ways to reproduce this, listing a few examples here:\n\n```python\nimport tensorflow as tf\nimport numpy as np\ndata = tf.random.truncated_normal(shape=1,mean=np.float32(20.8739),stddev=779.973,dtype=20,seed=64)\n```\n\n```python\nimport tensorflow as tf\nimport numpy as np\ndata =\ntf.random.stateless_truncated_normal(shape=1,seed=[63,70],mean=np.float32(20.8739),stddev=779.973,dtype=20)\n```\n\n```python\nimport tensorflow as tf\nimport numpy as np\ndata = tf.one_hot(indices=[62,50],depth=136,on_value=np.int32(237),off_value=158,axis=856,dtype=20)\n```\n\n```python\nimport tensorflow as tf\nimport numpy as np\ndata = tf.range(start=np.int32(214),limit=660,delta=129,dtype=20)\n```\n\n```python\nimport tensorflow as tf\nimport numpy as np\ndata = tf.raw_ops.ResourceCountUpTo(resource=np.int32(30), limit=872, T=3)\n```\n\n```python\nimport tensorflow as tf\nimport numpy as np\n\nwriter_array = np.array([1,2],dtype=np.int32)\nwriter_tensor = tf.convert_to_tensor(writer_array,dtype=tf.resource)\n```\n\nAll these examples and similar ones have the same behavior: the [conversion from Python array to C++ array](https://github.com/tensorflow/tensorflow/blob/ff70c47a396ef1e3cb73c90513da4f5cb71bebba/tensorflow/python/lib/core/ndarray_tensor.cc#L113-L169) is vulnerable to a type confusion:\n\n```cc\n int pyarray_type = PyArray_TYPE(array);\n PyArray_Descr* descr = PyArray_DESCR(array);\n switch (pyarray_type) {\n ...\n case NPY_VOID:\n // Quantized types are currently represented as custom struct types.\n // PyArray_TYPE returns NPY_VOID for structs, and we should look into\n // descr to derive the actual type.\n // Direct feeds of certain types of ResourceHandles are represented as a\n // custom struct type.\n return PyArrayDescr_to_TF_DataType(descr, out_tf_datatype);\n ...\n }\n```\n\nFor the tensor types involved in the above example, the `pyarray_type` is `NPY_VOID` but the `descr` field is such that `descr-\u003efield = NULL`. Then [`PyArrayDescr_to_TF_DataType`](https://github.com/tensorflow/tensorflow/blob/ff70c47a396ef1e3cb73c90513da4f5cb71bebba/tensorflow/python/lib/core/ndarray_tensor.cc#L72-L77) will trigger a null dereference:\n\n```cc\nStatus PyArrayDescr_to_TF_DataType(PyArray_Descr* descr,\n TF_DataType* out_tf_datatype) {\n PyObject* key;\n PyObject* value;\n Py_ssize_t pos = 0;\n if (PyDict_Next(descr-\u003efields, \u0026pos, \u0026key, \u0026value)) {\n ...\n }\n}\n```\n\nThis is because the Python\u0027s `PyDict_Next` implementation would dereference the first argument.\n\n### Patches\nWe have patched the issue in GitHub commit [030af767d357d1b4088c4a25c72cb3906abac489](https://github.com/tensorflow/tensorflow/commit/030af767d357d1b4088c4a25c72cb3906abac489).\n\nThe fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.\n\n### Attribution\nThis vulnerability has been reported by members of the Aivul Team from Qihoo 360 as well as Ye Zhang and Yakun Zhang of Baidu X-Team.",
"id": "GHSA-452g-f7fp-9jf7",
"modified": "2024-10-30T23:13:43Z",
"published": "2021-05-21T14:20:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-452g-f7fp-9jf7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29513"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/commit/030af767d357d1b4088c4a25c72cb3906abac489"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2021-441.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2021-639.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2021-150.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/tensorflow/tensorflow"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Type confusion during tensor casts lead to dereferencing null pointers"
}
GHSA-454X-H9G9-7VMJ
Vulnerability from github – Published: 2021-12-22 00:00 – Updated: 2021-12-28 00:01A null pointer dereference vulnerability exists in gpac 1.1.0 in the BD_CheckSFTimeOffset function, which causes a segmentation fault and application crash.
{
"affected": [],
"aliases": [
"CVE-2021-44922"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-21T21:15:00Z",
"severity": "MODERATE"
},
"details": "A null pointer dereference vulnerability exists in gpac 1.1.0 in the BD_CheckSFTimeOffset function, which causes a segmentation fault and application crash.",
"id": "GHSA-454x-h9g9-7vmj",
"modified": "2021-12-28T00:01:06Z",
"published": "2021-12-22T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44922"
},
{
"type": "WEB",
"url": "https://github.com/gpac/gpac/issues/1969"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4555-4GMG-WPCM
Vulnerability from github – Published: 2022-04-08 00:00 – Updated: 2022-04-16 00:01An authenticated remote attacker can cause a null pointer dereference in the CmpSettings component of the affected CODESYS products which leads to a crash.
{
"affected": [],
"aliases": [
"CVE-2022-22513"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-07T19:15:00Z",
"severity": "MODERATE"
},
"details": "An authenticated remote attacker can cause a null pointer dereference in the CmpSettings component of the affected CODESYS products which leads to a crash.",
"id": "GHSA-4555-4gmg-wpcm",
"modified": "2022-04-16T00:01:30Z",
"published": "2022-04-08T00:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22513"
},
{
"type": "WEB",
"url": "https://customers.codesys.com/index.php?eID=dumpFile\u0026t=f\u0026f=17093\u0026token=15cd8424832ea10dcd4873a409a09a539ee381ca\u0026download="
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-458Q-P5FC-J68H
Vulnerability from github – Published: 2022-05-17 00:27 – Updated: 2022-05-17 00:27The gs_makewordimagedevice function in base/gsdevmem.c in Artifex Software, Inc. Ghostscript 9.20 allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted file that is mishandled in the PDF Transparency module.
{
"affected": [],
"aliases": [
"CVE-2016-10220"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-03T05:59:00Z",
"severity": "MODERATE"
},
"details": "The gs_makewordimagedevice function in base/gsdevmem.c in Artifex Software, Inc. Ghostscript 9.20 allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted file that is mishandled in the PDF Transparency module.",
"id": "GHSA-458q-p5fc-j68h",
"modified": "2022-05-17T00:27:43Z",
"published": "2022-05-17T00:27:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10220"
},
{
"type": "WEB",
"url": "https://bugs.ghostscript.com/show_bug.cgi?id=697450"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201708-06"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3838"
},
{
"type": "WEB",
"url": "http://www.ghostscript.com/cgi-bin/findgit.cgi?daf85701dab05f17e924a48a81edc9195b4a04e8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-45FF-V9GQ-XWW8
Vulnerability from github – Published: 2025-03-12 12:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
smb: client: Add check for next_buffer in receive_encrypted_standard()
Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference.
{
"affected": [],
"aliases": [
"CVE-2025-21844"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-12T10:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Add check for next_buffer in receive_encrypted_standard()\n\nAdd check for the return value of cifs_buf_get() and cifs_small_buf_get()\nin receive_encrypted_standard() to prevent null pointer dereference.",
"id": "GHSA-45ff-v9gq-xww8",
"modified": "2026-05-12T15:30:50Z",
"published": "2025-03-12T12:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21844"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24e8e4523d3071bc5143b0db9127d511489f7b3b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/554736b583f529ee159aa95af9a0cbc12b5ffc96"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/860ca5e50f73c2a1cef7eefc9d39d04e275417f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e5d99a4cf2e23c716b44862975548415fae5391"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a9b0b4b29877cb4dc5d0842b59b5ccbacddb85bd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f277e479eea3d1aa18bc712abe1d2bf3dece2e30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f618aeb6cad2307e48a641379db610abcf593edf"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-45H5-CQQW-9RJW
Vulnerability from github – Published: 2022-05-14 03:07 – Updated: 2024-09-06 15:28A NULL pointer dereference (DoS) Vulnerability was found in the function aubio_source_avcodec_readframe in io/source_avcodec.c of aubio, which may lead to DoS when playing a crafted audio file.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "aubio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-17554"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": true,
"github_reviewed_at": "2023-08-02T22:37:01Z",
"nvd_published_at": "2017-12-12T01:29:00Z",
"severity": "MODERATE"
},
"details": "A NULL pointer dereference (DoS) Vulnerability was found in the function `aubio_source_avcodec_readframe` in io/source_avcodec.c of aubio, which may lead to DoS when playing a crafted audio file.",
"id": "GHSA-45h5-cqqw-9rjw",
"modified": "2024-09-06T15:28:38Z",
"published": "2022-05-14T03:07:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-17554"
},
{
"type": "WEB",
"url": "https://github.com/aubio/aubio/commit/a81b12a3b4174953b3bc7ef4c37103f4d5636740"
},
{
"type": "WEB",
"url": "https://github.com/IvanCql/vulnerability/blob/master/An%20NULL%20pointer%20dereference(DoS)%20Vulnerability%20was%20found%20in%20function%20%20aubio_source_avcodec_readframe%20of%20aubio.md"
},
{
"type": "PACKAGE",
"url": "https://github.com/aubio/aubio"
},
{
"type": "WEB",
"url": "https://github.com/aubio/aubio/blob/0.4.7/ChangeLog"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/aubio/PYSEC-2017-76.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Aubio is vulnerable to a NULL pointer dereference"
}
Mitigation MIT-56
For any pointers that could have been modified or provided from a function that can return NULL, check the pointer for NULL before use. When working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the check, and unlock when it has finished [REF-1484].
Mitigation
Select a programming language that is not susceptible to these issues.
Mitigation
Check the results of all functions that return a value and verify that the value is non-null before acting upon it.
Mitigation
Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.
Mitigation
Explicitly initialize all variables and other data stores, either during declaration or just before the first usage.
No CAPEC attack patterns related to this CWE.