GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
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.

6663 vulnerabilities reference this CWE, most recent first.

GHSA-XWHH-QFF2-J7FX

Vulnerability from github – Published: 2026-01-02 15:30 – Updated: 2026-01-05 21:30
VLAI
Details

A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.

We have already fixed the vulnerability in the following versions: QTS 5.2.7.3256 build 20250913 and later QuTS hero h5.2.7.3256 build 20250913 and later QuTS hero h5.3.1.3250 build 20250912 and later

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-53596"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-02T15:16:02Z",
    "severity": "LOW"
  },
  "details": "A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.\n\nWe have already fixed the vulnerability in the following versions:\nQTS 5.2.7.3256 build 20250913 and later\nQuTS hero h5.2.7.3256 build 20250913 and later\nQuTS hero h5.3.1.3250 build 20250912 and later",
  "id": "GHSA-xwhh-qff2-j7fx",
  "modified": "2026-01-05T21:30:31Z",
  "published": "2026-01-02T15:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53596"
    },
    {
      "type": "WEB",
      "url": "https://www.qnap.com/en/security-advisory/qsa-25-50"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U/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-XWHW-JWH4-HH9V

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

In Poppler 0.59.0, a NULL Pointer Dereference exists in the XRef::parseEntry() function in XRef.cc via a crafted PDF document.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-14517"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-17T23:29:00Z",
    "severity": "MODERATE"
  },
  "details": "In Poppler 0.59.0, a NULL Pointer Dereference exists in the XRef::parseEntry() function in XRef.cc via a crafted PDF document.",
  "id": "GHSA-xwhw-jwh4-hh9v",
  "modified": "2022-05-14T01:39:48Z",
  "published": "2022-05-14T01:39:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14517"
    },
    {
      "type": "WEB",
      "url": "https://bugs.freedesktop.org/show_bug.cgi?id=102687"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2018/dsa-4079"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105050"
    }
  ],
  "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-XWM4-236H-GR55

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

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

net/mlx5: Fix command bitmask initialization

Command bitmask have a dedicated bit for MANAGE_PAGES command, this bit isn't Initialize during command bitmask Initialization, only during MANAGE_PAGES.

In addition, mlx5_cmd_trigger_completions() is trying to trigger completion for MANAGE_PAGES command as well.

Hence, in case health error occurred before any MANAGE_PAGES command have been invoke (for example, during mlx5_enable_hca()), mlx5_cmd_trigger_completions() will try to trigger completion for MANAGE_PAGES command, which will result in null-ptr-deref error.[1]

Fix it by Initialize command bitmask correctly.

While at it, re-write the code for better understanding.

[1] BUG: KASAN: null-ptr-deref in mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core] Write of size 4 at addr 0000000000000214 by task kworker/u96:2/12078 CPU: 10 PID: 12078 Comm: kworker/u96:2 Not tainted 6.9.0-rc2_for_upstream_debug_2024_04_07_19_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_health0000:08:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: dump_stack_lvl+0x7e/0xc0 kasan_report+0xb9/0xf0 kasan_check_range+0xec/0x190 mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core] mlx5_cmd_flush+0x94/0x240 [mlx5_core] enter_error_state+0x6c/0xd0 [mlx5_core] mlx5_fw_fatal_reporter_err_work+0xf3/0x480 [mlx5_core] process_one_work+0x787/0x1490 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? pwq_dec_nr_in_flight+0xda0/0xda0 ? assign_work+0x168/0x240 worker_thread+0x586/0xd30 ? rescuer_thread+0xae0/0xae0 kthread+0x2df/0x3b0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x2d/0x70 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-50147"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-07T10:15:06Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix command bitmask initialization\n\nCommand bitmask have a dedicated bit for MANAGE_PAGES command, this bit\nisn\u0027t Initialize during command bitmask Initialization, only during\nMANAGE_PAGES.\n\nIn addition, mlx5_cmd_trigger_completions() is trying to trigger\ncompletion for MANAGE_PAGES command as well.\n\nHence, in case health error occurred before any MANAGE_PAGES command\nhave been invoke (for example, during mlx5_enable_hca()),\nmlx5_cmd_trigger_completions() will try to trigger completion for\nMANAGE_PAGES command, which will result in null-ptr-deref error.[1]\n\nFix it by Initialize command bitmask correctly.\n\nWhile at it, re-write the code for better understanding.\n\n[1]\nBUG: KASAN: null-ptr-deref in mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core]\nWrite of size 4 at addr 0000000000000214 by task kworker/u96:2/12078\nCPU: 10 PID: 12078 Comm: kworker/u96:2 Not tainted 6.9.0-rc2_for_upstream_debug_2024_04_07_19_01 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nWorkqueue: mlx5_health0000:08:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x7e/0xc0\n kasan_report+0xb9/0xf0\n kasan_check_range+0xec/0x190\n mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core]\n mlx5_cmd_flush+0x94/0x240 [mlx5_core]\n enter_error_state+0x6c/0xd0 [mlx5_core]\n mlx5_fw_fatal_reporter_err_work+0xf3/0x480 [mlx5_core]\n process_one_work+0x787/0x1490\n ? lockdep_hardirqs_on_prepare+0x400/0x400\n ? pwq_dec_nr_in_flight+0xda0/0xda0\n ? assign_work+0x168/0x240\n worker_thread+0x586/0xd30\n ? rescuer_thread+0xae0/0xae0\n kthread+0x2df/0x3b0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x2d/0x70\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork_asm+0x11/0x20\n \u003c/TASK\u003e",
  "id": "GHSA-xwm4-236h-gr55",
  "modified": "2025-11-04T00:31:56Z",
  "published": "2024-11-07T12:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50147"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2feac1e562be0efc621a6722644a90f355d53473"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d1606090bb294cecb7de3c4ed177f5aa0abd4c4e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d62b14045c6511a7b2d4948d1a83a4e592deeb05"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d88564c79d1cedaf2655f12261eca0d2796bde4e"
    },
    {
      "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-XWVH-5VG2-56CJ

Vulnerability from github – Published: 2022-07-18 00:00 – Updated: 2022-07-26 00:00
VLAI
Details

An issue was discovered in dbus-broker before 31. Multiple NULL pointer dereferences can be found when supplying a malformed XML config file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-31213"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-17T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in dbus-broker before 31. Multiple NULL pointer dereferences can be found when supplying a malformed XML config file.",
  "id": "GHSA-xwvh-5vg2-56cj",
  "modified": "2022-07-26T00:00:28Z",
  "published": "2022-07-18T00:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31213"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bus1/dbus-broker/compare/v30...v31"
    },
    {
      "type": "WEB",
      "url": "https://sec-consult.com/vulnerability-lab/advisory/memory-corruption-vulnerabilities-dbus-broker"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202305-04"
    }
  ],
  "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-XWWX-GG4V-8GP7

Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-20 18:31
VLAI
Details

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

scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param()

The validity of sock should be checked before assignment to avoid incorrect values. Commit 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()") introduced this change which may lead to inconsistent values of tcp_sw_conn->sendpage and conn->datadgst_en.

Fix the issue by moving the position of the assignment.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-53464"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-01T12:15:48Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: iscsi_tcp: Check that sock is valid before iscsi_set_param()\n\nThe validity of sock should be checked before assignment to avoid incorrect\nvalues. Commit 57569c37f0ad (\"scsi: iscsi: iscsi_tcp: Fix null-ptr-deref\nwhile calling getpeername()\") introduced this change which may lead to\ninconsistent values of tcp_sw_conn-\u003esendpage and conn-\u003edatadgst_en.\n\nFix the issue by moving the position of the assignment.",
  "id": "GHSA-xwwx-gg4v-8gp7",
  "modified": "2026-01-20T18:31:51Z",
  "published": "2025-10-01T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53464"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/48b19b79cfa37b1e50da3b5a8af529f994c08901"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/499757ad3332e2527254f9ab68dec1da087b1d96"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5e5c5f472972c4bc9430adc08b36763a0fa5b9f7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6e06a68fbbfcd8576eee8f7139fa2b13c9b72e91"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b287e21e73ec23f3788fbe40037c42dbe6e9a9a9"
    }
  ],
  "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-XX22-P4CH-683R

Vulnerability from github – Published: 2026-07-24 16:13 – Updated: 2026-07-24 16:13
VLAI
Summary
LZ4 Java: Native XXHash implementations can crash the JVM when passed invalid byte array ranges
Details

Summary

Insufficient validation of byte array arguments in JNI-based XXHash implementations in lz4-java 1.11.0 and earlier allows callers to crash the JVM by passing an invalid array reference or invalid range to native XXHash methods.

This affects applications where an attacker can influence the byte array object or the off / len arguments passed to affected XXHash APIs. It does not affect the common case where only the contents of a valid byte array are attacker-controlled.

Java-based XXHash implementations are not affected.

Details

The JNI-backed XXHash implementations pass caller-provided byte array arguments to native code. The affected APIs are:

  • XXHashFactory.nativeInstance().hash32().hash(byte[] buf, int off, int len, int seed)
  • XXHashFactory.nativeInstance().hash64().hash(byte[] buf, int off, int len, long seed)
  • XXHashFactory.nativeInstance().newStreamingHash32(seed).update(byte[] bytes, int off, int len)
  • XXHashFactory.nativeInstance().newStreamingHash64(seed).update(byte[] bytes, int off, int len)

Before the fix, the streaming JNI implementations did not validate bytes, off, or len before calling XXHashJNI.XXH32_update / XXHashJNI.XXH64_update. The non-streaming JNI implementations called SafeUtils.checkRange, but SafeUtils.checkRange(byte[], int, int) skipped all array access when len == 0, so a null byte array with a zero length could still reach JNI.

As a result:

  • hash(null, 0, 0, seed) and update(null, 0, 0) could pass a null array reference to JNI, causing a fatal JVM crash in GetPrimitiveArrayCritical.
  • update(new byte[16], 0, Integer.MAX_VALUE) could cause native XXHash code to read far beyond the end of the Java array, causing a fatal JVM crash and potentially exposing in-process memory to the native routine before the crash.

The oversized-length non-streaming hash(new byte[16], 0, Integer.MAX_VALUE, seed) case was already rejected in Java before this fix. The missing validation affected the streaming oversized-length case and the zero-length null-array case for both streaming and non-streaming JNI XXHash APIs.

The impact of this vulnerability depends on how user code uses the XXHash API. Code that hashes attacker-controlled byte contents in a valid, correctly bounded array is not affected. Code may be affected if an attacker can cause the application to pass a null array, an attacker-controlled offset, or an attacker-controlled length to the native XXHash API. The primary impact is denial of service due to JVM termination. For oversized lengths, native code may also read outside the Java array before the process crashes.

Mitigation

lz4-java 1.11.1 fixes this issue without requiring changes in user code.

If you cannot upgrade, avoid passing attacker-controlled array references, offsets, or lengths to JNI-backed XXHash APIs. In particular, validate that arrays are non-null and that off and len describe a range fully contained in the array before calling native XXHash methods.

Using XXHashFactory.safeInstance() avoids the JNI boundary and is not affected by this native crash behavior.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.11.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "at.yawk.lz4:lz4-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.lz4:lz4-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59949"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T16:13:41Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nInsufficient validation of byte array arguments in JNI-based XXHash implementations in lz4-java 1.11.0 and earlier allows callers to crash the JVM by passing an invalid array reference or invalid range to native XXHash methods.\n\nThis affects applications where an attacker can influence the byte array object or the `off` / `len` arguments passed to affected XXHash APIs. It does **not** affect the common case where only the contents of a valid byte array are attacker-controlled.\n\nJava-based XXHash implementations are *not* affected.\n\n### Details\n\nThe JNI-backed XXHash implementations pass caller-provided byte array arguments to native code. The affected APIs are:\n\n- `XXHashFactory.nativeInstance().hash32().hash(byte[] buf, int off, int len, int seed)`\n- `XXHashFactory.nativeInstance().hash64().hash(byte[] buf, int off, int len, long seed)`\n- `XXHashFactory.nativeInstance().newStreamingHash32(seed).update(byte[] bytes, int off, int len)`\n- `XXHashFactory.nativeInstance().newStreamingHash64(seed).update(byte[] bytes, int off, int len)`\n\nBefore the fix, the streaming JNI implementations did not validate `bytes`, `off`, or `len` before calling `XXHashJNI.XXH32_update` / `XXHashJNI.XXH64_update`. The non-streaming JNI implementations called `SafeUtils.checkRange`, but `SafeUtils.checkRange(byte[], int, int)` skipped all array access when `len == 0`, so a null byte array with a zero length could still reach JNI.\n\nAs a result:\n\n- `hash(null, 0, 0, seed)` and `update(null, 0, 0)` could pass a null array reference to JNI, causing a fatal JVM crash in `GetPrimitiveArrayCritical`.\n- `update(new byte[16], 0, Integer.MAX_VALUE)` could cause native XXHash code to read far beyond the end of the Java array, causing a fatal JVM crash and potentially exposing in-process memory to the native routine before the crash.\n\nThe oversized-length non-streaming `hash(new byte[16], 0, Integer.MAX_VALUE, seed)` case was already rejected in Java before this fix. The missing validation affected the streaming oversized-length case and the zero-length null-array case for both streaming and non-streaming JNI XXHash APIs.\n\nThe impact of this vulnerability depends on how user code uses the XXHash API. Code that hashes attacker-controlled byte contents in a valid, correctly bounded array is not affected. Code may be affected if an attacker can cause the application to pass a null array, an attacker-controlled offset, or an attacker-controlled length to the native XXHash API. The primary impact is denial of service due to JVM termination. For oversized lengths, native code may also read outside the Java array before the process crashes.\n\n### Mitigation\n\nlz4-java 1.11.1 fixes this issue without requiring changes in user code.\n\nIf you cannot upgrade, avoid passing attacker-controlled array references, offsets, or lengths to JNI-backed XXHash APIs. In particular, validate that arrays are non-null and that `off` and `len` describe a range fully contained in the array before calling native XXHash methods.\n\nUsing `XXHashFactory.safeInstance()` avoids the JNI boundary and is not affected by this native crash behavior.",
  "id": "GHSA-xx22-p4ch-683r",
  "modified": "2026-07-24T16:13:41Z",
  "published": "2026-07-24T16:13:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/yawkat/lz4-java/security/advisories/GHSA-xx22-p4ch-683r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yawkat/lz4-java/commit/dbd86d04b8dd716e1c2bc626be54189997d910da"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/yawkat/lz4-java"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yawkat/lz4-java/releases/tag/v1.11.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LZ4 Java: Native XXHash implementations can crash the JVM when passed invalid byte array ranges"
}

GHSA-XX3Q-MVC5-C52F

Vulnerability from github – Published: 2022-05-17 02:24 – Updated: 2022-05-17 02:24
VLAI
Details

There is a NULL pointer dereference in the caseless_hash function in gxps-archive.c in libgxps 0.2.5. A crafted input will lead to a remote denial of service attack.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-11590"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-24T01:29:00Z",
    "severity": "HIGH"
  },
  "details": "There is a NULL pointer dereference in the caseless_hash function in gxps-archive.c in libgxps 0.2.5. A crafted input will lead to a remote denial of service attack.",
  "id": "GHSA-xx3q-mvc5-c52f",
  "modified": "2022-05-17T02:24:08Z",
  "published": "2022-05-17T02:24:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11590"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1473167"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XX4X-7C38-RPQ3

Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-21 18:33
VLAI
Details

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

ASoC: amd: acp-mach-common: Add missing error check for clock acquisition

The acp_card_rt5682_init() and acp_card_rt5682s_init() functions did not check the return values of clk_get(). This could lead to a kernel crash when the invalid pointers are later dereferenced by clock core functions.

Fix this by: 1. Changing clk_get() to the device-managed devm_clk_get(). 2. Adding IS_ERR() checks immediately after each clock acquisition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-43443"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-08T15:16:56Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: amd: acp-mach-common: Add missing error check for clock acquisition\n\nThe acp_card_rt5682_init() and acp_card_rt5682s_init() functions did not\ncheck the return values of clk_get(). This could lead to a kernel crash\nwhen the invalid pointers are later dereferenced by clock core\nfunctions.\n\nFix this by:\n1. Changing clk_get() to the device-managed devm_clk_get().\n2. Adding IS_ERR() checks immediately after each clock acquisition.",
  "id": "GHSA-xx4x-7c38-rpq3",
  "modified": "2026-05-21T18:33:06Z",
  "published": "2026-05-08T15:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43443"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0cee68fb7f4cf1562e067c5a82d25062a973b0d0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/30c64fb9839949f085c8eb55b979cbd8a4c51f00"
    }
  ],
  "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-XX6W-WXQJ-HCRW

Vulnerability from github – Published: 2022-05-13 01:17 – Updated: 2025-04-20 03:45
VLAI
Details

DrawGetStrokeDashArray in wand/drawing-wand.c in ImageMagick 7.0.7-1 mishandles certain NULL arrays, which allows attackers to perform Denial of Service (NULL pointer dereference and application crash in AcquireQuantumMemory within MagickCore/memory.c) by providing a crafted Image File as input.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-14505"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-17T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "DrawGetStrokeDashArray in wand/drawing-wand.c in ImageMagick 7.0.7-1 mishandles certain NULL arrays, which allows attackers to perform Denial of Service (NULL pointer dereference and application crash in AcquireQuantumMemory within MagickCore/memory.c) by providing a crafted Image File as input.",
  "id": "GHSA-xx6w-wxqj-hcrw",
  "modified": "2025-04-20T03:45:24Z",
  "published": "2022-05-13T01:17:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14505"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ImageMagick/ImageMagick/issues/716"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/05/msg00015.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/09/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3681-1"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/100882"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XX7J-2FQW-VV47

Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2025-09-22 21:30
VLAI
Details

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

bpf: Fix a btf decl_tag bug when tagging a function

syzbot reported a btf decl_tag bug with stack trace below:

general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 3592 Comm: syz-executor914 Not tainted 5.16.0-syzkaller-11424-gb7892f7d5cb2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:btf_type_vlen include/linux/btf.h:231 [inline] RIP: 0010:btf_decl_tag_resolve+0x83e/0xaa0 kernel/bpf/btf.c:3910 ... Call Trace: btf_resolve+0x251/0x1020 kernel/bpf/btf.c:4198 btf_check_all_types kernel/bpf/btf.c:4239 [inline] btf_parse_type_sec kernel/bpf/btf.c:4280 [inline] btf_parse kernel/bpf/btf.c:4513 [inline] btf_new_fd+0x19fe/0x2370 kernel/bpf/btf.c:6047 bpf_btf_load kernel/bpf/syscall.c:4039 [inline] __sys_bpf+0x1cbb/0x5970 kernel/bpf/syscall.c:4679 __do_sys_bpf kernel/bpf/syscall.c:4738 [inline] __se_sys_bpf kernel/bpf/syscall.c:4736 [inline] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4736 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae

The kasan error is triggered with an illegal BTF like below: type 0: void type 1: int type 2: decl_tag to func type 3 type 3: func to func_proto type 8 The total number of types is 4 and the type 3 is illegal since its func_proto type is out of range.

Currently, the target type of decl_tag can be struct/union, var or func. Both struct/union and var implemented their own 'resolve' callback functions and hence handled properly in kernel. But func type doesn't have 'resolve' callback function. When btf_decl_tag_resolve() tries to check func type, it tries to get vlen of its func_proto type, which triggered the above kasan error.

To fix the issue, btf_decl_tag_resolve() needs to do btf_func_check() before trying to accessing func_proto type. In the current implementation, func type is checked with btf_func_check() in the main checking function btf_check_all_types(). To fix the above kasan issue, let us implement 'resolve' callback func type properly. The 'resolve' callback will be also called in btf_check_all_types() for func types.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49228"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:00:59Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a btf decl_tag bug when tagging a function\n\nsyzbot reported a btf decl_tag bug with stack trace below:\n\n  general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN\n  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n  CPU: 0 PID: 3592 Comm: syz-executor914 Not tainted 5.16.0-syzkaller-11424-gb7892f7d5cb2 #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n  RIP: 0010:btf_type_vlen include/linux/btf.h:231 [inline]\n  RIP: 0010:btf_decl_tag_resolve+0x83e/0xaa0 kernel/bpf/btf.c:3910\n  ...\n  Call Trace:\n   \u003cTASK\u003e\n   btf_resolve+0x251/0x1020 kernel/bpf/btf.c:4198\n   btf_check_all_types kernel/bpf/btf.c:4239 [inline]\n   btf_parse_type_sec kernel/bpf/btf.c:4280 [inline]\n   btf_parse kernel/bpf/btf.c:4513 [inline]\n   btf_new_fd+0x19fe/0x2370 kernel/bpf/btf.c:6047\n   bpf_btf_load kernel/bpf/syscall.c:4039 [inline]\n   __sys_bpf+0x1cbb/0x5970 kernel/bpf/syscall.c:4679\n   __do_sys_bpf kernel/bpf/syscall.c:4738 [inline]\n   __se_sys_bpf kernel/bpf/syscall.c:4736 [inline]\n   __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4736\n   do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n   do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe kasan error is triggered with an illegal BTF like below:\n   type 0: void\n   type 1: int\n   type 2: decl_tag to func type 3\n   type 3: func to func_proto type 8\nThe total number of types is 4 and the type 3 is illegal\nsince its func_proto type is out of range.\n\nCurrently, the target type of decl_tag can be struct/union, var or func.\nBoth struct/union and var implemented their own \u0027resolve\u0027 callback functions\nand hence handled properly in kernel.\nBut func type doesn\u0027t have \u0027resolve\u0027 callback function. When\nbtf_decl_tag_resolve() tries to check func type, it tries to get\nvlen of its func_proto type, which triggered the above kasan error.\n\nTo fix the issue, btf_decl_tag_resolve() needs to do btf_func_check()\nbefore trying to accessing func_proto type.\nIn the current implementation, func type is checked with\nbtf_func_check() in the main checking function btf_check_all_types().\nTo fix the above kasan issue, let us implement \u0027resolve\u0027 callback\nfunc type properly. The \u0027resolve\u0027 callback will be also called\nin btf_check_all_types() for func types.",
  "id": "GHSA-xx7j-2fqw-vv47",
  "modified": "2025-09-22T21:30:15Z",
  "published": "2025-09-22T21:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49228"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/796d5666f6422ddadc938fb888044fcc16f2dbe3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a3bcd2110c087bc62e90fddd4a93237b049d6e68"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d7e7b42f4f956f2c68ad8cda87d750093dbba737"
    }
  ],
  "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.