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.

6370 vulnerabilities reference this CWE, most recent first.

GHSA-PP7M-7XWH-J3H9

Vulnerability from github – Published: 2025-09-17 15:30 – Updated: 2025-12-10 00:30
VLAI
Details

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

media: cx88: Fix a null-ptr-deref bug in buffer_prepare()

When the driver calls cx88_risc_buffer() to prepare the buffer, the function call may fail, resulting in a empty buffer and null-ptr-deref later in buffer_queue().

The following log can reveal it:

[ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI [ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500 [ 41.836311] Call Trace: [ 41.836945] __enqueue_in_driver+0x141/0x360 [ 41.837262] vb2_start_streaming+0x62/0x4a0 [ 41.838216] vb2_core_streamon+0x1da/0x2c0 [ 41.838516] __vb2_init_fileio+0x981/0xbc0 [ 41.839141] __vb2_perform_fileio+0xbf9/0x1120 [ 41.840072] vb2_fop_read+0x20e/0x400 [ 41.840346] v4l2_read+0x215/0x290 [ 41.840603] vfs_read+0x162/0x4c0

Fix this by checking the return value of cx88_risc_buffer()

[hverkuil: fix coding style issues]

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50359"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-17T15:15:34Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx88: Fix a null-ptr-deref bug in buffer_prepare()\n\nWhen the driver calls cx88_risc_buffer() to prepare the buffer, the\nfunction call may fail, resulting in a empty buffer and null-ptr-deref\nlater in buffer_queue().\n\nThe following log can reveal it:\n\n[   41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\n[   41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n[   41.828027] RIP: 0010:buffer_queue+0xc2/0x500\n[   41.836311] Call Trace:\n[   41.836945]  __enqueue_in_driver+0x141/0x360\n[   41.837262]  vb2_start_streaming+0x62/0x4a0\n[   41.838216]  vb2_core_streamon+0x1da/0x2c0\n[   41.838516]  __vb2_init_fileio+0x981/0xbc0\n[   41.839141]  __vb2_perform_fileio+0xbf9/0x1120\n[   41.840072]  vb2_fop_read+0x20e/0x400\n[   41.840346]  v4l2_read+0x215/0x290\n[   41.840603]  vfs_read+0x162/0x4c0\n\nFix this by checking the return value of cx88_risc_buffer()\n\n[hverkuil: fix coding style issues]",
  "id": "GHSA-pp7m-7xwh-j3h9",
  "modified": "2025-12-10T00:30:21Z",
  "published": "2025-09-17T15:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50359"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/10c99d1c46ea9cd940029e17bab11d021f315c21"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2b064d91440b33fba5b452f2d1b31f13ae911d71"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4befc7ffa18ef9a4b70d854465313a345a06862f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/644d5a87ab1863eb606526ea743021752a17e9cb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6f21976095c1e92454ab030976f95f40d652351b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/704838040f3bdb4aa07ff4f26505a666a3defcfe"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9181af2dbf06e7f432e5dbe88d10b22343e851b9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c2257c8a501537afab276c306cb717b7260276e1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c76d04d2079a4b7369ce9a0e859c0f3f2250bcc1"
    }
  ],
  "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-PP8C-QFHV-484P

Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-11-17 15:30
VLAI
Details

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

ocfs2: fix panic in failed foilio allocation

commit 7e119cff9d0a ("ocfs2: convert w_pages to w_folios") and commit 9a5e08652dc4b ("ocfs2: use an array of folios instead of an array of pages") save -ENOMEM in the folio array upon allocation failure and call the folio array free code.

The folio array free code expects either valid folio pointers or NULL. Finding the -ENOMEM will result in a panic. Fix by NULLing the error folio entry.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-37950"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-20T16:15:33Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix panic in failed foilio allocation\n\ncommit 7e119cff9d0a (\"ocfs2: convert w_pages to w_folios\") and commit\n9a5e08652dc4b (\"ocfs2: use an array of folios instead of an array of\npages\") save -ENOMEM in the folio array upon allocation failure and call\nthe folio array free code.\n\nThe folio array free code expects either valid folio pointers or NULL. \nFinding the -ENOMEM will result in a panic.  Fix by NULLing the error\nfolio entry.",
  "id": "GHSA-pp8c-qfhv-484p",
  "modified": "2025-11-17T15:30:32Z",
  "published": "2025-05-20T18:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37950"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/31d4cd4eb2f8d9b87ebfa6a5e443a59e3b3d7b8c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/80d18f060d5bdf2c5eb3d1d00dcb744d6a879222"
    }
  ],
  "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-PPHC-92V7-V4W2

Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-28 09:31
VLAI
Details

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

netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check

The nf_osf_ttl() function accessed skb->dev to perform a local interface address lookup without verifying that the device pointer was valid.

Additionally, the implementation utilized an in_dev_for_each_ifa_rcu loop to match the packet source address against local interface addresses. It assumed that packets from the same subnet should not see a decrement on the initial TTL. A packet might appear it is from the same subnet but it actually isn't especially in modern environments with containers and virtual switching.

Remove the device dereference and interface loop. Replace the logic with a switch statement that evaluates the TTL according to the ttl_check.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-52998"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-24T17:17:10Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_osf: fix potential NULL dereference in ttl check\n\nThe nf_osf_ttl() function accessed skb-\u003edev to perform a local interface\naddress lookup without verifying that the device pointer was valid.\n\nAdditionally, the implementation utilized an in_dev_for_each_ifa_rcu\nloop to match the packet source address against local interface\naddresses. It assumed that packets from the same subnet should not see a\ndecrement on the initial TTL. A packet might appear it is from the same\nsubnet but it actually isn\u0027t especially in modern environments with\ncontainers and virtual switching.\n\nRemove the device dereference and interface loop. Replace the logic with\na switch statement that evaluates the TTL according to the ttl_check.",
  "id": "GHSA-pphc-92v7-v4w2",
  "modified": "2026-06-28T09:31:37Z",
  "published": "2026-06-24T18:32:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52998"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5d05de2f0928d81309a815ecc76d1a3ad72cbc16"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/711987ba281fd806322a7cd244e98e2a81903114"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/79b90a96688e521771fa6ed3dc7864b76b8df293"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/83fc5dd63455a779ea2dd0f7ffee3c920919d80b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/95be653a76793856ff8b2d8bd82c2943c23f5ca8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c996a90f3071cf43683e5423da31aadbe002b8b4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/edc806f9122961f0d3819f7c69c14cccde31f277"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f4de0777e4554a7de19c920accde6319dd530782"
    }
  ],
  "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-PPJR-267J-5P9X

Vulnerability from github – Published: 2023-03-20 21:11 – Updated: 2023-07-19 19:19
VLAI
Summary
NULL pointer derefernce in `stb_image`
Details

A bug in error handling in the stb_image C library could cause a NULL pointer dereference when attempting to load an invalid or unsupported image file. This is fixed in version 0.2.5 and later of the stb_image Rust crate, by patching the C code to correctly handle NULL pointers.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "stb_image"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-20T21:11:58Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "A bug in error handling in the `stb_image` C library could cause a NULL pointer dereference when attempting to load an invalid or unsupported image file.  This is fixed in version 0.2.5 and later of the `stb_image` Rust crate, by patching the C code to correctly handle NULL pointers.\n",
  "id": "GHSA-ppjr-267j-5p9x",
  "modified": "2023-07-19T19:19:42Z",
  "published": "2023-03-20T21:11:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/servo/rust-stb-image/pull/102"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/servo/rust-stb-imag"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2023-0021.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "NULL pointer derefernce in `stb_image`"
}

GHSA-PPWX-W5V2-MFJ6

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

An issue was discovered in swftools through 20200710. A NULL pointer dereference exists in the function dump_method() located in abc.c. It allows an attacker to cause Denial of Service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-39575"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-20T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in swftools through 20200710. A NULL pointer dereference exists in the function dump_method() located in abc.c. It allows an attacker to cause Denial of Service.",
  "id": "GHSA-ppwx-w5v2-mfj6",
  "modified": "2022-05-24T19:15:06Z",
  "published": "2022-05-24T19:15:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39575"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matthiaskramm/swftools/issues/128"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PQ25-X76J-WRFP

Vulnerability from github – Published: 2022-11-10 19:01 – Updated: 2022-11-10 19:01
VLAI
Details

NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where a local user with basic capabilities can cause a null-pointer dereference, which may lead to denial of service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-34666"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-10T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where a local user with basic capabilities can cause a null-pointer dereference, which may lead to denial of service.",
  "id": "GHSA-pq25-x76j-wrfp",
  "modified": "2022-11-10T19:01:07Z",
  "published": "2022-11-10T19:01:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34666"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5383"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202310-02"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PQ4C-FM9X-V9HJ

Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-30 03:37
VLAI
Details

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

drm/xe/dma-buf: handle empty bo and UAF races

There look to be some nasty races here when triggering the invalidate_mappings hook:

1) We do xe_bo_alloc() followed by the attach, before the actual full bo init step in xe_dma_buf_init_obj(). However the bo is visible on the attachments list after the attach. This is bad since exporter driver, say amdgpu, can at any time call back into our invalidate_mappings hook, with an empty/bogus bo, leading to potential bugs/crashes.

2) Similar to 1) but here we get a UAF, when the invalidate_mappings hook is triggered. For example, we get as far as xe_bo_init_locked() but this fails in some way. But here the bo will be freed on error, but we still have it attached from dma-buf pov, so if the invalidate_mappings is now triggered then the bo we access is gone and we trigger UAF and more bugs/crashes.

To fix this, move the attach step until after we actually have a fully set up buffer object. Note that the bo is not published to userspace until later, so not sure what the comment "Don't publish the bo until we have a valid attachment", is referring to.

We have at least two different customers reporting hitting a NULL ptr deref in evict_flags when importing something from amdgpu, followed by triggering the evict flow. Hit rate is also pretty low, which would hint at some kind of race, so something like 1) or 2) might explain this.

v2: - Shuffle the order of the ops slightly (no functional change) - Improve the comment to better explain the ordering (Matt B)

(cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-52951"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416",
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-24T17:17:05Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/dma-buf: handle empty bo and UAF races\n\nThere look to be some nasty races here when triggering the\ninvalidate_mappings hook:\n\n1) We do xe_bo_alloc() followed by the attach, before the actual full bo\n   init step in xe_dma_buf_init_obj(). However the bo is visible on the\n   attachments list after the attach.  This is bad since exporter driver,\n   say amdgpu, can at any time call back into our invalidate_mappings hook,\n   with an empty/bogus bo, leading to potential bugs/crashes.\n\n2) Similar to 1) but here we get a UAF, when the invalidate_mappings\n   hook is triggered. For example, we get as far as xe_bo_init_locked()\n   but this fails in some way. But here the bo will be freed on error, but\n   we still have it attached from dma-buf pov, so if the\n   invalidate_mappings is now triggered then the bo we access is gone and\n   we trigger UAF and more bugs/crashes.\n\nTo fix this, move the attach step until after we actually have a fully\nset up buffer object. Note that the bo is not published to userspace\nuntil later, so not sure what the comment \"Don\u0027t publish the bo\nuntil we have a valid attachment\", is referring to.\n\nWe have at least two different customers reporting hitting a NULL ptr\nderef in evict_flags when importing something from amdgpu, followed by\ntriggering the evict flow. Hit rate is also pretty low, which would\nhint at some kind of race, so something like 1) or 2) might explain\nthis.\n\nv2:\n  - Shuffle the order of the ops slightly (no functional change)\n  - Improve the comment to better explain the ordering (Matt B)\n\n(cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)",
  "id": "GHSA-pq4c-fm9x-v9hj",
  "modified": "2026-06-30T03:37:11Z",
  "published": "2026-06-24T18:32:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52951"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-52951"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492353"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/20a99ea1e2fd720856d6ba497ff26b82c604751f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/981bedbbe61364fcc3a3b87ebaf648a66cd07108"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9894731e513019df22a29e5c52f1c98890355ff1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c473ae25421fddc3dde247ba7b85225b10641d09"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52951.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PQ5R-RP8M-P9VH

Vulnerability from github – Published: 2024-03-29 00:30 – Updated: 2024-08-22 21:31
VLAI
Details

Jerryscript 2.4.0 has SEGV at ./jerry-core/ecma/base/ecma-helpers.c:238:58 in ecma_get_object_type.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-29489"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-28T23:15:46Z",
    "severity": "MODERATE"
  },
  "details": "Jerryscript 2.4.0 has SEGV at ./jerry-core/ecma/base/ecma-helpers.c:238:58 in ecma_get_object_type.",
  "id": "GHSA-pq5r-rp8m-p9vh",
  "modified": "2024-08-22T21:31:27Z",
  "published": "2024-03-29T00:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29489"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jerryscript-project/jerryscript/issues/5101"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jerryscript-project/jerryscript/pull/5129"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jerryscript-project/jerryscript/commit/cefd391772529c8a9531d7b3c244d78d38be47c6"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/gandalf4a/9826a897ae1e3c8d1c7e71a1ec71d415"
    }
  ],
  "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-PQ66-H8QJ-7XG9

Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-01-16 18:30
VLAI
Details

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

cacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU

Commit

5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU")

adds functionality that architectures can use to optionally allocate and build cacheinfo early during boot. Commit

6539cffa9495 ("cacheinfo: Add arch specific early level initializer")

lets secondary CPUs correct (and reallocate memory) cacheinfo data if needed.

If the early build functionality is not used and cacheinfo does not need correction, memory for cacheinfo is never allocated. x86 does not use the early build functionality. Consequently, during the cacheinfo CPU hotplug callback, last_level_cache_is_valid() attempts to dereference a NULL pointer:

BUG: kernel NULL pointer dereference, address: 0000000000000100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not present page PGD 0 P4D 0 Oops: 0000 [#1] PREEPMT SMP NOPTI CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1 RIP: 0010: last_level_cache_is_valid+0x95/0xe0a

Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback if not done earlier.

Moreover, before determining the validity of the last-level cache info, ensure that it has been allocated. Simply checking for non-zero cache_leaves() is not sufficient, as some architectures (e.g., Intel processors) have non-zero cache_leaves() before allocation.

Dereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size(). This function iterates over all online CPUs. However, a CPU may have come online recently, but its cacheinfo may not have been allocated yet.

While here, remove an unnecessary indentation in allocate_cache_info().

[ bp: Massage. ]

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-56617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-27T15:15:21Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU\n\nCommit\n\n  5944ce092b97 (\"arch_topology: Build cacheinfo from primary CPU\")\n\nadds functionality that architectures can use to optionally allocate and\nbuild cacheinfo early during boot. Commit\n\n  6539cffa9495 (\"cacheinfo: Add arch specific early level initializer\")\n\nlets secondary CPUs correct (and reallocate memory) cacheinfo data if\nneeded.\n\nIf the early build functionality is not used and cacheinfo does not need\ncorrection, memory for cacheinfo is never allocated. x86 does not use\nthe early build functionality. Consequently, during the cacheinfo CPU\nhotplug callback, last_level_cache_is_valid() attempts to dereference\na NULL pointer:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000100\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] PREEPMT SMP NOPTI\n  CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1\n  RIP: 0010: last_level_cache_is_valid+0x95/0xe0a\n\nAllocate memory for cacheinfo during the cacheinfo CPU hotplug callback\nif not done earlier.\n\nMoreover, before determining the validity of the last-level cache info,\nensure that it has been allocated. Simply checking for non-zero\ncache_leaves() is not sufficient, as some architectures (e.g., Intel\nprocessors) have non-zero cache_leaves() before allocation.\n\nDereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size().\nThis function iterates over all online CPUs. However, a CPU may have come\nonline recently, but its cacheinfo may not have been allocated yet.\n\nWhile here, remove an unnecessary indentation in allocate_cache_info().\n\n  [ bp: Massage. ]",
  "id": "GHSA-pq66-h8qj-7xg9",
  "modified": "2025-01-16T18:30:59Z",
  "published": "2024-12-27T15:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56617"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/23b5908b11b77ff8d7b8f7b8f11cbab2e1f4bfc2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/95e197354e0de07e9a20819bdae6562e4dda0f20"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b3fce429a1e030b50c1c91351d69b8667eef627b"
    }
  ],
  "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-PQ7F-896M-7JG7

Vulnerability from github – Published: 2024-02-13 09:30 – Updated: 2024-02-13 09:30
VLAI
Details

A vulnerability has been identified in Tecnomatix Plant Simulation V2201 (All versions), Tecnomatix Plant Simulation V2302 (All versions < V2302.0007). The affected applications contain a null pointer dereference vulnerability while parsing specially crafted SPP files. An attacker could leverage this vulnerability to crash the application causing denial of service condition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-23800"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-13T09:15:48Z",
    "severity": "LOW"
  },
  "details": "A vulnerability has been identified in Tecnomatix Plant Simulation V2201 (All versions), Tecnomatix Plant Simulation V2302 (All versions \u003c V2302.0007). The affected applications contain a null pointer dereference vulnerability while parsing specially crafted SPP files. An attacker could leverage this vulnerability to crash the application causing denial of service condition.",
  "id": "GHSA-pq7f-896m-7jg7",
  "modified": "2024-02-13T09:30:33Z",
  "published": "2024-02-13T09:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23800"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-017796.html"
    }
  ],
  "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:L",
      "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.