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.

6310 vulnerabilities reference this CWE, most recent first.

GHSA-52J9-MGVJ-V9GH

Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2024-09-09 18:30
VLAI
Details

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

drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2

[Why] Commit: - commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload allocation/removement") accidently overwrite the commit - commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2") which cause regression.

[How] Recover the original NULL fix and remove the unnecessary input parameter 'state' for drm_dp_add_payload_part2().

(cherry picked from commit 4545614c1d8da603e57b60dd66224d81b6ffc305)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-39498"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-12T13:15:12Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2\n\n[Why]\nCommit:\n- commit 5aa1dfcdf0a4 (\"drm/mst: Refactor the flow for payload allocation/removement\")\naccidently overwrite the commit\n- commit 54d217406afe (\"drm: use mgr-\u003edev in drm_dbg_kms in drm_dp_add_payload_part2\")\nwhich cause regression.\n\n[How]\nRecover the original NULL fix and remove the unnecessary input parameter \u0027state\u0027 for\ndrm_dp_add_payload_part2().\n\n(cherry picked from commit 4545614c1d8da603e57b60dd66224d81b6ffc305)",
  "id": "GHSA-52j9-mgvj-v9gh",
  "modified": "2024-09-09T18:30:29Z",
  "published": "2024-07-12T15:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39498"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5a507b7d2be15fddb95bf8dee01110b723e2bcd9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8e21de5f99b2368a5155037ce0aae8aaba3f5241"
    }
  ],
  "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-52JH-2XXH-PWH6

Vulnerability from github – Published: 2026-03-24 21:29 – Updated: 2026-03-27 22:09
VLAI
Summary
NATS Server panic via malicious compression on leafnode port
Details

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

When configured to accept leafnode connections (for a hub/spoke topology of multiple nats-servers), then the default configuration allows for negotiating compression; a malicious remote NATS server can trigger a server panic via that compression.

Problem Description

If the nats-server has the "leafnode" configuration enabled (not default), then anyone who can connect can crash the nats-server by triggering a panic. This happens pre-authentication and requires that compression be enabled (which it is, by default, when leafnodes are used).

Context: a NATS server can form various clustering topologies, including local clusters, and superclusters of clusters, but leafnodes allow for separate administrative domains to link together with limited data communication; eg, a server in a moving vehicle might use a local leafnode for agents to connect to, and sync up to a central service as and when available. The leafnode configuration here is where the central server allows other NATS servers to connect into it, almost like regular NATS clients. Documentation examples typically use port 7422 for leafnode communications.

Affected Versions

Version 2, prior to v2.11.14 or v2.12.5

Workarounds

Disable compression on the leafnode port:

leafnodes {
  port: 7422
  compression: off
}
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.0-RC.1"
            },
            {
              "fixed": "2.12.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-29785"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-24T21:29:06Z",
    "nvd_published_at": "2026-03-25T20:16:30Z",
    "severity": "HIGH"
  },
  "details": "### Background\n\nNATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.\n\nWhen configured to accept leafnode connections (for a hub/spoke topology of multiple nats-servers), then the default configuration allows for negotiating compression; a malicious remote NATS server can trigger a server panic via that compression.\n\n### Problem Description\n\nIf the nats-server has the \"leafnode\" configuration enabled (not default), then anyone who can connect can crash the nats-server by triggering a panic. This happens pre-authentication and requires that compression be enabled (which it is, by default, when leafnodes are used).\n\nContext: a NATS server can form various clustering topologies, including local clusters, and superclusters of clusters, but leafnodes allow for separate administrative domains to link together with limited data communication; eg, a server in a moving vehicle might use a local leafnode for agents to connect to, and sync up to a central service as and when available. The leafnode configuration here is where the central server allows other NATS servers to connect into it, almost like regular NATS clients. Documentation examples typically use port 7422 for leafnode communications.\n\n### Affected Versions\n\nVersion 2, prior to v2.11.14 or v2.12.5\n\n### Workarounds\n\nDisable compression on the leafnode port:\n\n```\nleafnodes {\n  port: 7422\n  compression: off\n}\n```",
  "id": "GHSA-52jh-2xxh-pwh6",
  "modified": "2026-03-27T22:09:21Z",
  "published": "2026-03-24T21:29:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats-server/security/advisories/GHSA-52jh-2xxh-pwh6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29785"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats-server/commit/a1488de6f2ba6e666aef0f9cce0016f7f167d6a8"
    },
    {
      "type": "WEB",
      "url": "https://advisories.nats.io/CVE/secnote-2026-04.txt"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nats-io/nats-server"
    }
  ],
  "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"
    }
  ],
  "summary": "NATS Server panic via malicious compression on leafnode port"
}

GHSA-52MX-XJ4W-GW54

Vulnerability from github – Published: 2024-10-21 12:30 – Updated: 2024-10-24 00:33
VLAI
Details

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

IB/mlx5: Fix UMR pd cleanup on error flow of driver init

The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2].

Fix it by checking pd pointer to avoid panic if it is NULL;

[1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-47694"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T12:15:06Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix UMR pd cleanup on error flow of driver init\n\nThe cited commit moves the pd allocation from function\nmlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup().\nSo the fix in commit [1] is broken. In error flow, will hit panic [2].\n\nFix it by checking pd pointer to avoid panic if it is NULL;\n\n[1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init\n[2]\n [  347.567063] infiniband mlx5_0: Couldn\u0027t register device with driver model\n [  347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020\n [  347.593438] #PF: supervisor read access in kernel mode\n [  347.595176] #PF: error_code(0x0000) - not-present page\n [  347.596962] PGD 0 P4D 0\n [  347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core]\n [  347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282\n [  347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000\n [  347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000\n [  347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0\n [  347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000\n [  347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001\n [  347.609067] FS:  00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000\n [  347.610094] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [  347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0\n [  347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n [  347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n [  347.612804] Call Trace:\n [  347.613130]  \u003cTASK\u003e\n [  347.613417]  ? __die+0x20/0x60\n [  347.613793]  ? page_fault_oops+0x150/0x3e0\n [  347.614243]  ? free_msg+0x68/0x80 [mlx5_core]\n [  347.614840]  ? cmd_exec+0x48f/0x11d0 [mlx5_core]\n [  347.615359]  ? exc_page_fault+0x74/0x130\n [  347.615808]  ? asm_exc_page_fault+0x22/0x30\n [  347.616273]  ? ib_dealloc_pd_user+0x12/0xc0 [ib_core]\n [  347.616801]  mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib]\n [  347.617365]  mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib]\n [  347.618025]  __mlx5_ib_add+0x96/0xd0 [mlx5_ib]\n [  347.618539]  mlx5r_probe+0xe9/0x310 [mlx5_ib]\n [  347.619032]  ? kernfs_add_one+0x107/0x150\n [  347.619478]  ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib]\n [  347.619984]  auxiliary_bus_probe+0x3e/0x90\n [  347.620448]  really_probe+0xc5/0x3a0\n [  347.620857]  __driver_probe_device+0x80/0x160\n [  347.621325]  driver_probe_device+0x1e/0x90\n [  347.621770]  __driver_attach+0xec/0x1c0\n [  347.622213]  ? __device_attach_driver+0x100/0x100\n [  347.622724]  bus_for_each_dev+0x71/0xc0\n [  347.623151]  bus_add_driver+0xed/0x240\n [  347.623570]  driver_register+0x58/0x100\n [  347.623998]  __auxiliary_driver_register+0x6a/0xc0\n [  347.624499]  ? driver_register+0xae/0x100\n [  347.624940]  ? 0xffffffffa0893000\n [  347.625329]  mlx5_ib_init+0x16a/0x1e0 [mlx5_ib]\n [  347.625845]  do_one_initcall+0x4a/0x2a0\n [  347.626273]  ? gcov_event+0x2e2/0x3a0\n [  347.626706]  do_init_module+0x8a/0x260\n [  347.627126]  init_module_from_file+0x8b/0xd0\n [  347.627596]  __x64_sys_finit_module+0x1ca/0x2f0\n [  347.628089]  do_syscall_64+0x4c/0x100",
  "id": "GHSA-52mx-xj4w-gw54",
  "modified": "2024-10-24T00:33:35Z",
  "published": "2024-10-21T12:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47694"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/112e6e83a894260cc7efe79a1fc47d4d51461742"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/99e2de5942b0390ddc24efada71edc6593e23f05"
    }
  ],
  "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-52VJ-CJHG-WPWV

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

The (1) asn1_read_value_type and (2) asn1_read_value functions in GNU Libtasn1 before 3.6 allows context-dependent attackers to cause a denial of service (NULL pointer dereference and crash) via a NULL value in an ivalue argument.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2014-3469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-06-05T20:55:00Z",
    "severity": "MODERATE"
  },
  "details": "The (1) asn1_read_value_type and (2) asn1_read_value functions in GNU Libtasn1 before 3.6 allows context-dependent attackers to cause a denial of service (NULL pointer dereference and crash) via a NULL value in an ivalue argument.",
  "id": "GHSA-52vj-cjhg-wpwv",
  "modified": "2022-05-13T01:13:34Z",
  "published": "2022-05-13T01:13:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-3469"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1102329"
    },
    {
      "type": "WEB",
      "url": "http://advisories.mageia.org/MGASA-2014-0247.html"
    },
    {
      "type": "WEB",
      "url": "http://linux.oracle.com/errata/ELSA-2014-0594.html"
    },
    {
      "type": "WEB",
      "url": "http://linux.oracle.com/errata/ELSA-2014-0596.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.gnu.org/archive/html/help-libtasn1/2014-05/msg00006.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2014-06/msg00002.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2014-06/msg00015.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2014-0594.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2014-0596.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2014-0687.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2014-0815.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/58591"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/58614"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/59021"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/59057"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/59408"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/60320"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/60415"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/61888"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2014/dsa-3056"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2015:116"
    },
    {
      "type": "WEB",
      "url": "http://www.novell.com/support/kb/doc.php?id=7015302"
    },
    {
      "type": "WEB",
      "url": "http://www.novell.com/support/kb/doc.php?id=7015303"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-52X5-63XF-5W3P

Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-05-24 19:20
VLAI
Details

A NULL pointer dereference in the function TextPage::restoreState of pdf2xml v2.0 allows attackers to cause a denial of service (DoS).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-23872"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-10T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "A NULL pointer dereference in the function TextPage::restoreState of pdf2xml v2.0 allows attackers to cause a denial of service (DoS).",
  "id": "GHSA-52x5-63xf-5w3p",
  "modified": "2022-05-24T19:20:15Z",
  "published": "2022-05-24T19:20:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-23872"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kermitt2/pdf2xml/issues/10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Aurorainfinity/Poc/tree/master/pdf2xml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-5322-F7JR-CV4M

Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-11 18:30
VLAI
Details

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

net/smc: Reset connection when trying to use SMCRv2 fails.

We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It can be reproduced by:

  • smc_run nginx
  • smc_run wrk -t 32 -c 500 -d 30 http://:

BUG: kernel NULL pointer dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ? __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ? __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50

During the CLC handshake, server sequentially tries available SMCRv2 and SMCRv1 devices in smc_listen_work().

If an SMCRv2 device is found. SMCv2 based link group and link will be assigned to the connection. Then assumed that some buffer assignment errors happen later in the CLC handshake, such as RMB registration failure, server will give up SMCRv2 and try SMCRv1 device instead. But the resources assigned to the connection won't be reset.

When server tries SMCRv1 device, the connection creation process will be executed again. Since conn->lnk has been assigned when trying SMCRv2, it will not be set to the correct SMCRv1 link in smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to correct SMCRv1 link group but conn->lnk points to the SMCRv2 link mistakenly.

Then in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx] will be accessed. Since the link->link_idx is not correct, the related MR may not have been initialized, so crash happens.

| Try SMCRv2 device first | |-> conn->lgr: assign existed SMCRv2 link group; | |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC); | |-> sndbuf & RMB creation fails, quit; | | Try SMCRv1 device then | |-> conn->lgr: create SMCRv1 link group and assign; | |-> conn->link: keep SMCRv2 link mistakenly; | |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0] | initialized. | | Then smc_clc_send_confirm_accept() accesses | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash. v

This patch tries to fix this by cleaning conn->lnk before assigning link. In addition, it is better to reset the connection and clean the resources assigned if trying SMCRv2 failed in buffer creation or registration.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-53382"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-18T14:15:41Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: Reset connection when trying to use SMCRv2 fails.\n\nWe found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It\ncan be reproduced by:\n\n- smc_run nginx\n- smc_run wrk -t 32 -c 500 -d 30 http://\u003cip\u003e:\u003cport\u003e\n\n BUG: kernel NULL pointer dereference, address: 0000000000000014\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0\n Oops: 0000 [#1] PREEMPT SMP PTI\n CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G        W   E      6.4.0-rc1+ #42\n Workqueue: smc_hs_wq smc_listen_work [smc]\n RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc]\n RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06\n RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000\n RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00\n RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000\n R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180\n R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001\n FS:  0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  \u003cTASK\u003e\n  ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib]\n  ? smcr_buf_map_link+0x24b/0x290 [smc]\n  ? __smc_buf_create+0x4ee/0x9b0 [smc]\n  smc_clc_send_accept+0x4c/0xb0 [smc]\n  smc_listen_work+0x346/0x650 [smc]\n  ? __schedule+0x279/0x820\n  process_one_work+0x1e5/0x3f0\n  worker_thread+0x4d/0x2f0\n  ? __pfx_worker_thread+0x10/0x10\n  kthread+0xe5/0x120\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x2c/0x50\n  \u003c/TASK\u003e\n\nDuring the CLC handshake, server sequentially tries available SMCRv2\nand SMCRv1 devices in smc_listen_work().\n\nIf an SMCRv2 device is found. SMCv2 based link group and link will be\nassigned to the connection. Then assumed that some buffer assignment\nerrors happen later in the CLC handshake, such as RMB registration\nfailure, server will give up SMCRv2 and try SMCRv1 device instead. But\nthe resources assigned to the connection won\u0027t be reset.\n\nWhen server tries SMCRv1 device, the connection creation process will\nbe executed again. Since conn-\u003elnk has been assigned when trying SMCRv2,\nit will not be set to the correct SMCRv1 link in\nsmcr_lgr_conn_assign_link(). So in such situation, conn-\u003elgr points to\ncorrect SMCRv1 link group but conn-\u003elnk points to the SMCRv2 link\nmistakenly.\n\nThen in smc_clc_send_confirm_accept(), conn-\u003ermb_desc-\u003emr[link-\u003elink_idx]\nwill be accessed. Since the link-\u003elink_idx is not correct, the related\nMR may not have been initialized, so crash happens.\n\n | Try SMCRv2 device first\n |     |-\u003e conn-\u003elgr:\tassign existed SMCRv2 link group;\n |     |-\u003e conn-\u003elink:\tassign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC);\n |     |-\u003e sndbuf \u0026 RMB creation fails, quit;\n |\n | Try SMCRv1 device then\n |     |-\u003e conn-\u003elgr:\tcreate SMCRv1 link group and assign;\n |     |-\u003e conn-\u003elink:\tkeep SMCRv2 link mistakenly;\n |     |-\u003e sndbuf \u0026 RMB creation succeed, only RMB-\u003emr[link_idx = 0]\n |         initialized.\n |\n | Then smc_clc_send_confirm_accept() accesses\n | conn-\u003ermb_desc-\u003emr[conn-\u003elink-\u003elink_idx, which is 1], then crash.\n v\n\nThis patch tries to fix this by cleaning conn-\u003elnk before assigning\nlink. In addition, it is better to reset the connection and clean the\nresources assigned if trying SMCRv2 failed in buffer creation or\nregistration.",
  "id": "GHSA-5322-f7jr-cv4m",
  "modified": "2025-12-11T18:30:33Z",
  "published": "2025-09-18T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53382"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/35112271672ae98f45df7875244a4e33aa215e31"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9540765d1882d15497d880096de99fafabcfa08c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d33be18917ffe69865dfed18b0a67b0dee0b47d7"
    }
  ],
  "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-5339-45C2-MH5V

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2025-04-11 12:31
VLAI
Details

Null pointer dereference was found in upx PackLinuxElf::canUnpack() in p_lx_elf.cpp,in version UPX 4.0.0. That allow attackers to execute arbitrary code and cause a denial of service via a crafted file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-30500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-27T00:15:00Z",
    "severity": "HIGH"
  },
  "details": "Null pointer dereference was found in upx PackLinuxElf::canUnpack() in p_lx_elf.cpp,in version UPX 4.0.0. That allow attackers to execute arbitrary code and cause a denial of service via a crafted file.",
  "id": "GHSA-5339-45c2-mh5v",
  "modified": "2025-04-11T12:31:38Z",
  "published": "2022-05-24T19:03:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30500"
    },
    {
      "type": "WEB",
      "url": "https://github.com/upx/upx/issues/485"
    },
    {
      "type": "WEB",
      "url": "https://github.com/upx/upx/commit/90279abdfcd235172eab99651043051188938dcc"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1948692"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-533H-QGF9-6H99

Vulnerability from github – Published: 2022-05-17 02:55 – Updated: 2025-04-20 03:34
VLAI
Details

The PoDoFo::PdfColorGray::~PdfColorGray function in PdfColor.cpp in PoDoFo 0.9.4 allows remote attackers to cause a denial of service (NULL pointer dereference) via a crafted file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-6849"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-15T14:59:00Z",
    "severity": "MODERATE"
  },
  "details": "The PoDoFo::PdfColorGray::~PdfColorGray function in PdfColor.cpp in PoDoFo 0.9.4 allows remote attackers to cause a denial of service (NULL pointer dereference) via a crafted file.",
  "id": "GHSA-533h-qgf9-6h99",
  "modified": "2025-04-20T03:34:10Z",
  "published": "2022-05-17T02:55:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6849"
    },
    {
      "type": "WEB",
      "url": "https://blogs.gentoo.org/ago/2017/03/02/podofo-null-pointer-dereference-in-podofopdfcolorgraypdfcolorgray-pdfcolor-cpp"
    }
  ],
  "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-534C-PJGH-9R4G

Vulnerability from github – Published: 2025-12-02 03:31 – Updated: 2025-12-02 15:30
VLAI
Details

In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01661199; Issue ID: MSV-4296.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-20750"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-02T03:16:16Z",
    "severity": "MODERATE"
  },
  "details": "In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01661199; Issue ID: MSV-4296.",
  "id": "GHSA-534c-pjgh-9r4g",
  "modified": "2025-12-02T15:30:29Z",
  "published": "2025-12-02T03:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20750"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/December-2025"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-53C4-HHMH-VW5Q

Vulnerability from github – Published: 2022-12-14 21:38 – Updated: 2023-08-30 18:40
VLAI
Summary
Helm vulnerable to denial of service through through repository index file
Details

Fuzz testing, by Ada Logics and sponsored by the CNCF, identified input to functions in the _repo_ package that can cause a segmentation violation. Applications that use functions from the _repo_ package in the Helm SDK can have a Denial of Service attack when they use this package and it panics.

Impact

The _repo_ package contains a handler that processes the index file of a repository. For example, the Helm client adds references to chart repositories where charts are managed. The _repo_ package parses the index file of the repository and loads it into structures Go can work with. Some index files can cause array data structures to be created causing a memory violation.

Applications that use the _repo_ package in the Helm SDK to parse an index file can suffer a Denial of Service when that input causes a panic that cannot be recovered from.

The Helm Client will panic with an index file that causes a memory violation panic. Helm is not a long running service so the panic will not affect future uses of the Helm client.

Patches

This issue has been resolved in 3.10.3.

Workarounds

SDK users can validate index files that are correctly formatted before passing them to the _repo_ functions.

For more information

Helm's security policy is spelled out in detail in our SECURITY document.

Credits

Disclosed by Ada Logics in a fuzzing audit sponsored by CNCF.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "helm.sh/helm/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23525"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-14T21:38:31Z",
    "nvd_published_at": "2022-12-15T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Fuzz testing, by Ada Logics and sponsored by the CNCF, identified input to functions in the `_repo_` package that can cause a segmentation violation. Applications that use functions from the `_repo_` package in the Helm SDK can have a Denial of Service attack when they use this package and it panics.\n\n### Impact\n\nThe `_repo_` package contains a handler that processes the index file of a repository. For example, the Helm client adds references to chart repositories where charts are managed. The `_repo_` package parses the index file of the repository and loads it into structures Go can work with. Some index files can cause array data structures to be created causing a memory violation.\n\nApplications that use the `_repo_` package in the Helm SDK to parse an index file can suffer a Denial of Service when that input causes a panic that cannot be recovered from.\n\nThe Helm Client will panic with an index file that causes a memory violation panic. Helm is not a long running service so the panic will not affect future uses of the Helm client.\n\n### Patches\n\nThis issue has been resolved in 3.10.3. \n\n### Workarounds\n\nSDK users can validate index files that are correctly formatted before passing them to the `_repo_` functions.\n\n### For more information\n\nHelm\u0027s security policy is spelled out in detail in our [SECURITY](https://github.com/helm/community/blob/master/SECURITY.md) document.\n\n### Credits\n\nDisclosed by Ada Logics in a fuzzing audit sponsored by CNCF.",
  "id": "GHSA-53c4-hhmh-vw5q",
  "modified": "2023-08-30T18:40:46Z",
  "published": "2022-12-14T21:38:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/security/advisories/GHSA-53c4-hhmh-vw5q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23525"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/commit/638ebffbc2e445156f3978f02fd83d9af1e56f5b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/helm/helm"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2022-1165"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Helm vulnerable to denial of service through through repository index file"
}

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.