Common Weakness Enumeration

CWE-476

Allowed

NULL Pointer Dereference

Abstraction: Base · Status: Stable

API response cwe.mitre.org

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

6310 vulnerabilities reference this CWE, most recent first.

GHSA-J57R-QMGX-XP34

Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-04-15 18:31
VLAI
Details

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

RDMA/bnxt_re: Add sanity checks on rdev validity

There is a possibility that ulp_irq_stop and ulp_irq_start callbacks will be called when the device is in detached state. This can cause a crash due to NULL pointer dereference as the rdev is already freed.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-21901"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-01T16:15:20Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Add sanity checks on rdev validity\n\nThere is a possibility that ulp_irq_stop and ulp_irq_start\ncallbacks will be called when the device is in detached state.\nThis can cause a crash due to NULL pointer dereference as\nthe rdev is already freed.",
  "id": "GHSA-j57r-qmgx-xp34",
  "modified": "2025-04-15T18:31:42Z",
  "published": "2025-04-01T18:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21901"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8cb0eef46d70a99c88c26a1addb7fd955242e0e6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aed1bc673907e3df372b317c10ff2f3582f8bf1a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f0df225d12fcb049429fb5bf5122afe143c2dd15"
    }
  ],
  "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-J57X-5H9F-J263

Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-04-23 21:31
VLAI
Details

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

accel/amdxdna: Fix NULL pointer dereference of mgmt_chann

mgmt_chann may be set to NULL if the firmware returns an unexpected error in aie2_send_mgmt_msg_wait(). This can later lead to a NULL pointer dereference in aie2_hw_stop().

Fix this by introducing a dedicated helper to destroy mgmt_chann and by adding proper NULL checks before accessing it.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-23328"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T11:16:29Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/amdxdna: Fix NULL pointer dereference of mgmt_chann\n\nmgmt_chann may be set to NULL if the firmware returns an unexpected\nerror in aie2_send_mgmt_msg_wait(). This can later lead to a NULL\npointer dereference in aie2_hw_stop().\n\nFix this by introducing a dedicated helper to destroy mgmt_chann\nand by adding proper NULL checks before accessing it.",
  "id": "GHSA-j57x-5h9f-j263",
  "modified": "2026-04-23T21:31:17Z",
  "published": "2026-03-25T12:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23328"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/032ca7a9059c4ba6c329e0f1b442dab54dd9c3e5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6270ee26e1edd862ea17e3eba148ca8fb2c99dc9"
    }
  ],
  "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-J58H-PPM8-RM4X

Vulnerability from github – Published: 2025-01-19 12:31 – Updated: 2025-01-31 15:30
VLAI
Details

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

nfs: Fix oops in nfs_netfs_init_request() when copying to cache

When netfslib wants to copy some data that has just been read on behalf of nfs, it creates a new write request and calls nfs_netfs_init_request() to initialise it, but with a NULL file pointer. This causes nfs_file_open_context() to oops - however, we don't actually need the nfs context as we're only going to write to the cache.

Fix this by just returning if we aren't given a file pointer and emit a warning if the request was for something other than copy-to-cache.

Further, fix nfs_netfs_free_request() so that it doesn't try to free the context if the pointer is NULL.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-57927"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-19T12:15:26Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfs: Fix oops in nfs_netfs_init_request() when copying to cache\n\nWhen netfslib wants to copy some data that has just been read on behalf of\nnfs, it creates a new write request and calls nfs_netfs_init_request() to\ninitialise it, but with a NULL file pointer.  This causes\nnfs_file_open_context() to oops - however, we don\u0027t actually need the nfs\ncontext as we\u0027re only going to write to the cache.\n\nFix this by just returning if we aren\u0027t given a file pointer and emit a\nwarning if the request was for something other than copy-to-cache.\n\nFurther, fix nfs_netfs_free_request() so that it doesn\u0027t try to free the\ncontext if the pointer is NULL.",
  "id": "GHSA-j58h-ppm8-rm4x",
  "modified": "2025-01-31T15:30:44Z",
  "published": "2025-01-19T12:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57927"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/13a07cc81e2d116cece727a83746c74b87a9d417"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/86ad1a58f6a9453f49e06ef957a40a8dac00a13f"
    }
  ],
  "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-J59F-X285-69JX

Vulnerability from github – Published: 2026-05-08 22:50 – Updated: 2026-06-08 23:47
VLAI
Summary
free5GC's NEF 3gpp-pfd-management PATCH applications/{appId} panics on UDR access failure due to nil ProblemDetails dereference
Details

Summary

free5GC's NEF PATCH /3gpp-pfd-management/v1/{afId}/transactions/{transId}/applications/{appId} handler panics with a nil-pointer dereference when the upstream UDR call fails AND the consumer wrapper returns err != nil together with a nil *ProblemDetails. The handler's errPfdData != nil branch builds its own problemDetailsErr correctly, but immediately after it reads problemDetails.Cause (the OTHER value, which is nil in this branch) and panics. Gin recovery converts the panic into HTTP 500, so a single PATCH against this endpoint returns 500 instead of the intended controlled error response whenever UDR access is failing.

This is a second-order bug: the trigger requires UDR access to be failing (e.g. NRF or UDR is unreachable, registration broken, transient network failure). The attacker does not directly control that condition, so this is scored as AC:H. Once the upstream condition exists, the trigger is a single PATCH request and is repeatable.

The HTTP request itself in v4.2.1 is reachable without an Authorization header because the underlying NEF 3gpp-pfd-management route group is mounted without inbound auth middleware (see free5gc/free5gc#858). So in the validation lab the entire trigger chain is unauthenticated end-to-end.

Details

Validated against the NEF container in the official Docker compose lab. - Source repo tag: v4.2.1 - Running Docker image: free5gc/nef:v4.2.1 - Runtime NEF commit: 5ce35eab - Docker validation date: 2026-03-21 (container log timestamp 2026-03-21T03:06:36Z) - NEF endpoint: http://10.100.200.19:8000

Vulnerable handler logic in PatchIndividualApplicationPFDManagement (paraphrased):

pdfData, problemDetails, errPfdData := p.Consumer().AppDataPfdsAppIdGet(appID)

switch {
case problemDetails != nil:
    ...
case errPfdData != nil:
    problemDetailsErr := &models.ProblemDetails{
        Status: http.StatusInternalServerError,
        Detail: "Query to UDR failed",
    }
    c.Set(sbi.IN_PB_DETAILS_CTX_STR, problemDetails.Cause)   // <-- nil deref
    c.JSON(int(problemDetailsErr.Status), problemDetailsErr)
    return
}

In the errPfdData != nil branch, problemDetails is by construction nil (otherwise the first case would have matched). Reading problemDetails.Cause panics with runtime error: invalid memory address or nil pointer dereference. The intended value is presumably problemDetailsErr.Cause -- the locally constructed problem-details struct.

Code evidence (paths in free5gc/nef): - Patch handler core path: - NFs/nef/internal/sbi/processor/pfd.go:563 - NFs/nef/internal/sbi/processor/pfd.go:610 - Panic site (nil-deref on problemDetails.Cause): - NFs/nef/internal/sbi/processor/pfd.go:622 - Route exposure / dispatch: - NFs/nef/internal/sbi/api_pfd.go:168 - NFs/nef/internal/sbi/api_pfd.go:188

PoC

Reproduced end-to-end against the running NEF at http://10.100.200.19:8000. The trigger requires UDR access to be failing -- the lab simulates this by stopping NRF (so NEF's UDR client fails to discover/dial UDR). In production, equivalent triggers include NRF outages, UDR outages, or transient network failures.

  1. Create an AF context (no Authorization header):
curl -i -X POST 'http://10.100.200.19:8000/3gpp-traffic-influence/v1/afnpd3/subscriptions' \
  -H 'Content-Type: application/json' \
  --data '{"afAppId":"app-nef-npd3","anyUeInd":true}'
  1. Create a PFD-management transaction:
curl -i -X POST 'http://10.100.200.19:8000/3gpp-pfd-management/v1/afnpd3/transactions' \
  -H 'Content-Type: application/json' \
  --data '{"pfdDatas":{"appnpd3":{"externalAppId":"appnpd3","pfds":{"pfd1":{"pfdId":"pfd1","flowDescriptions":["permit in ip from 10.68.28.39 80 to any"]}}}}}'
  1. Make UDR access fail (lab simulation):
docker stop nrf
  1. Trigger the panic with one PATCH:
curl -i -X PATCH 'http://10.100.200.19:8000/3gpp-pfd-management/v1/afnpd3/transactions/1/applications/appnpd3' \
  -H 'Content-Type: application/json' \
  --data '{"externalAppId":"appnpd3","pfds":{"pfd1":{"pfdId":"pfd1","flowDescriptions":[]}}}'

HTTP/1.1 500 Internal Server Error
Content-Length: 0
  1. NEF container logs (docker logs --since 2026-03-21T03:06:36Z nef) confirm the nil-deref panic at pfd.go:622 inside PatchIndividualApplicationPFDManagement:
[INFO][NEF][PFDMng] PatchIndividualApplicationPFDManagement - scsAsID[afnpd3], transID[1], appID[appnpd3]
[ERRO][NEF][GIN] panic: runtime error: invalid memory address or nil pointer dereference
github.com/free5gc/nef/internal/sbi/processor.(*Processor).PatchIndividualApplicationPFDManagement
    .../pfd.go:622
github.com/free5gc/nef/internal/sbi.(*Server).apiPatchIndividualApplicationPFDManagement
    .../api_pfd.go:188
[INFO][NEF][GIN] | 500 | PATCH | /3gpp-pfd-management/v1/afnpd3/transactions/1/applications/appnpd3 |
  1. Restore for further testing:
docker start nrf

Impact

NULL pointer dereference (CWE-476) caused by improper handling of an exceptional branch (CWE-754): the errPfdData != nil branch reads problemDetails.Cause even though problemDetails is nil by construction in that branch (the prior case already matched the non-nil case). The intended target was the locally constructed problemDetailsErr.Cause.

Gin recovery catches the panic, so the NEF process is NOT killed and other endpoints continue serving. The realized impact is per-request: PATCH against this endpoint returns 500 (with empty body and a stack trace in NEF logs) instead of the intended controlled UDR-failure response, whenever upstream UDR access is failing.

No Confidentiality impact (the response is 500 with empty body). No persistent Integrity impact (the panic happens before any state mutation). Availability impact is limited to per-request degradation and only fires while UDR access is independently broken; the attacker does not directly control that precondition, so AC:H is the honest assessment.

Affected: free5gc v4.2.1.

Upstream issue: https://github.com/free5gc/free5gc/issues/925 Upstream fix: https://github.com/free5gc/nef/pull/22

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/nef"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44322"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476",
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T22:50:57Z",
    "nvd_published_at": "2026-05-27T17:16:37Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nfree5GC\u0027s NEF `PATCH /3gpp-pfd-management/v1/{afId}/transactions/{transId}/applications/{appId}` handler panics with a nil-pointer dereference when the upstream UDR call fails AND the consumer wrapper returns `err != nil` together with a nil `*ProblemDetails`. The handler\u0027s `errPfdData != nil` branch builds its own `problemDetailsErr` correctly, but immediately after it reads `problemDetails.Cause` (the OTHER value, which is nil in this branch) and panics. Gin recovery converts the panic into `HTTP 500`, so a single PATCH against this endpoint returns 500 instead of the intended controlled error response whenever UDR access is failing.\n\nThis is a second-order bug: the trigger requires UDR access to be failing (e.g. NRF or UDR is unreachable, registration broken, transient network failure). The attacker does not directly control that condition, so this is scored as AC:H. Once the upstream condition exists, the trigger is a single PATCH request and is repeatable.\n\nThe HTTP request itself in v4.2.1 is reachable without an `Authorization` header because the underlying NEF `3gpp-pfd-management` route group is mounted without inbound auth middleware (see free5gc/free5gc#858). So in the validation lab the entire trigger chain is unauthenticated end-to-end.\n\n### Details\nValidated against the NEF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/nef:v4.2.1`\n- Runtime NEF commit: `5ce35eab`\n- Docker validation date: 2026-03-21 (container log timestamp `2026-03-21T03:06:36Z`)\n- NEF endpoint: `http://10.100.200.19:8000`\n\nVulnerable handler logic in `PatchIndividualApplicationPFDManagement` (paraphrased):\n```go\npdfData, problemDetails, errPfdData := p.Consumer().AppDataPfdsAppIdGet(appID)\n\nswitch {\ncase problemDetails != nil:\n    ...\ncase errPfdData != nil:\n    problemDetailsErr := \u0026models.ProblemDetails{\n        Status: http.StatusInternalServerError,\n        Detail: \"Query to UDR failed\",\n    }\n    c.Set(sbi.IN_PB_DETAILS_CTX_STR, problemDetails.Cause)   // \u003c-- nil deref\n    c.JSON(int(problemDetailsErr.Status), problemDetailsErr)\n    return\n}\n```\nIn the `errPfdData != nil` branch, `problemDetails` is by construction nil (otherwise the first `case` would have matched). Reading `problemDetails.Cause` panics with `runtime error: invalid memory address or nil pointer dereference`. The intended value is presumably `problemDetailsErr.Cause` -- the locally constructed problem-details struct.\n\nCode evidence (paths in `free5gc/nef`):\n- Patch handler core path:\n  - `NFs/nef/internal/sbi/processor/pfd.go:563`\n  - `NFs/nef/internal/sbi/processor/pfd.go:610`\n- Panic site (nil-deref on `problemDetails.Cause`):\n  - `NFs/nef/internal/sbi/processor/pfd.go:622`\n- Route exposure / dispatch:\n  - `NFs/nef/internal/sbi/api_pfd.go:168`\n  - `NFs/nef/internal/sbi/api_pfd.go:188`\n\n### PoC\nReproduced end-to-end against the running NEF at `http://10.100.200.19:8000`. The trigger requires UDR access to be failing -- the lab simulates this by stopping NRF (so NEF\u0027s UDR client fails to discover/dial UDR). In production, equivalent triggers include NRF outages, UDR outages, or transient network failures.\n\n1. Create an AF context (no Authorization header):\n```\ncurl -i -X POST \u0027http://10.100.200.19:8000/3gpp-traffic-influence/v1/afnpd3/subscriptions\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"afAppId\":\"app-nef-npd3\",\"anyUeInd\":true}\u0027\n```\n\n2. Create a PFD-management transaction:\n```\ncurl -i -X POST \u0027http://10.100.200.19:8000/3gpp-pfd-management/v1/afnpd3/transactions\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"pfdDatas\":{\"appnpd3\":{\"externalAppId\":\"appnpd3\",\"pfds\":{\"pfd1\":{\"pfdId\":\"pfd1\",\"flowDescriptions\":[\"permit in ip from 10.68.28.39 80 to any\"]}}}}}\u0027\n```\n\n3. Make UDR access fail (lab simulation):\n```\ndocker stop nrf\n```\n\n4. Trigger the panic with one PATCH:\n```\ncurl -i -X PATCH \u0027http://10.100.200.19:8000/3gpp-pfd-management/v1/afnpd3/transactions/1/applications/appnpd3\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"externalAppId\":\"appnpd3\",\"pfds\":{\"pfd1\":{\"pfdId\":\"pfd1\",\"flowDescriptions\":[]}}}\u0027\n```\n```\nHTTP/1.1 500 Internal Server Error\nContent-Length: 0\n```\n\n5. NEF container logs (`docker logs --since 2026-03-21T03:06:36Z nef`) confirm the nil-deref panic at `pfd.go:622` inside `PatchIndividualApplicationPFDManagement`:\n```\n[INFO][NEF][PFDMng] PatchIndividualApplicationPFDManagement - scsAsID[afnpd3], transID[1], appID[appnpd3]\n[ERRO][NEF][GIN] panic: runtime error: invalid memory address or nil pointer dereference\ngithub.com/free5gc/nef/internal/sbi/processor.(*Processor).PatchIndividualApplicationPFDManagement\n    .../pfd.go:622\ngithub.com/free5gc/nef/internal/sbi.(*Server).apiPatchIndividualApplicationPFDManagement\n    .../api_pfd.go:188\n[INFO][NEF][GIN] | 500 | PATCH | /3gpp-pfd-management/v1/afnpd3/transactions/1/applications/appnpd3 |\n```\n\n6. Restore for further testing:\n```\ndocker start nrf\n```\n\n### Impact\nNULL pointer dereference (CWE-476) caused by improper handling of an exceptional branch (CWE-754): the `errPfdData != nil` branch reads `problemDetails.Cause` even though `problemDetails` is nil by construction in that branch (the prior `case` already matched the non-nil case). The intended target was the locally constructed `problemDetailsErr.Cause`.\n\nGin recovery catches the panic, so the NEF process is NOT killed and other endpoints continue serving. The realized impact is per-request: PATCH against this endpoint returns `500` (with empty body and a stack trace in NEF logs) instead of the intended controlled UDR-failure response, whenever upstream UDR access is failing.\n\nNo Confidentiality impact (the response is `500` with empty body). No persistent Integrity impact (the panic happens before any state mutation). Availability impact is limited to per-request degradation and only fires while UDR access is independently broken; the attacker does not directly control that precondition, so AC:H is the honest assessment.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/925\nUpstream fix: https://github.com/free5gc/nef/pull/22",
  "id": "GHSA-j59f-x285-69jx",
  "modified": "2026-06-08T23:47:23Z",
  "published": "2026-05-08T22:50:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-j59f-x285-69jx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44322"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/issues/925"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nef/pull/22"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nef/commit/72a47f3fab4dffbd227f8d92c5f69dca93b610cb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/free5gc"
    }
  ],
  "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": "free5GC\u0027s NEF 3gpp-pfd-management PATCH applications/{appId} panics on UDR access failure due to nil ProblemDetails dereference"
}

GHSA-J59Q-58W9-M522

Vulnerability from github – Published: 2022-01-15 00:01 – Updated: 2022-01-22 00:02
VLAI
Details

ROPium v3.1 was discovered to contain an invalid memory address dereference via the find() function.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-45761"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-14T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "ROPium v3.1 was discovered to contain an invalid memory address dereference via the find() function.",
  "id": "GHSA-j59q-58w9-m522",
  "modified": "2022-01-22T00:02:09Z",
  "published": "2022-01-15T00:01:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45761"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Boyan-MILANOV/ropium/issues/32"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-J5GM-GF6P-7HPM

Vulnerability from github – Published: 2024-08-08 09:30 – Updated: 2024-09-06 15:32
VLAI
Details

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

tpm: Use auth only after NULL check in tpm_buf_check_hmac_response()

Dereference auth after NULL check in tpm_buf_check_hmac_response(). Otherwise, unless tpm2_sessions_init() was called, a call can cause NULL dereference, when TCG_TPM2_HMAC is enabled.

[jarkko: adjusted the commit message.]

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-42255"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-08T09:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Use auth only after NULL check in tpm_buf_check_hmac_response()\n\nDereference auth after NULL check in tpm_buf_check_hmac_response().\nOtherwise, unless tpm2_sessions_init() was called, a call can cause NULL\ndereference, when TCG_TPM2_HMAC is enabled.\n\n[jarkko: adjusted the commit message.]",
  "id": "GHSA-j5gm-gf6p-7hpm",
  "modified": "2024-09-06T15:32:56Z",
  "published": "2024-08-08T09:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42255"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7dc357d343f134bf59815ff6098b93503ec8a23b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b9afbb9a0c734197c59c43610071041044bf1562"
    }
  ],
  "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-J5GX-C23H-6W7F

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

RedisGraph 2.x through 2.2.11 has a NULL Pointer Dereference that leads to a server crash because it mishandles an unquoted string, such as an alias that has not yet been introduced.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-35668"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-23T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "RedisGraph 2.x through 2.2.11 has a NULL Pointer Dereference that leads to a server crash because it mishandles an unquoted string, such as an alias that has not yet been introduced.",
  "id": "GHSA-j5gx-c23h-6w7f",
  "modified": "2022-05-24T17:37:16Z",
  "published": "2022-05-24T17:37:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35668"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RedisGraph/RedisGraph/issues/1502"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RedisGraph/RedisGraph/pull/1503"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-J5HC-79CM-3QPW

Vulnerability from github – Published: 2024-04-17 09:30 – Updated: 2024-04-17 09:30
VLAI
Details

The memory allocation function ACPI_ALLOCATE_ZEROED does not guarantee a successful allocation, but the subsequent code directly dereferences the pointer that receives it, which may lead to null pointer dereference.

To fix this issue, a null pointer check should be added. If it is null, return exception code AE_NO_MEMORY.

Severity
5.3 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-24856"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-17T09:15:07Z",
    "severity": "MODERATE"
  },
  "details": "The memory allocation function ACPI_ALLOCATE_ZEROED does not guarantee a\nsuccessful allocation, but the subsequent code directly dereferences the\npointer that receives it, which may lead to null pointer dereference.\n\nTo fix this issue, a null pointer check should be added. If it is null, \nreturn exception code AE_NO_MEMORY.\n\n",
  "id": "GHSA-j5hc-79cm-3qpw",
  "modified": "2024-04-17T09:30:32Z",
  "published": "2024-04-17T09:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24856"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.openanolis.cn/show_bug.cgi?id=8764"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J5HR-7JJV-X3H2

Vulnerability from github – Published: 2022-05-14 03:48 – Updated: 2022-05-14 03:48
VLAI
Details

PoDoFo 0.9.5 does not properly validate memcpy arguments in the PdfMemoryOutputStream::Write function (base/PdfOutputStream.cpp). Remote attackers could leverage this vulnerability to cause a denial-of-service or possibly unspecified other impact via a crafted pdf file.

Severity
7.8 (High)
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-5308"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-09T05:29:00Z",
    "severity": "HIGH"
  },
  "details": "PoDoFo 0.9.5 does not properly validate memcpy arguments in the PdfMemoryOutputStream::Write function (base/PdfOutputStream.cpp). Remote attackers could leverage this vulnerability to cause a denial-of-service or possibly unspecified other impact via a crafted pdf file.",
  "id": "GHSA-j5hr-7jjv-x3h2",
  "modified": "2022-05-14T03:48:14Z",
  "published": "2022-05-14T03:48:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5308"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1532390"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J5J7-J8WM-QV7R

Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-01-13 21:31
VLAI
Details

A null pointer dereference vulnerability in the MsgRegisterEvent() system call of the QNX Neutrino Kernel in QNX SDP 7.1 and 7.0, and QNX OS for Safety 2.2, 2.1 and 2.0 could potentially allow an attacker with local access and code execution abilities, to crash the QNX Neutrino kernel.

Severity
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-8090"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-13T17:15:59Z",
    "severity": "MODERATE"
  },
  "details": "A null pointer dereference vulnerability in\u00a0the MsgRegisterEvent() system call of\u00a0the QNX Neutrino Kernel in QNX SDP 7.1 and 7.0, and QNX OS for Safety 2.2, 2.1 and 2.0 could potentially allow an attacker with local access and code execution abilities, to crash the QNX Neutrino kernel.",
  "id": "GHSA-j5j7-j8wm-qv7r",
  "modified": "2026-01-13T21:31:43Z",
  "published": "2026-01-13T18:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8090"
    },
    {
      "type": "WEB",
      "url": "https://support.blackberry.com/pkb/s/article/141027"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/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.

← Back to the CWE list