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.

6768 vulnerabilities reference this CWE, most recent first.

GHSA-MJR6-MGJJ-R5P7

Vulnerability from github – Published: 2022-09-03 00:00 – Updated: 2022-09-09 00:00
VLAI
Details

A null pointer dereference may potentially occur during RSA key import in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-35135"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-02T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A null pointer dereference may potentially occur during RSA key import in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice \u0026 Music, Snapdragon Wearables",
  "id": "GHSA-mjr6-mgjj-r5p7",
  "modified": "2022-09-09T00:00:57Z",
  "published": "2022-09-03T00:00:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35135"
    },
    {
      "type": "WEB",
      "url": "https://www.qualcomm.com/company/product-security/bulletins/july-2022-bulletin"
    }
  ],
  "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-MM2V-M6VC-RHF4

Vulnerability from github – Published: 2024-09-18 09:30 – Updated: 2024-11-20 18:32
VLAI
Details

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

hwmon: (hp-wmi-sensors) Check if WMI event data exists

The BIOS can choose to return no event data in response to a WMI event, so the ACPI object passed to the WMI notify handler can be NULL.

Check for such a situation and ignore the event in such a case.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-46768"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-18T08:15:04Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (hp-wmi-sensors) Check if WMI event data exists\n\nThe BIOS can choose to return no event data in response to a\nWMI event, so the ACPI object passed to the WMI notify handler\ncan be NULL.\n\nCheck for such a situation and ignore the event in such a case.",
  "id": "GHSA-mm2v-m6vc-rhf4",
  "modified": "2024-11-20T18:32:15Z",
  "published": "2024-09-18T09:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46768"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/217539e994e53206bbf3fb330261cc78c480d311"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4b19c83ba108aa66226da5b79810e4d19e005f12"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a54da9df75cd1b4b5028f6c60f9a211532680585"
    }
  ],
  "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-MM2W-55V7-4V2M

Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2024-06-03 18:55
VLAI
Details

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

net: wangxun: fix kernel panic due to null pointer

When the device uses a custom subsystem vendor ID, the function wx_sw_init() returns before the memory of 'wx->mac_table' is allocated. The null pointer will causes the kernel panic.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-52783"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T16:15:17Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wangxun: fix kernel panic due to null pointer\n\nWhen the device uses a custom subsystem vendor ID, the function\nwx_sw_init() returns before the memory of \u0027wx-\u003emac_table\u0027 is allocated.\nThe null pointer will causes the kernel panic.",
  "id": "GHSA-mm2w-55v7-4v2m",
  "modified": "2024-06-03T18:55:26Z",
  "published": "2024-05-21T18:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52783"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/61a55071653974dab172d4c5d699bb365cfd13c9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8ba2c459668cfe2aaacc5ebcd35b4b9ef8643013"
    }
  ],
  "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-MM34-XR6Q-46QF

Vulnerability from github – Published: 2024-09-25 18:31 – Updated: 2024-09-25 18:31
VLAI
Details

A vulnerability in the HTTP Server feature of Cisco IOS XE Software when the Telephony Service feature is enabled could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.

This vulnerability is due to a null pointer dereference when accessing specific URLs. An attacker could exploit this vulnerability by sending crafted HTTP traffic to an affected device. A successful exploit could allow the attacker to cause the affected device to reload, causing a DoS condition on the affected device.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-20436"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-25T17:15:16Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the HTTP Server feature of Cisco IOS XE Software when the Telephony Service feature is enabled could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.\n\n This vulnerability is due to a null pointer dereference when accessing specific URLs. An attacker could exploit this vulnerability by sending crafted HTTP traffic to an affected device. A successful exploit could allow the attacker to cause the affected device to reload, causing a DoS condition on the affected device.",
  "id": "GHSA-mm34-xr6q-46qf",
  "modified": "2024-09-25T18:31:20Z",
  "published": "2024-09-25T18:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20436"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-httpsrvr-dos-yOZThut"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MMFR-PMJX-HW9W

Vulnerability from github – Published: 2026-08-21 20:55 – Updated: 2026-08-21 20:55
VLAI
Summary
kin-openapi openai3filter: nil-pointer panic in ConvertErrors on malformed multipart/form-data body enables unauthenticated DoS
Details

Summary

A nil-pointer dereference in openapi3filter.ConvertErrors lets any unauthenticated client crash a server with a single HTTP request. When an application validates a multipart/form-data request body and renders the resulting validation error through the library-provided ValidationErrorEncoder / ConvertErrors helpers, a malformed scalar form field (e.g. a non-numeric value for an integer property) produces an error shape that convertParseError dereferences without a nil check. The handler goroutine panics, causing a denial of service. application/json request bodies are not affected — the bug is specific to multipart/form-data.

Details

The panic is in convertParseError, at openapi3filter/validation_error_encoder.go:119-120 (still present on master at the time of writing):

} else if innerErr.RootCause() != nil {
    if rootErr, ok := innerErr.Cause.(*ParseError); ok &&
        rootErr.Kind == KindInvalidFormat && e.Parameter.In == "query" {   // ❌ e.Parameter may be nil → panic

The comparison e.Parameter.In == "query" assumes e.Parameter is non-nil. It is reached whenever both of the following hold:

  1. e.Parameter == nil. A *RequestError carries either Parameter (parameter errors) or RequestBody (body errors), never both. ValidateRequestBody builds body errors with only RequestBody set, leaving Parameter nil — see validate_request.go:326-332.
  2. innerErr.Cause is itself a *ParseError (a ParseError nested inside a ParseError), so the type assertion on line 119 succeeds and execution reaches the e.Parameter.In dereference on line 120.

The only default code path that satisfies both conditions is the multipart body decoder, which wraps a failed part's *ParseError inside another *ParseError at req_resp_decoder.go:1549 and :1558:

if v, ok := err.(*ParseError); ok {
    return nil, &ParseError{path: []any{name}, Cause: v}   // v is a *ParseError → nested
}

Why other paths do not reach the dereference:

Body content type Failure mode RequestError.Err shape .Cause is *ParseError? e.Parameter Panics?
multipart/form-data scalar part fails primitive parse (age=notanumber) *ParseError wrapping a *ParseError yes nil YES
application/json malformed JSON syntax *ParseError whose .Cause is an encoding/json error no (assertion fails → safe fallback branch) nil no
application/json wrong type / schema violation *openapi3.SchemaError (routed to convertSchemaError, never reaches convertParseError) n/a nil no
styled query / path params invalid format *ParseError wrapping a *ParseError yes set (non-nil) no (guard/assignment succeeds)

Note that the sibling "path" branch two lines above (line 108) already guards correctly with e.Parameter != nil; the "query" branch simply omits the same guard.

Recommended fix. Add the missing nil guard to the condition:

        if rootErr, ok := innerErr.Cause.(*ParseError); ok &&
-           rootErr.Kind == KindInvalidFormat && e.Parameter.In == "query" {
+           rootErr.Kind == KindInvalidFormat && e.Parameter != nil && e.Parameter.In == "query" {

When e.Parameter == nil the inner if is skipped and control falls through to the existing return &ValidationError{Status: http.StatusBadRequest, Title: innerErr.Reason} at line 127-130 — a correct 400 Bad Request. I verified that applying only this one-line guard stops the panic and returns *ValidationError{Status: 400}.

Minor follow-up worth including in the same change: for the multipart nested *ParseError, the outer ParseError.Reason is empty, so the fallback Title: innerErr.Reason yields a 400 with an empty Title. The descriptive text lives in innerErr.Error() (e.g. "path age: value notanumber: an invalid integer: invalid syntax"). Prefer a non-empty fallback:

title := innerErr.Reason
if title == "" {
    title = innerErr.Error()
}
return &ValidationError{Status: http.StatusBadRequest, Title: title}

PoC

Verified against revision 98d956447b64eaa10d3570a80b3be1a2849945f1 (also reproducible on current master), Go 1.25.0.

1. Spec — one operation accepting a multipart/form-data body with a non-string scalar (integer) property:

openapi: '3.0.3'
info: {title: t, version: '1.0.0'}
paths:
  /upload:
    post:
      requestBody:
        required: true
        content:
          multipart/form-data:
            schema:
              type: object
              properties:
                age: {type: integer}
      responses:
        '200': {description: ok}

2. Program — validate a request whose age part is non-numeric, then convert the error the way a typical error-rendering middleware does:

package main

import (
    "bytes"
    "context"
    "fmt"
    "mime/multipart"
    "net/http"

    "github.com/getkin/kin-openapi/openapi3"
    "github.com/getkin/kin-openapi/openapi3filter"
    "github.com/getkin/kin-openapi/routers/gorillamux"
)

const spec = `
openapi: '3.0.3'
info: {title: t, version: '1.0.0'}
paths:
  /upload:
    post:
      requestBody:
        required: true
        content:
          multipart/form-data:
            schema:
              type: object
              properties:
                age: {type: integer}
      responses:
        '200': {description: ok}
`

func main() {
    loader := openapi3.NewLoader()
    doc, _ := loader.LoadFromData([]byte(spec))
    _ = doc.Validate(loader.Context)
    router, _ := gorillamux.NewRouter(doc)

    // multipart body: a non-numeric value for the integer property "age"
    var buf bytes.Buffer
    w := multipart.NewWriter(&buf)
    _ = w.WriteField("age", "notanumber")
    w.Close()

    r, _ := http.NewRequest(http.MethodPost, "/upload", &buf)
    r.Header.Set("Content-Type", w.FormDataContentType())
    route, pp, _ := router.FindRoute(r)

    reqErr := openapi3filter.ValidateRequest(context.Background(), &openapi3filter.RequestValidationInput{
        Request: r, PathParams: pp, Route: route,
        Options: &openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},
    })
    fmt.Printf("ValidateRequest returned: %T\n", reqErr) // *openapi3filter.RequestError

    // What an application's error-rendering middleware calls:
    _ = openapi3filter.ConvertErrors(reqErr) // panics
    fmt.Println("no panic (unexpected)")
}

3. Observed output (go run .):

ValidateRequest returned: *openapi3filter.RequestError
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x...]

goroutine 1 [running]:
github.com/getkin/kin-openapi/openapi3filter.convertParseError(...)
    .../openapi3filter/validation_error_encoder.go:120 +0x17c
github.com/getkin/kin-openapi/openapi3filter.ConvertErrors(...)
    .../openapi3filter/validation_error_encoder.go:42 +0xec
main.main()
    ...
exit status 2

The panic is at exactly validation_error_encoder.go:120 — the unguarded e.Parameter.In dereference.

Control (confirms JSON is not a vector): repeating the setup with an application/json body and either a malformed body ({"age":) or a wrong-type body ({"age": "notanumber"}) returns from ConvertErrors normally, with no panic. Only the multipart/form-data path crashes.

In a real HTTP server, ConvertErrors / ValidationErrorEncoder.Encode runs inside the request handler, so the panic aborts the in-flight request (connection reset / 500) and, without a recover() in the middleware chain, is trivially repeatable.

Impact

  • Type: Nil-pointer dereference → unauthenticated remote denial of service.
  • Who is impacted: any application using github.com/getkin/kin-openapi/openapi3filter that (1) exposes an endpoint accepting a multipart/form-data request body with at least one non-string scalar property (integer / number / boolean), and (2) renders validation errors through the library's own ValidationErrorEncoder or ConvertErrors helpers. These are the library's advertised error-rendering helpers, so this is a realistic default integration.
  • Attack: a single crafted, unauthenticated request (a multipart part whose value doesn't parse to the declared scalar type). No credentials, special privileges, or unusual client capabilities are required, and it is repeatable at will.
  • Consequence: the handling goroutine panics. Absent a recover() boundary in the application's middleware, the request is aborted; sustained requests deny service. Confidentiality and integrity are not affected.
  • Not affected: applications that only accept application/json bodies (verified above), applications that do not use ConvertErrors / ValidationErrorEncoder to format errors, or applications that wrap handlers in a recover() (which converts the crash into a handled 500 but still prevents normal error rendering).
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/getkin/kin-openapi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.0"
            },
            {
              "fixed": "0.141.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-76905"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-21T20:55:46Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA nil-pointer dereference in `openapi3filter.ConvertErrors` lets any unauthenticated client crash a server with a single HTTP request. When an application validates a `multipart/form-data` request body and renders the resulting validation error through the library-provided `ValidationErrorEncoder` / `ConvertErrors` helpers, a malformed scalar form field (e.g. a non-numeric value for an `integer` property) produces an error shape that `convertParseError` dereferences without a nil check. The handler goroutine panics, causing a denial of service. `application/json` request bodies are **not** affected \u2014 the bug is specific to `multipart/form-data`.\n\n### Details\n\nThe panic is in `convertParseError`, at [`openapi3filter/validation_error_encoder.go:119-120`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/validation_error_encoder.go#L119) (still present on `master` at the time of writing):\n\n```go\n} else if innerErr.RootCause() != nil {\n    if rootErr, ok := innerErr.Cause.(*ParseError); ok \u0026\u0026\n        rootErr.Kind == KindInvalidFormat \u0026\u0026 e.Parameter.In == \"query\" {   // \u274c e.Parameter may be nil \u2192 panic\n```\n\nThe comparison `e.Parameter.In == \"query\"` assumes `e.Parameter` is non-nil. It is reached whenever **both** of the following hold:\n\n1. **`e.Parameter == nil`.** A `*RequestError` carries *either* `Parameter` (parameter errors) *or* `RequestBody` (body errors), never both. `ValidateRequestBody` builds body errors with only `RequestBody` set, leaving `Parameter` nil \u2014 see [`validate_request.go:326-332`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/validate_request.go#L326).\n2. **`innerErr.Cause` is itself a `*ParseError`** (a `ParseError` nested inside a `ParseError`), so the type assertion on line 119 succeeds and execution reaches the `e.Parameter.In` dereference on line 120.\n\nThe only default code path that satisfies *both* conditions is the **multipart** body decoder, which wraps a failed part\u0027s `*ParseError` inside another `*ParseError` at [`req_resp_decoder.go:1549`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L1549) and [`:1558`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L1558):\n\n```go\nif v, ok := err.(*ParseError); ok {\n    return nil, \u0026ParseError{path: []any{name}, Cause: v}   // v is a *ParseError \u2192 nested\n}\n```\n\nWhy other paths do **not** reach the dereference:\n\n| Body content type | Failure mode | `RequestError.Err` shape | `.Cause` is `*ParseError`? | `e.Parameter` | Panics? |\n|---|---|---|---|---|---|\n| **`multipart/form-data`** | scalar part fails primitive parse (`age=notanumber`) | `*ParseError` wrapping a `*ParseError` | **yes** | `nil` | **YES** |\n| `application/json` | malformed JSON syntax | `*ParseError` whose `.Cause` is an `encoding/json` error | no (assertion fails \u2192 safe fallback branch) | `nil` | no |\n| `application/json` | wrong type / schema violation | `*openapi3.SchemaError` (routed to `convertSchemaError`, never reaches `convertParseError`) | n/a | `nil` | no |\n| styled `query` / `path` params | invalid format | `*ParseError` wrapping a `*ParseError` | yes | **set (non-nil)** | no (guard/assignment succeeds) |\n\nNote that the sibling `\"path\"` branch two lines above ([line 108](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/validation_error_encoder.go#L108)) already guards correctly with `e.Parameter != nil`; the `\"query\"` branch simply omits the same guard.\n\n**Recommended fix.** Add the missing nil guard to the condition:\n\n```diff\n \t\tif rootErr, ok := innerErr.Cause.(*ParseError); ok \u0026\u0026\n-\t\t\trootErr.Kind == KindInvalidFormat \u0026\u0026 e.Parameter.In == \"query\" {\n+\t\t\trootErr.Kind == KindInvalidFormat \u0026\u0026 e.Parameter != nil \u0026\u0026 e.Parameter.In == \"query\" {\n```\n\nWhen `e.Parameter == nil` the inner `if` is skipped and control falls through to the existing `return \u0026ValidationError{Status: http.StatusBadRequest, Title: innerErr.Reason}` at [line 127-130](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/validation_error_encoder.go#L127) \u2014 a correct `400 Bad Request`. I verified that applying only this one-line guard stops the panic and returns `*ValidationError{Status: 400}`.\n\nMinor follow-up worth including in the same change: for the multipart nested `*ParseError`, the *outer* `ParseError.Reason` is empty, so the fallback `Title: innerErr.Reason` yields a `400` with an **empty `Title`**. The descriptive text lives in `innerErr.Error()` (e.g. `\"path age: value notanumber: an invalid integer: invalid syntax\"`). Prefer a non-empty fallback:\n\n```go\ntitle := innerErr.Reason\nif title == \"\" {\n    title = innerErr.Error()\n}\nreturn \u0026ValidationError{Status: http.StatusBadRequest, Title: title}\n```\n\n### PoC\n\nVerified against revision `98d956447b64eaa10d3570a80b3be1a2849945f1` (also reproducible on current `master`), Go 1.25.0.\n\n**1. Spec** \u2014 one operation accepting a `multipart/form-data` body with a non-string scalar (`integer`) property:\n\n```yaml\nopenapi: \u00273.0.3\u0027\ninfo: {title: t, version: \u00271.0.0\u0027}\npaths:\n  /upload:\n    post:\n      requestBody:\n        required: true\n        content:\n          multipart/form-data:\n            schema:\n              type: object\n              properties:\n                age: {type: integer}\n      responses:\n        \u0027200\u0027: {description: ok}\n```\n\n**2. Program** \u2014 validate a request whose `age` part is non-numeric, then convert the error the way a typical error-rendering middleware does:\n\n```go\npackage main\n\nimport (\n\t\"bytes\"\n\t\"context\"\n\t\"fmt\"\n\t\"mime/multipart\"\n\t\"net/http\"\n\n\t\"github.com/getkin/kin-openapi/openapi3\"\n\t\"github.com/getkin/kin-openapi/openapi3filter\"\n\t\"github.com/getkin/kin-openapi/routers/gorillamux\"\n)\n\nconst spec = `\nopenapi: \u00273.0.3\u0027\ninfo: {title: t, version: \u00271.0.0\u0027}\npaths:\n  /upload:\n    post:\n      requestBody:\n        required: true\n        content:\n          multipart/form-data:\n            schema:\n              type: object\n              properties:\n                age: {type: integer}\n      responses:\n        \u0027200\u0027: {description: ok}\n`\n\nfunc main() {\n\tloader := openapi3.NewLoader()\n\tdoc, _ := loader.LoadFromData([]byte(spec))\n\t_ = doc.Validate(loader.Context)\n\trouter, _ := gorillamux.NewRouter(doc)\n\n\t// multipart body: a non-numeric value for the integer property \"age\"\n\tvar buf bytes.Buffer\n\tw := multipart.NewWriter(\u0026buf)\n\t_ = w.WriteField(\"age\", \"notanumber\")\n\tw.Close()\n\n\tr, _ := http.NewRequest(http.MethodPost, \"/upload\", \u0026buf)\n\tr.Header.Set(\"Content-Type\", w.FormDataContentType())\n\troute, pp, _ := router.FindRoute(r)\n\n\treqErr := openapi3filter.ValidateRequest(context.Background(), \u0026openapi3filter.RequestValidationInput{\n\t\tRequest: r, PathParams: pp, Route: route,\n\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t})\n\tfmt.Printf(\"ValidateRequest returned: %T\\n\", reqErr) // *openapi3filter.RequestError\n\n\t// What an application\u0027s error-rendering middleware calls:\n\t_ = openapi3filter.ConvertErrors(reqErr) // panics\n\tfmt.Println(\"no panic (unexpected)\")\n}\n```\n\n**3. Observed output** (`go run .`):\n\n```\nValidateRequest returned: *openapi3filter.RequestError\npanic: runtime error: invalid memory address or nil pointer dereference\n[signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x...]\n\ngoroutine 1 [running]:\ngithub.com/getkin/kin-openapi/openapi3filter.convertParseError(...)\n\t.../openapi3filter/validation_error_encoder.go:120 +0x17c\ngithub.com/getkin/kin-openapi/openapi3filter.ConvertErrors(...)\n\t.../openapi3filter/validation_error_encoder.go:42 +0xec\nmain.main()\n\t...\nexit status 2\n```\n\nThe panic is at exactly `validation_error_encoder.go:120` \u2014 the unguarded `e.Parameter.In` dereference.\n\n**Control (confirms JSON is not a vector):** repeating the setup with an `application/json` body and either a malformed body (`{\"age\": `) or a wrong-type body (`{\"age\": \"notanumber\"}`) returns from `ConvertErrors` normally, with no panic. Only the `multipart/form-data` path crashes.\n\nIn a real HTTP server, `ConvertErrors` / `ValidationErrorEncoder.Encode` runs inside the request handler, so the panic aborts the in-flight request (connection reset / 500) and, without a `recover()` in the middleware chain, is trivially repeatable.\n\n### Impact\n\n- **Type:** Nil-pointer dereference \u2192 **unauthenticated remote denial of service**.\n- **Who is impacted:** any application using `github.com/getkin/kin-openapi/openapi3filter` that (1) exposes an endpoint accepting a `multipart/form-data` request body with at least one non-string scalar property (`integer` / `number` / `boolean`), **and** (2) renders validation errors through the library\u0027s own `ValidationErrorEncoder` or `ConvertErrors` helpers. These are the library\u0027s advertised error-rendering helpers, so this is a realistic default integration.\n- **Attack:** a single crafted, unauthenticated request (a multipart part whose value doesn\u0027t parse to the declared scalar type). No credentials, special privileges, or unusual client capabilities are required, and it is repeatable at will.\n- **Consequence:** the handling goroutine panics. Absent a `recover()` boundary in the application\u0027s middleware, the request is aborted; sustained requests deny service. Confidentiality and integrity are not affected.\n- **Not affected:** applications that only accept `application/json` bodies (verified above), applications that do not use `ConvertErrors` / `ValidationErrorEncoder` to format errors, or applications that wrap handlers in a `recover()` (which converts the crash into a handled 500 but still prevents normal error rendering).",
  "id": "GHSA-mmfr-pmjx-hw9w",
  "modified": "2026-08-21T20:55:46Z",
  "published": "2026-08-21T20:55:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getkin/kin-openapi/security/advisories/GHSA-mmfr-pmjx-hw9w"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkin/kin-openapi/commit/1d0a337c9b1570fab283be8a04c8af6e43b9a22c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getkin/kin-openapi"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkin/kin-openapi/releases/tag/v0.141.0"
    }
  ],
  "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": "kin-openapi openai3filter: nil-pointer panic in ConvertErrors on malformed multipart/form-data body enables unauthenticated DoS"
}

GHSA-MMJ4-6PPP-MQR2

Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-11-03 21:33
VLAI
Details

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

KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel

Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.

Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC:

dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1

Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-21779"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-27T03:15:18Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Reject Hyper-V\u0027s SEND_IPI hypercalls if local APIC isn\u0027t in-kernel\n\nAdvertise support for Hyper-V\u0027s SEND_IPI and SEND_IPI_EX hypercalls if and\nonly if the local API is emulated/virtualized by KVM, and explicitly reject\nsaid hypercalls if the local APIC is emulated in userspace, i.e. don\u0027t rely\non userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.\n\nRejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if\nHyper-V enlightenments are exposed to the guest without an in-kernel local\nAPIC:\n\n  dump_stack+0xbe/0xfd\n  __kasan_report.cold+0x34/0x84\n  kasan_report+0x3a/0x50\n  __apic_accept_irq+0x3a/0x5c0\n  kvm_hv_send_ipi.isra.0+0x34e/0x820\n  kvm_hv_hypercall+0x8d9/0x9d0\n  kvm_emulate_hypercall+0x506/0x7e0\n  __vmx_handle_exit+0x283/0xb60\n  vmx_handle_exit+0x1d/0xd0\n  vcpu_enter_guest+0x16b0/0x24c0\n  vcpu_run+0xc0/0x550\n  kvm_arch_vcpu_ioctl_run+0x170/0x6d0\n  kvm_vcpu_ioctl+0x413/0xb20\n  __se_sys_ioctl+0x111/0x160\n  do_syscal1_64+0x30/0x40\n  entry_SYSCALL_64_after_hwframe+0x67/0xd1\n\nNote, checking the sending vCPU is sufficient, as the per-VM irqchip_mode\ncan\u0027t be modified after vCPUs are created, i.e. if one vCPU has an\nin-kernel local APIC, then all vCPUs have an in-kernel local APIC.",
  "id": "GHSA-mmj4-6ppp-mqr2",
  "modified": "2025-11-03T21:33:01Z",
  "published": "2025-02-27T03:34:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21779"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/45fa526b0f5a34492ed0536c3cdf88b78380e4de"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5393cf22312418262679eaadb130d608c75fe690"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/61224533f2b61e252b03e214195d27d64b22989a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/874ff13c73c45ecb38cb82191e8c1d523f0dc81b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a8de7f100bb5989d9c3627d3a223ee1c863f3b69"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aca8be4403fb90db7adaf63830e27ebe787a76e8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ca29f58ca374c40a0e69c5306fc5c940a0069074"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MMPX-FX25-F58M

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

samurai 1.2 has a NULL pointer dereference in printstatus() function in build.c via a crafted build file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-30219"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-29T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "samurai 1.2 has a NULL pointer dereference in printstatus() function in build.c via a crafted build file.",
  "id": "GHSA-mmpx-fx25-f58m",
  "modified": "2022-05-24T17:49:07Z",
  "published": "2022-05-24T17:49:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30219"
    },
    {
      "type": "WEB",
      "url": "https://github.com/michaelforney/samurai/issues/68"
    },
    {
      "type": "WEB",
      "url": "https://github.com/michaelforney/samurai/commit/d2af3bc375e2a77139c3a28d6128c60cd8d08655"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-MMQ4-R743-Q9W7

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

An issue was discovered in the Tatsuya Kinoshita w3m fork before 0.5.3-31. w3m allows remote attackers to cause a denial of service (segmentation fault and crash) via a crafted HTML page.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2016-9441"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-12-12T02:59:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in the Tatsuya Kinoshita w3m fork before 0.5.3-31. w3m allows remote attackers to cause a denial of service (segmentation fault and crash) via a crafted HTML page.",
  "id": "GHSA-mmq4-r743-q9w7",
  "modified": "2022-05-17T02:36:43Z",
  "published": "2022-05-17T02:36:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9441"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tats/w3m/issues/24"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tats/w3m/blob/master/ChangeLog"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201701-08"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2016/11/18/3"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/94407"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MMQ9-QVQ7-H3JQ

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

An issue was discovered in Foxit Reader and PhantomPDF before 9.4 on Windows. It is a NULL pointer dereference during PDF parsing.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-5006"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-03T23:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Foxit Reader and PhantomPDF before 9.4 on Windows. It is a NULL pointer dereference during PDF parsing.",
  "id": "GHSA-mmq9-qvq7-h3jq",
  "modified": "2022-05-14T01:41:05Z",
  "published": "2022-05-14T01:41:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5006"
    },
    {
      "type": "WEB",
      "url": "https://www.foxitsoftware.com/support/security-bulletins.php"
    }
  ],
  "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-MMV6-WM63-PPR6

Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-07-07 18:30
VLAI
Details

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

drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs

[Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node.

The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36.

Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data))

(cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-53135"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T09:16:30Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs\n\n[Why \u0026 How]\ndp_sdp_message_debugfs_write() dereferences connector-\u003ebase.state-\u003ecrtc\nwithout checking for NULL. A connector can be connected but not bound to\nany CRTC (e.g. after hot-plug before the next atomic commit), causing a\nkernel crash when writing to the sdp_message debugfs node.\n\nThe function also ignores the user-provided size argument and always\npasses 36 bytes to copy_from_user(), reading past the user buffer when\nsize \u003c 36.\n\nFix both issues by:\n- Returning -ENODEV when connector-\u003ebase.state or state-\u003ecrtc is NULL\n- Clamping write_size to min(size, sizeof(data))\n\n(cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)",
  "id": "GHSA-mmv6-wm63-ppr6",
  "modified": "2026-07-07T18:30:27Z",
  "published": "2026-06-25T09:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53135"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7ae95c0275c330b5dbae806f8e431720edad776f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7fc4fab4acc307ad2903312c195872b2953d32c3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a2de1d71891a038a9346b2c1a72b88c8350f2479"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/adf67034b1f61f7119295208085bfd43f85f56af"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b781f90a9528555c709e59789550893581ef0be4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bb6f705b73b5f191f14ad004e2c8c4b615806187"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c90954cdea4d6998ec345de0d840d030c145b89e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ee9cfcf77a8e8af637396dc00966df5f701e661c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation MIT-56
Implementation

For any pointers that could have been modified or provided from a function that can return NULL, check the pointer for NULL before use. When working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the check, and unlock when it has finished [REF-1484].

Mitigation
Requirements

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

Mitigation
Implementation

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

Mitigation
Architecture and Design

Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.

Mitigation
Implementation

Explicitly initialize all variables and other data stores, either during declaration or just before the first usage.

No CAPEC attack patterns related to this CWE.