Common Weakness Enumeration

CWE-476

Allowed

NULL Pointer Dereference

Abstraction: Base · Status: Stable

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

6310 vulnerabilities reference this CWE, most recent first.

GHSA-2P4Q-Q7J4-Q23G

Vulnerability from github – Published: 2024-09-27 15:30 – Updated: 2025-11-03 21:31
VLAI
Details

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

drm/amd/display: Check BIOS images before it is used

BIOS images may fail to load and null checks are added before they are used.

This fixes 6 NULL_RETURNS issues reported by Coverity.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-46809"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-27T13:15:13Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Check BIOS images before it is used\n\nBIOS images may fail to load and null checks are added before they are\nused.\n\nThis fixes 6 NULL_RETURNS issues reported by Coverity.",
  "id": "GHSA-2p4q-q7j4-q23g",
  "modified": "2025-11-03T21:31:13Z",
  "published": "2024-09-27T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46809"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4fcd903a5d9e897420d7d8b3ca55c6e5dbb47379"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8b0ddf19cca2a352b2a7e01d99d3ba949a99c84c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c5cb98554c4c6265b494d040c1c62f1db2fa28a6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e46b70a7cfed71cb84e985c785c39c16df5c28cb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e50bec62acaeec03afc6fa5dfb2426e52d049cf5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/eef7301e674438913134539e77dd887960949f20"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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-2P59-XC6P-6W7C

Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-06-28 09:31
VLAI
Details

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

ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams

snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic.

Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-53242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T09:16:42Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams\n\nsnd_pcm_drain() uses init_waitqueue_entry which does not clear\nentry.prev/next, and add_wait_queue with a conditional\nremove_wait_queue that is skipped when to_check is no longer\nin the group after concurrent UNLINK.  The orphaned wait entry\nremains on the unlinked substream sleep queue.  On the next\ndrain iteration, add_wait_queue adds the entry to a new queue\nwhile still linked on the old one, corrupting both lists.  A\nsubsequent wake_up dereferences NULL at the func pointer\n(mapped from the spinlock at offset 0 of the misinterpreted\nwait_queue_head_t), causing a kernel panic.\n\nReplace init_waitqueue_entry/add_wait_queue/conditional\nremove_wait_queue with init_wait_entry/prepare_to_wait/\nfinish_wait.  init_wait_entry clears prev/next via\nINIT_LIST_HEAD on each iteration and sets\nautoremove_wake_function which auto-removes the entry on\nwake-up.  finish_wait safely handles both the already-removed\nand still-queued cases.",
  "id": "GHSA-2p59-xc6p-6w7c",
  "modified": "2026-06-28T09:31:46Z",
  "published": "2026-06-25T09:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53242"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7c71a9522555ff137a9ca36b15d759ca04d84788"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/88fe2e3658726cb21ff2dcf9770bf672f9b9d31b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b053fcd8912f06c30f932f5b8ec41c72de474695"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cac5bf3500ee6422cf64e0df0b5daeecfed42917"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cd98837db15f323463b8df07282ac723bd5c3fed"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d68b621bb5a48051932f1017a6e1bc9b18f854d0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d842f26a167e77a36f3ed333b9fa99d36ef99fe6"
    }
  ],
  "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-2P5H-HPJ4-FXGG

Vulnerability from github – Published: 2022-09-14 00:00 – Updated: 2022-09-20 22:06
VLAI
Summary
LIEF contains a segmentation violation
Details

LIEF commit 365a16a was discovered to contain a segmentation violation via the component CoreFile.tcc:69. A patch is available at commit ca938740264f1fcb18f91cba8e4039c518ecb75b.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lief"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-38497"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-20T22:05:34Z",
    "nvd_published_at": "2022-09-13T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "LIEF commit 365a16a was discovered to contain a segmentation violation via the component `CoreFile.tcc:69`. A patch is available at commit ca938740264f1fcb18f91cba8e4039c518ecb75b.",
  "id": "GHSA-2p5h-hpj4-fxgg",
  "modified": "2022-09-20T22:06:57Z",
  "published": "2022-09-14T00:00:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38497"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lief-project/LIEF/issues/766"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lief-project/LIEF/commit/ca938740264f1fcb18f91cba8e4039c518ecb75b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lief-project/LIEF"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/lief/PYSEC-2022-277.yaml"
    }
  ],
  "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"
    }
  ],
  "summary": "LIEF contains a segmentation violation"
}

GHSA-2P73-743M-M4R5

Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-02-05 18:30
VLAI
Details

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

drbd: only clone bio if we have a backing device

Commit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a bio_set_dev call (which has since been removed) to "earlier", from drbd_request_prepare to drbd_req_new.

The problem is that this accesses device->ldev->backing_bdev, which is not NULL-checked at this point. When we don't have an ldev (i.e. when the DRBD device is diskless), this leads to a null pointer deref.

So, only allocate the private_bio if we actually have a disk. This is also a small optimization, since we don't clone the bio to only to immediately free it again in the diskless case.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50506"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-04T16:15:47Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrbd: only clone bio if we have a backing device\n\nCommit c347a787e34cb (drbd: set -\u003ebi_bdev in drbd_req_new) moved a\nbio_set_dev call (which has since been removed) to \"earlier\", from\ndrbd_request_prepare to drbd_req_new.\n\nThe problem is that this accesses device-\u003eldev-\u003ebacking_bdev, which is\nnot NULL-checked at this point. When we don\u0027t have an ldev (i.e. when\nthe DRBD device is diskless), this leads to a null pointer deref.\n\nSo, only allocate the private_bio if we actually have a disk. This is\nalso a small optimization, since we don\u0027t clone the bio to only to\nimmediately free it again in the diskless case.",
  "id": "GHSA-2p73-743m-m4r5",
  "modified": "2026-02-05T18:30:28Z",
  "published": "2025-10-04T18:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50506"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/05580a3bbf3cec677cb00a85dfeb21d6a9b48eaf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6d42ddf7f27b6723549ee6d4c8b1b418b59bf6b5"
    }
  ],
  "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-2PCW-FG2M-836W

Vulnerability from github – Published: 2025-04-08 09:31 – Updated: 2026-07-14 15:31
VLAI
Details

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

mm/migrate: fix shmem xarray update during migration

A shmem folio can be either in page cache or in swap cache, but not at the same time. Namely, once it is in swap cache, folio->mapping should be NULL, and the folio is no longer in a shmem mapping.

In __folio_migrate_mapping(), to determine the number of xarray entries to update, folio_test_swapbacked() is used, but that conflates shmem in page cache case and shmem in swap cache case. It leads to xarray multi-index entry corruption, since it turns a sibling entry to a normal entry during xas_store() (see [1] for a userspace reproduction). Fix it by only using folio_test_swapcache() to determine whether xarray is storing swap cache entries or not to choose the right number of xarray entries to update.

[1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/

Note: In __split_huge_page(), folio_test_anon() && folio_test_swapcache() is used to get swap_cache address space, but that ignores the shmem folio in swap cache case. It could lead to NULL pointer dereferencing when a in-swap-cache shmem folio is split at __xa_store(), since !folio_test_anon() is true and folio->mapping is NULL. But fortunately, its caller split_huge_page_to_list_to_order() bails out early with EBUSY when folio->mapping is NULL. So no need to take care of it here.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-22015"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-08T09:15:26Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/migrate: fix shmem xarray update during migration\n\nA shmem folio can be either in page cache or in swap cache, but not at the\nsame time.  Namely, once it is in swap cache, folio-\u003emapping should be\nNULL, and the folio is no longer in a shmem mapping.\n\nIn __folio_migrate_mapping(), to determine the number of xarray entries to\nupdate, folio_test_swapbacked() is used, but that conflates shmem in page\ncache case and shmem in swap cache case.  It leads to xarray multi-index\nentry corruption, since it turns a sibling entry to a normal entry during\nxas_store() (see [1] for a userspace reproduction).  Fix it by only using\nfolio_test_swapcache() to determine whether xarray is storing swap cache\nentries or not to choose the right number of xarray entries to update.\n\n[1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/\n\nNote:\nIn __split_huge_page(), folio_test_anon() \u0026\u0026 folio_test_swapcache() is\nused to get swap_cache address space, but that ignores the shmem folio in\nswap cache case.  It could lead to NULL pointer dereferencing when a\nin-swap-cache shmem folio is split at __xa_store(), since\n!folio_test_anon() is true and folio-\u003emapping is NULL.  But fortunately,\nits caller split_huge_page_to_list_to_order() bails out early with EBUSY\nwhen folio-\u003emapping is NULL.  So no need to take care of it here.",
  "id": "GHSA-2pcw-fg2m-836w",
  "modified": "2026-07-14T15:31:20Z",
  "published": "2025-04-08T09:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22015"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/29124ae980e2860f0eec7355949d3d3292ee81da"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/49100c0b070e900f87c8fac3be9b9ef8a30fa673"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/60cf233b585cdf1f3c5e52d1225606b86acd08b0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/75cfb92eb63298d717b6b0118f91ba12c4fcfeb5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c057ee03f751d6cecf7ee64f52f6545d94082aaa"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-2PHP-7PRQ-766P

Vulnerability from github – Published: 2022-02-12 00:00 – Updated: 2023-08-17 15:30
VLAI
Details

A Null Pointer Dereference vulnerability exits in ffjpeg d5cfd49 (2021-12-06) in bmp_load(). When the size information in metadata of the bmp is out of range, it returns without assign memory buffer to pb->pdata and did not exit the program. So the program crashes when it tries to access the pb->data, in jfif_encode() at jfif.c:763. This is due to the incomplete patch for CVE-2020-13438.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-45385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-11T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A Null Pointer Dereference vulnerability exits in ffjpeg d5cfd49 (2021-12-06) in bmp_load(). When the size information in metadata of the bmp is out of range, it returns without assign memory buffer to `pb-\u003epdata` and did not exit the program. So the program crashes when it tries to access the pb-\u003edata, in jfif_encode() at jfif.c:763. This is due to the incomplete patch for CVE-2020-13438.",
  "id": "GHSA-2php-7prq-766p",
  "modified": "2023-08-17T15:30:19Z",
  "published": "2022-02-12T00:00:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45385"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rockcarry/ffjpeg/issues/47"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rockcarry/ffjpeg/pull/48"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2PJX-4J7G-WF3F

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

A NULL pointer access issue was discovered in Asterisk 15.x through 15.2.1. The RTP support in Asterisk maintains its own registry of dynamic codecs and desired payload numbers. While an SDP negotiation may result in a codec using a different payload number, these desired ones are still stored internally. When an RTP packet was received, this registry would be consulted if the payload number was not found in the negotiated SDP. This registry was incorrectly consulted for all packets, even those which are dynamic. If the payload number resulted in a codec of a different type than the RTP stream (for example, the payload number resulted in a video codec but the stream carried audio), a crash could occur if no stream of that type had been negotiated. This was due to the code incorrectly assuming that a stream of that type would always exist.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-7285"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-02-22T00:29:00Z",
    "severity": "HIGH"
  },
  "details": "A NULL pointer access issue was discovered in Asterisk 15.x through 15.2.1. The RTP support in Asterisk maintains its own registry of dynamic codecs and desired payload numbers. While an SDP negotiation may result in a codec using a different payload number, these desired ones are still stored internally. When an RTP packet was received, this registry would be consulted if the payload number was not found in the negotiated SDP. This registry was incorrectly consulted for all packets, even those which are dynamic. If the payload number resulted in a codec of a different type than the RTP stream (for example, the payload number resulted in a video codec but the stream carried audio), a crash could occur if no stream of that type had been negotiated. This was due to the code incorrectly assuming that a stream of that type would always exist.",
  "id": "GHSA-2pjx-4j7g-wf3f",
  "modified": "2022-05-14T03:36:28Z",
  "published": "2022-05-14T03:36:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7285"
    },
    {
      "type": "WEB",
      "url": "http://downloads.asterisk.org/pub/security/AST-2018-001.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/103149"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1040415"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2PP7-RWQG-2GCX

Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2024-12-30 21:30
VLAI
Details

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

usb: dwc2: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-47409"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T15:15:26Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc2: check return value after calling platform_get_resource()\n\nIt will cause null-ptr-deref if platform_get_resource() returns NULL,\nwe need check the return value.",
  "id": "GHSA-2pp7-rwqg-2gcx",
  "modified": "2024-12-30T21:30:46Z",
  "published": "2024-05-21T15:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47409"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2754fa3b73df7d0ae042f3ed6cfd9df9042f6262"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/337f00a0bc62d7cb7d10ec0b872c79009a1641df"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4b7f4a0eb92bf37bea4cd838c7f83ea42823ca8b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/856e6e8e0f9300befa87dde09edb578555c99a82"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8b9c1c33e51d0959f2aec573dfbac0ffd3f5c0b7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a7182993dd8e09f96839ddc3ac54f9b37370d282"
    }
  ],
  "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-2PPH-66PX-9X3W

Vulnerability from github – Published: 2025-08-22 18:31 – Updated: 2025-11-26 18:30
VLAI
Details

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

media: ti: j721e-csi2rx: fix list_del corruption

If ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is marked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue. This causes the same buffer to be retried in the next iteration, resulting in a double list_del() and eventual list corruption.

Fix this by removing the buffer from the queue before calling vb2_buffer_done() on error.

This resolves a crash due to list_del corruption: [ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA [ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048 [ 37.839761] list_del corruption. next->prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428) [ 37.850799] ------------[ cut here ]------------ [ 37.855424] kernel BUG at lib/list_debug.c:65! [ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul [ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY [ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT) [ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.914059] sp : ffff800080003db0 [ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000 [ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122 [ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0 [ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a [ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720 [ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea [ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568 [ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff [ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000 [ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d [ 37.988832] Call trace: [ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P) [ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4 [ 38.001419] udma_vchan_complete+0x1e0/0x344 [ 38.005705] tasklet_action_common+0x118/0x310 [ 38.010163] tasklet_action+0x30/0x3c [ 38.013832] handle_softirqs+0x10c/0x2e0 [ 38.017761] __do_softirq+0x14/0x20 [ 38.021256] _dosoftirq+0x10/0x20 [ 38.024931] call_on_irq_stack+0x24/0x60 [ 38.028873] do_softirq_own_stack+0x1c/0x40 [ 38.033064] irq_exit_rcu+0x130/0x15c [ 38.036909] irq_exit_rcu+0x10/0x20 [ 38.040403] el1_interrupt+0x38/0x60 [ 38.043987] el1h_64_irq_handler+0x18/0x24 [ 38.048091] el1h_64_irq+0x6c/0x70 [ 38.051501] default_idle_call+0x34/0xe0 (P) [ 38.055783] do_idle+0x1f8/0x250 [ 38.059021] cpu_startup_entry+0x34/0x3c [ 38.062951] rest_init+0xb4/0xc0 [ 38.066186] console_on_rootfs+0x0/0x6c [ 38.070031] __primary_switched+0x88/0x90 [ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000) [ 38.080168] ---[ end trace 0000000000000000 ]--- [ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt [ 38.092197] SMP: stopping secondary CPUs [ 38.096139] Kernel Offset: disabled [ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b [ 38.105202] Memory Limit: none [ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-38619"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-22T16:15:35Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ti: j721e-csi2rx: fix list_del corruption\n\nIf ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is\nmarked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue.\nThis causes the same buffer to be retried in the next iteration, resulting\nin a double list_del() and eventual list corruption.\n\nFix this by removing the buffer from the queue before calling\nvb2_buffer_done() on error.\n\nThis resolves a crash due to list_del corruption:\n[   37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA\n[   37.832187]  slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048\n[   37.839761] list_del corruption. next-\u003eprev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428)\n[   37.850799] ------------[ cut here ]------------\n[   37.855424] kernel BUG at lib/list_debug.c:65!\n[   37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP\n[   37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul\n[   37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY\n[   37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT)\n[   37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114\n[   37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114\n[   37.914059] sp : ffff800080003db0\n[   37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000\n[   37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122\n[   37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0\n[   37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a\n[   37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720\n[   37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea\n[   37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568\n[   37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff\n[   37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000\n[   37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d\n[   37.988832] Call trace:\n[   37.991281]  __list_del_entry_valid_or_report+0xdc/0x114 (P)\n[   37.996959]  ti_csi2rx_dma_callback+0x84/0x1c4\n[   38.001419]  udma_vchan_complete+0x1e0/0x344\n[   38.005705]  tasklet_action_common+0x118/0x310\n[   38.010163]  tasklet_action+0x30/0x3c\n[   38.013832]  handle_softirqs+0x10c/0x2e0\n[   38.017761]  __do_softirq+0x14/0x20\n[   38.021256]  ____do_softirq+0x10/0x20\n[   38.024931]  call_on_irq_stack+0x24/0x60\n[   38.028873]  do_softirq_own_stack+0x1c/0x40\n[   38.033064]  __irq_exit_rcu+0x130/0x15c\n[   38.036909]  irq_exit_rcu+0x10/0x20\n[   38.040403]  el1_interrupt+0x38/0x60\n[   38.043987]  el1h_64_irq_handler+0x18/0x24\n[   38.048091]  el1h_64_irq+0x6c/0x70\n[   38.051501]  default_idle_call+0x34/0xe0 (P)\n[   38.055783]  do_idle+0x1f8/0x250\n[   38.059021]  cpu_startup_entry+0x34/0x3c\n[   38.062951]  rest_init+0xb4/0xc0\n[   38.066186]  console_on_rootfs+0x0/0x6c\n[   38.070031]  __primary_switched+0x88/0x90\n[   38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000)\n[   38.080168] ---[ end trace 0000000000000000 ]---\n[   38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt\n[   38.092197] SMP: stopping secondary CPUs\n[   38.096139] Kernel Offset: disabled\n[   38.099631] CPU features: 0x0000,00002000,02000801,0400420b\n[   38.105202] Memory Limit: none\n[   38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---",
  "id": "GHSA-2pph-66px-9x3w",
  "modified": "2025-11-26T18:30:59Z",
  "published": "2025-08-22T18:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38619"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/68e5579f4de12207b23c41b44a4c0778b6c2858f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/92d0188f36ca8082af7989d743eb5b44c2d259f7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a4a8cb0889927d59ebd839458c8f038bc5298ef9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ae42c6fe531425ef2f47e82f96851427d24bbf6b"
    }
  ],
  "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-2PPM-VR48-8V34

Vulnerability from github – Published: 2024-10-08 18:33 – Updated: 2024-10-08 18:33
VLAI
Details

Windows Mobile Broadband Driver Denial of Service Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-43559"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-08T18:15:22Z",
    "severity": "MODERATE"
  },
  "details": "Windows Mobile Broadband Driver Denial of Service Vulnerability",
  "id": "GHSA-2ppm-vr48-8v34",
  "modified": "2024-10-08T18:33:16Z",
  "published": "2024-10-08T18:33:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43559"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43559"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/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.