Common Weakness Enumeration

CWE-476

Allowed

NULL Pointer Dereference

Abstraction: Base · Status: Stable

The product dereferences a pointer that it expects to be valid but is NULL.

6305 vulnerabilities reference this CWE, most recent first.

GHSA-62CC-P492-PJH2

Vulnerability from github – Published: 2025-09-23 15:31 – Updated: 2025-09-23 15:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Implement ref count for SRB

The timeout handler and the done function are racing. When qla2x00_async_iocb_timeout() starts to run it can be preempted by the normal response path (via the firmware?). qla24xx_async_gpsc_sp_done() releases the SRB unconditionally. When scheduling back to qla2x00_async_iocb_timeout() qla24xx_async_abort_cmd() will access an freed sp->qpair pointer:

qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xx_handle_gpsc_event 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xx_async_abort_cmd+0x1b/0x1c0 [qla2xxx]

Obvious solution to this is to introduce a reference counter. One reference is taken for the normal code path (the 'good' case) and one for the timeout path. As we always race between the normal good case and the timeout/abort handler we need to serialize it. Also we cannot assume any order between the handlers. Since this is slow path we can use proper synchronization via locks.

When we are able to cancel a timer (del_timer returns 1) we know there can't be any error handling in progress because the timeout handler hasn't expired yet, thus we can safely decrement the refcounter by one.

If we are not able to cancel the timer, we know an abort handler is running. We have to make sure we call sp->done() in the abort handlers before calling kref_put().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49159"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:00:53Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Implement ref count for SRB\n\nThe timeout handler and the done function are racing. When\nqla2x00_async_iocb_timeout() starts to run it can be preempted by the\nnormal response path (via the firmware?). qla24xx_async_gpsc_sp_done()\nreleases the SRB unconditionally. When scheduling back to\nqla2x00_async_iocb_timeout() qla24xx_async_abort_cmd() will access an freed\nsp-\u003eqpair pointer:\n\n  qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21.\n  qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21\n  qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400.\n  qla2xxx [0000:83:00.0]-28d8:0: qla24xx_handle_gpsc_event 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5\n  BUG: unable to handle kernel NULL pointer dereference at 0000000000000004\n  IP: qla24xx_async_abort_cmd+0x1b/0x1c0 [qla2xxx]\n\nObvious solution to this is to introduce a reference counter. One reference\nis taken for the normal code path (the \u0027good\u0027 case) and one for the timeout\npath. As we always race between the normal good case and the timeout/abort\nhandler we need to serialize it. Also we cannot assume any order between\nthe handlers. Since this is slow path we can use proper synchronization via\nlocks.\n\nWhen we are able to cancel a timer (del_timer returns 1) we know there\ncan\u0027t be any error handling in progress because the timeout handler hasn\u0027t\nexpired yet, thus we can safely decrement the refcounter by one.\n\nIf we are not able to cancel the timer, we know an abort handler is\nrunning. We have to make sure we call sp-\u003edone() in the abort handlers\nbefore calling kref_put().",
  "id": "GHSA-62cc-p492-pjh2",
  "modified": "2025-09-23T15:31:07Z",
  "published": "2025-09-23T15:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49159"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/31e6cdbe0eae37badceb5e0d4f06cf051432fd77"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ceda7f794f3dfe272491e93e3e93049f8be5f07b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e140723f78ff418c8df7d990e102e07b65c87d4a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e17111dd2fda81c35f309b1e5b6ab35809a375e7"
    }
  ],
  "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-62F8-J3HG-8HCG

Vulnerability from github – Published: 2022-05-13 01:26 – Updated: 2022-05-13 01:26
VLAI
Details

The counterToCSSValue function in CSSComputedStyleDeclaration.cpp in the Cascading Style Sheets (CSS) implementation in WebCore in WebKit before r82222, as used in Google Chrome before 11.0.696.43 and other products, does not properly handle access to the (1) counterIncrement and (2) counterReset attributes of CSSStyleDeclaration data provided by a getComputedStyle method call, which allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via crafted JavaScript code.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2011-1691"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2011-04-15T00:55:00Z",
    "severity": "MODERATE"
  },
  "details": "The counterToCSSValue function in CSSComputedStyleDeclaration.cpp in the Cascading Style Sheets (CSS) implementation in WebCore in WebKit before r82222, as used in Google Chrome before 11.0.696.43 and other products, does not properly handle access to the (1) counterIncrement and (2) counterReset attributes of CSSStyleDeclaration data provided by a getComputedStyle method call, which allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via crafted JavaScript code.",
  "id": "GHSA-62f8-j3hg-8hcg",
  "modified": "2022-05-13T01:26:06Z",
  "published": "2022-05-13T01:26:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-1691"
    },
    {
      "type": "WEB",
      "url": "https://bugs.webkit.org/show_bug.cgi?id=57266"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/66818"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A14365"
    },
    {
      "type": "WEB",
      "url": "http://code.google.com/p/chromium/issues/detail?id=77665"
    },
    {
      "type": "WEB",
      "url": "http://googlechromereleases.blogspot.com/2011/04/beta-channel-update_12.html"
    },
    {
      "type": "WEB",
      "url": "http://trac.webkit.org/changeset/82222"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-62FM-R774-57V7

Vulnerability from github – Published: 2024-01-09 18:30 – Updated: 2024-01-09 18:30
VLAI
Details

Microsoft Message Queuing Denial of Service Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-20661"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-09T18:15:49Z",
    "severity": "HIGH"
  },
  "details": "Microsoft Message Queuing Denial of Service Vulnerability",
  "id": "GHSA-62fm-r774-57v7",
  "modified": "2024-01-09T18:30:28Z",
  "published": "2024-01-09T18:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20661"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-20661"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-62GX-355R-9FHG

Vulnerability from github – Published: 2021-05-21 14:21 – Updated: 2024-10-30 23:12
VLAI
Summary
Session operations in eager mode lead to null pointer dereferences
Details

Impact

In eager mode (default in TF 2.0 and later), session operations are invalid. However, users could still call the raw ops associated with them and trigger a null pointer dereference:

import tensorflow as tf
tf.raw_ops.GetSessionTensor(handle=['\x12\x1a\x07'],dtype=4)
import tensorflow as tf
tf.raw_ops.DeleteSessionTensor(handle=['\x12\x1a\x07'])

The implementation dereferences the session state pointer without checking if it is valid:

  OP_REQUIRES_OK(ctx, ctx->session_state()->GetTensor(name, &val));

Thus, in eager mode, ctx->session_state() is nullptr and the call of the member function is undefined behavior.

Patches

We have patched the issue in GitHub commit ff70c47a396ef1e3cb73c90513da4f5cb71bebba.

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.

Show details on source website

{
  "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-29518"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-18T23:30:55Z",
    "nvd_published_at": "2021-05-14T20:15:00Z",
    "severity": "LOW"
  },
  "details": "### Impact\nIn eager mode (default in TF 2.0 and later), session operations are invalid. However, users could still call the raw ops associated with them and trigger a null pointer dereference:\n\n```python\nimport tensorflow as tf\ntf.raw_ops.GetSessionTensor(handle=[\u0027\\x12\\x1a\\x07\u0027],dtype=4)\n```\n```python\nimport tensorflow as tf\ntf.raw_ops.DeleteSessionTensor(handle=[\u0027\\x12\\x1a\\x07\u0027])\n``` \n\nThe [implementation](https://github.com/tensorflow/tensorflow/blob/eebb96c2830d48597d055d247c0e9aebaea94cd5/tensorflow/core/kernels/session_ops.cc#L104) dereferences the session state pointer without checking if it is valid:\n  \n```cc\n  OP_REQUIRES_OK(ctx, ctx-\u003esession_state()-\u003eGetTensor(name, \u0026val));\n```\n\nThus, in eager mode, `ctx-\u003esession_state()` is nullptr and the call of the member function is undefined behavior.\n\n### Patches\nWe have patched the issue in GitHub commit [ff70c47a396ef1e3cb73c90513da4f5cb71bebba](https://github.com/tensorflow/tensorflow/commit/ff70c47a396ef1e3cb73c90513da4f5cb71bebba).\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.",
  "id": "GHSA-62gx-355r-9fhg",
  "modified": "2024-10-30T23:12:44Z",
  "published": "2021-05-21T14:21:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-62gx-355r-9fhg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29518"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/commit/ff70c47a396ef1e3cb73c90513da4f5cb71bebba"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2021-446.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2021-644.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2021-155.yaml"
    }
  ],
  "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": "Session operations in eager mode lead to null pointer dereferences"
}

GHSA-62HH-2R25-QF45

Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14
VLAI
Details

The dex_parse_debug_item function in libr/bin/p/bin_dex.c in radare2 1.2.1 allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted DEX file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-6415"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-02T01:59:00Z",
    "severity": "MODERATE"
  },
  "details": "The dex_parse_debug_item function in libr/bin/p/bin_dex.c in radare2 1.2.1 allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted DEX file.",
  "id": "GHSA-62hh-2r25-qf45",
  "modified": "2022-05-13T01:14:38Z",
  "published": "2022-05-13T01:14:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6415"
    },
    {
      "type": "WEB",
      "url": "https://github.com/radare/radare2/issues/6872"
    },
    {
      "type": "WEB",
      "url": "https://github.com/radareorg/radare2/commit/68338b71a563b24e62617bb629059adc0c94b230"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/96523"
    }
  ],
  "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"
    }
  ]
}

GHSA-62JH-QWJH-CGR7

Vulnerability from github – Published: 2024-12-16 18:31 – Updated: 2024-12-16 18:31
VLAI
Details

A vulnerability was found in IObit Advanced SystemCare Utimate up to 17.0.0. It has been declared as problematic. Affected by this vulnerability is the function 0x8001E018 in the library AscRegistryFilter.sys of the component IOCTL Handler. The manipulation leads to null pointer dereference. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-12660"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-404",
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-16T18:15:10Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in IObit Advanced SystemCare Utimate up to 17.0.0. It has been declared as problematic. Affected by this vulnerability is the function 0x8001E018 in the library AscRegistryFilter.sys of the component IOCTL Handler. The manipulation leads to null pointer dereference. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-62jh-qwjh-cgr7",
  "modified": "2024-12-16T18:31:09Z",
  "published": "2024-12-16T18:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12660"
    },
    {
      "type": "WEB",
      "url": "https://shareforall.notion.site/IOBit-Advanced-SystemCare-Utimate-AscRegistryFilter-0x8001E018-NPD-DOS-15260437bb1e80c5ab28da895ed46227"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.288529"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.288529"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.456337"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/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-62Q3-HJ99-8QW6

Vulnerability from github – Published: 2022-07-20 00:00 – Updated: 2022-07-27 00:00
VLAI
Details

A null pointer dereference bug was found in wavpack-5.4.0 The results from the ASAN log: AddressSanitizer:DEADLYSIGNAL ===================================================================84257==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x561b47a970c6 bp 0x7fff13952fb0 sp 0x7fff1394fca0 T0) ==84257==The signal is caused by a WRITE memory access. ==84257==Hint: address points to the zero page. #0 0x561b47a970c5 in main cli/wvunpack.c:834 #1 0x7efc4f5c0082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) #2 0x561b47a945ed in _start (/usr/local/bin/wvunpack+0xa5ed) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV cli/wvunpack.c:834 in main ==84257==ABORTING

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-2476"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-19T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A null pointer dereference bug was found in wavpack-5.4.0 The results from the ASAN log: AddressSanitizer:DEADLYSIGNAL ===================================================================84257==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x561b47a970c6 bp 0x7fff13952fb0 sp 0x7fff1394fca0 T0) ==84257==The signal is caused by a WRITE memory access. ==84257==Hint: address points to the zero page. #0 0x561b47a970c5 in main cli/wvunpack.c:834 #1 0x7efc4f5c0082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) #2 0x561b47a945ed in _start (/usr/local/bin/wvunpack+0xa5ed) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV cli/wvunpack.c:834 in main ==84257==ABORTING",
  "id": "GHSA-62q3-hj99-8qw6",
  "modified": "2022-07-27T00:00:31Z",
  "published": "2022-07-20T00:00:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2476"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dbry/WavPack/issues/121"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CK45CC7MQ54SHEIJ63PW3HP4BCPTX6QP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QMIXZWB3OURGBAEU3T5HQY56BN2ZVLYF"
    }
  ],
  "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"
    }
  ]
}

GHSA-62R6-M6FG-P4WJ

Vulnerability from github – Published: 2023-11-14 21:31 – Updated: 2024-05-16 21:31
VLAI
Details

NULL pointer dereference in some Intel(R) Arc(TM) & Iris(R) Xe Graphics - WHQL - Windows drivers before version 31.0.101.4255 may allow an authenticated user to potentially enable denial of service via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-42879"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-395",
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-14T19:15:13Z",
    "severity": "MODERATE"
  },
  "details": "NULL pointer dereference in some Intel(R) Arc(TM) \u0026 Iris(R) Xe Graphics - WHQL - Windows drivers before version 31.0.101.4255 may allow an authenticated user to potentially enable denial of service via local access.",
  "id": "GHSA-62r6-m6fg-p4wj",
  "modified": "2024-05-16T21:31:55Z",
  "published": "2023-11-14T21:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42879"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00864.html"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01020.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-62RX-986C-7PG7

Vulnerability from github – Published: 2024-08-26 12:31 – Updated: 2025-11-04 00:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: fix NULL dereference at band check in starting tx ba session

In MLD connection, link_data/link_conf are dynamically allocated. They don't point to vif->bss_conf. So, there will be no chanreq assigned to vif->bss_conf and then the chan will be NULL. Tweak the code to check ht_supported/vht_supported/has_he/has_eht on sta deflink.

Crash log (with rtw89 version under MLO development): [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9890.526102] #PF: supervisor read access in kernel mode [ 9890.526105] #PF: error_code(0x0000) - not-present page [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1 [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 [ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core] [ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 All code ======== 0: f7 e8 imul %eax 2: d5 (bad) 3: 93 xchg %eax,%ebx 4: 3e ea ds (bad) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c: 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz

Code starting with the faulting instruction

0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 test %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873 [ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70 [ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000 [ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000 [ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Call Trace: [ 9890.526324] [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713) [ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator ---truncated---

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-43911"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-26T11:15:05Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix NULL dereference at band check in starting tx ba session\n\nIn MLD connection, link_data/link_conf are dynamically allocated. They\ndon\u0027t point to vif-\u003ebss_conf. So, there will be no chanreq assigned to\nvif-\u003ebss_conf and then the chan will be NULL. Tweak the code to check\nht_supported/vht_supported/has_he/has_eht on sta deflink.\n\nCrash log (with rtw89 version under MLO development):\n[ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 9890.526102] #PF: supervisor read access in kernel mode\n[ 9890.526105] #PF: error_code(0x0000) - not-present page\n[ 9890.526109] PGD 0 P4D 0\n[ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI\n[ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G           OE      6.9.0 #1\n[ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018\n[ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core]\n[ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211\n[ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 \u003c83\u003e 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3\nAll code\n========\n   0:\tf7 e8                \timul   %eax\n   2:\td5                   \t(bad)\n   3:\t93                   \txchg   %eax,%ebx\n   4:\t3e ea                \tds (bad)\n   6:\t48 83 c4 28          \tadd    $0x28,%rsp\n   a:\t89 d8                \tmov    %ebx,%eax\n   c:\t5b                   \tpop    %rbx\n   d:\t41 5c                \tpop    %r12\n   f:\t41 5d                \tpop    %r13\n  11:\t41 5e                \tpop    %r14\n  13:\t41 5f                \tpop    %r15\n  15:\t5d                   \tpop    %rbp\n  16:\tc3                   \tretq\n  17:\tcc                   \tint3\n  18:\tcc                   \tint3\n  19:\tcc                   \tint3\n  1a:\tcc                   \tint3\n  1b:\t49 8b 84 24 e0 f1 ff \tmov    -0xe20(%r12),%rax\n  22:\tff\n  23:\t48 8b 80 90 1b 00 00 \tmov    0x1b90(%rax),%rax\n  2a:*\t83 38 03             \tcmpl   $0x3,(%rax)\t\t\u003c-- trapping instruction\n  2d:\t0f 84 37 fe ff ff    \tje     0xfffffffffffffe6a\n  33:\tbb ea ff ff ff       \tmov    $0xffffffea,%ebx\n  38:\teb cc                \tjmp    0x6\n  3a:\t49                   \trex.WB\n  3b:\t8b                   \t.byte 0x8b\n  3c:\t84 24 10             \ttest   %ah,(%rax,%rdx,1)\n  3f:\tf3                   \trepz\n\nCode starting with the faulting instruction\n===========================================\n   0:\t83 38 03             \tcmpl   $0x3,(%rax)\n   3:\t0f 84 37 fe ff ff    \tje     0xfffffffffffffe40\n   9:\tbb ea ff ff ff       \tmov    $0xffffffea,%ebx\n   e:\teb cc                \tjmp    0xffffffffffffffdc\n  10:\t49                   \trex.WB\n  11:\t8b                   \t.byte 0x8b\n  12:\t84 24 10             \ttest   %ah,(%rax,%rdx,1)\n  15:\tf3                   \trepz\n[ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246\n[ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8\n[ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685\n[ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873\n[ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70\n[ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000\n[ 9890.526313] FS:  0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000\n[ 9890.526316] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0\n[ 9890.526321] Call Trace:\n[ 9890.526324]  \u003cTASK\u003e\n[ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479)\n[ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)\n[ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713)\n[ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator\n---truncated---",
  "id": "GHSA-62rx-986c-7pg7",
  "modified": "2025-11-04T00:31:18Z",
  "published": "2024-08-26T12:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43911"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/021d53a3d87eeb9dbba524ac515651242a2a7e3b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0acaf4a5025d6dafb7da787d2d4c47ed95e46ed6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a53c2d847627b790fb3bd8b00e02c247941b17e0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a5594c1e03b0df3908b1e1202a1ba34422eed0f6"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.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-62V4-CXJV-V35X

Vulnerability from github – Published: 2026-06-26 21:32 – Updated: 2026-07-06 21:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

crypto: eip93 - fix hmac setkey algo selection

eip93_hmac_setkey() allocates a temporary ahash transform for computing HMAC ipad/opad key material. The allocation uses the driver-specific cra_driver_name (e.g. "sha256-eip93") but passes CRYPTO_ALG_ASYNC as the mask, which excludes async algorithms.

Since the EIP93 hash algorithms are the only ones registered under those driver names and they are inherently async, the lookup is self-contradictory and always fails with -ENOENT.

When called from the AEAD setkey path, this failure leaves the SA record partially initialized with zeroed digest fields. A subsequent crypto operation then dereferences a NULL pointer in the request context, resulting in a kernel panic:

  pc : eip93_aead_handle_result+0xc8c/0x1240 [crypto_hw_eip93]
  lr : eip93_aead_handle_result+0xbec/0x1240 [crypto_hw_eip93]
  sp : ffffffc082feb820
  x29: ffffffc082feb820 x28: ffffff8011043980 x27: 0000000000000000
  x26: 0000000000000000 x25: ffffffc078da0bc8 x24: 0000000091043980
  x23: ffffff8004d59e50 x22: ffffff8004d59410 x21: ffffff8004d593c0
  x20: ffffff8004d593c0 x19: ffffff8004d4f300 x18: 0000000000000000
  x17: 0000000000000000 x16: 0000000000000000 x15: 0000007fda7aa498
  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
  x11: 0000000000000000 x10: fffffffff8127a80 x9 : 0000000000000000
  x8 : ffffff8004d4f380 x7 : 0000000000000000 x6 : 000000000000003f
  x5 : 0000000000000040 x4 : 0000000000000008 x3 : 0000000000000009
  x2 : 0000000000000008 x1 : 0000000028000003 x0 : ffffff8004d388c0
  Code: 910142b6 f94012e0 f9002aa0 f90006d3 (f9400740)

The reported symbol eip93_aead_handle_result+0xc8c is a resolution artifact from static functions being merged under the nearest exported symbol. Decoding the faulting sequence:

  910142b6  ADD  X22, X21, #0x50
  f94012e0  LDR  X0, [X23, #0x20]
  f9002aa0  STR  X0, [X21, #0x50]
  f90006d3  STR  X19, [X22, #0x8]
  f9400740  LDR  X0, [X26, #0x8]

The faulting LDR at [X26, #0x8] is loading ctx->flags (offset 8 in eip93_hash_ctx), where ctx has been resolved to NULL from a partially initialized or unreachable transform context following the failed setkey.

Fix this by dropping the CRYPTO_ALG_ASYNC mask from the crypto_alloc_ahash() call. The code already handles async completion correctly via crypto_wait_req(), so there is no requirement to restrict the lookup to synchronous algorithms.

Note that hashing a single 64-byte block through the hardware is likely slower than doing it in software due to the DMA round-trip overhead, but offloading it may still spare CPU cycles on the slower embedded cores where this IP is found.

[Detailed investigation report of this bug]

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-53302"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-26T20:17:23Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: eip93 - fix hmac setkey algo selection\n\neip93_hmac_setkey() allocates a temporary ahash transform for\ncomputing HMAC ipad/opad key material. The allocation uses the\ndriver-specific cra_driver_name (e.g. \"sha256-eip93\") but passes\nCRYPTO_ALG_ASYNC as the mask, which excludes async algorithms.\n\nSince the EIP93 hash algorithms are the only ones registered\nunder those driver names and they are inherently async, the\nlookup is self-contradictory and always fails with -ENOENT.\n\nWhen called from the AEAD setkey path, this failure leaves the\nSA record partially initialized with zeroed digest fields. A\nsubsequent crypto operation then dereferences a NULL pointer in\nthe request context, resulting in a kernel panic:\n\n```\n  pc : eip93_aead_handle_result+0xc8c/0x1240 [crypto_hw_eip93]\n  lr : eip93_aead_handle_result+0xbec/0x1240 [crypto_hw_eip93]\n  sp : ffffffc082feb820\n  x29: ffffffc082feb820 x28: ffffff8011043980 x27: 0000000000000000\n  x26: 0000000000000000 x25: ffffffc078da0bc8 x24: 0000000091043980\n  x23: ffffff8004d59e50 x22: ffffff8004d59410 x21: ffffff8004d593c0\n  x20: ffffff8004d593c0 x19: ffffff8004d4f300 x18: 0000000000000000\n  x17: 0000000000000000 x16: 0000000000000000 x15: 0000007fda7aa498\n  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n  x11: 0000000000000000 x10: fffffffff8127a80 x9 : 0000000000000000\n  x8 : ffffff8004d4f380 x7 : 0000000000000000 x6 : 000000000000003f\n  x5 : 0000000000000040 x4 : 0000000000000008 x3 : 0000000000000009\n  x2 : 0000000000000008 x1 : 0000000028000003 x0 : ffffff8004d388c0\n  Code: 910142b6 f94012e0 f9002aa0 f90006d3 (f9400740)\n```\n\nThe reported symbol eip93_aead_handle_result+0xc8c is a\nresolution artifact from static functions being merged under\nthe nearest exported symbol. Decoding the faulting sequence:\n\n```\n  910142b6  ADD  X22, X21, #0x50\n  f94012e0  LDR  X0, [X23, #0x20]\n  f9002aa0  STR  X0, [X21, #0x50]\n  f90006d3  STR  X19, [X22, #0x8]\n  f9400740  LDR  X0, [X26, #0x8]\n```\n\nThe faulting LDR at [X26, #0x8] is loading ctx-\u003eflags\n(offset 8 in eip93_hash_ctx), where ctx has been resolved\nto NULL from a partially initialized or unreachable\ntransform context following the failed setkey.\n\nFix this by dropping the CRYPTO_ALG_ASYNC mask from the\ncrypto_alloc_ahash() call. The code already handles async\ncompletion correctly via crypto_wait_req(), so there is no\nrequirement to restrict the lookup to synchronous algorithms.\n\nNote that hashing a single 64-byte block through the hardware\nis likely slower than doing it in software due to the DMA\nround-trip overhead, but offloading it may still spare CPU\ncycles on the slower embedded cores where this IP is found.\n\n[Detailed investigation report of this bug]",
  "id": "GHSA-62v4-cxjv-v35x",
  "modified": "2026-07-06T21:30:25Z",
  "published": "2026-06-26T21:32:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53302"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3ba3b02f897b14e34977e1886d95ffe64d907204"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ec226d3e58bb9f0e26a77346085b6b4d594d53d8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fc9310d79fdb117b369a01eb00f4fd5fb4849d4e"
    }
  ],
  "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"
    }
  ]
}

Mitigation MIT-56
Implementation

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
Requirements

Select a programming language that is not susceptible to these issues.

Mitigation
Implementation

Check the results of all functions that return a value and verify that the value is non-null before acting upon it.

Mitigation
Architecture and Design

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
Implementation

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.