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.

6769 vulnerabilities reference this CWE, most recent first.

GHSA-5PX8-3QCF-QPM5

Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-06-05 18:31
VLAI
Details

In GNU SASL before 2.2.3, DIGEST-MD5 has a NULL pointer dereference affecting both clients and servers, via a known token with no accompanying = character. This occurs in lib/digest-md5/getsubopt.c.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-48829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-24T04:16:39Z",
    "severity": "HIGH"
  },
  "details": "In GNU SASL before 2.2.3, DIGEST-MD5 has a NULL pointer dereference affecting both clients and servers, via a known token with no accompanying = character. This occurs in lib/digest-md5/getsubopt.c.",
  "id": "GHSA-5px8-3qcf-qpm5",
  "modified": "2026-06-05T18:31:31Z",
  "published": "2026-05-26T13:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48829"
    },
    {
      "type": "WEB",
      "url": "https://codeberg.org/gsasl/gsasl/commit/da9b5ae2962b014879e4a406c3b38f25aa70e97a"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2026/06/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-security-announce/2026/msg00182.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.gnu.org/archive/html/help-gsasl/2026-05/msg00000.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.gnu.org/archive/html/help-gsasl/2026-05/msg00002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5Q47-P32P-3746

Vulnerability from github – Published: 2024-08-13 18:31 – Updated: 2024-08-13 18:31
VLAI
Details

Windows Layer-2 Bridge Network Driver Denial of Service Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-38146"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-13T18:15:19Z",
    "severity": "HIGH"
  },
  "details": "Windows Layer-2 Bridge Network Driver Denial of Service Vulnerability",
  "id": "GHSA-5q47-p32p-3746",
  "modified": "2024-08-13T18:31:16Z",
  "published": "2024-08-13T18:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38146"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38146"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5Q8G-4P6J-Q2CW

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

An issue was discovered in GNU LibreDWG 0.7 and 0.7.1645. There is a NULL pointer dereference in the function dwg_dxf_LTYPE at dwg.spec (later than CVE-2019-9779).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-9776"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-14T09:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in GNU LibreDWG 0.7 and 0.7.1645. There is a NULL pointer dereference in the function dwg_dxf_LTYPE at dwg.spec (later than CVE-2019-9779).",
  "id": "GHSA-5q8g-4p6j-q2cw",
  "modified": "2022-05-14T01:18:14Z",
  "published": "2022-05-14T01:18:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9776"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LibreDWG/libredwg/issues/99"
    },
    {
      "type": "WEB",
      "url": "https://savannah.gnu.org/bugs/index.php?55893"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00033.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00045.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/107447"
    }
  ],
  "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-5Q8V-G9HQ-MVPX

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

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

drm/amdkfd: Fix kfd_process_device_init_vm error handling

Should only destroy the ib_mem and let process cleanup worker to free the outstanding BOs. Reset the pointer in pdd->qpd structure, to avoid NULL pointer access in process destroy worker.

BUG: kernel NULL pointer dereference, address: 0000000000000010 Call Trace: amdgpu_amdkfd_gpuvm_unmap_gtt_bo_from_kernel+0x46/0xb0 [amdgpu] kfd_process_device_destroy_cwsr_dgpu+0x40/0x70 [amdgpu] kfd_process_destroy_pdds+0x71/0x190 [amdgpu] kfd_process_wq_release+0x2a2/0x3b0 [amdgpu] process_one_work+0x2a1/0x600 worker_thread+0x39/0x3d0

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50354"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-17T15:15:34Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix kfd_process_device_init_vm error handling\n\nShould only destroy the ib_mem and let process cleanup worker to free\nthe outstanding BOs. Reset the pointer in pdd-\u003eqpd structure, to avoid\nNULL pointer access in process destroy worker.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000010\n Call Trace:\n  amdgpu_amdkfd_gpuvm_unmap_gtt_bo_from_kernel+0x46/0xb0 [amdgpu]\n  kfd_process_device_destroy_cwsr_dgpu+0x40/0x70 [amdgpu]\n  kfd_process_destroy_pdds+0x71/0x190 [amdgpu]\n  kfd_process_wq_release+0x2a2/0x3b0 [amdgpu]\n  process_one_work+0x2a1/0x600\n  worker_thread+0x39/0x3d0",
  "id": "GHSA-5q8v-g9hq-mvpx",
  "modified": "2025-12-10T18:30:21Z",
  "published": "2025-09-17T15:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50354"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/29d48b87db64b6697ddad007548e51d032081c59"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9d74d1f52e16d8e07f7fbe52e96d6391418a2fe9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b6e78bd3bf2eb964c95eb2596d3cd367307a20b5"
    }
  ],
  "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-5QCV-CCHC-8X29

Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-10-01 21:31
VLAI
Details

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

Bluetooth: btrtl: check for NULL in btrtl_setup_realtek()

If insert an USB dongle which chip is not maintained in ic_id_table, it will hit the NULL point accessed. Add a null point check to avoid the Kernel Oops.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-57987"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-27T02:15:12Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btrtl: check for NULL in btrtl_setup_realtek()\n\nIf insert an USB dongle which chip is not maintained in ic_id_table, it\nwill hit the NULL point accessed. Add a null point check to avoid the\nKernel Oops.",
  "id": "GHSA-5qcv-cchc-8x29",
  "modified": "2025-10-01T21:31:10Z",
  "published": "2025-02-27T03:34:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57987"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/02f9da874e5e4626f81772eacc18967921998a71"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1158ad8e8abb361d4b2aaa010c9af74de20ab82b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3c15082f3567032d196e8760753373332508c2ca"
    }
  ],
  "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-5QHM-686W-6256

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

An issue was discovered in the Linux kernel through 5.11.11. synic_get in arch/x86/kvm/hyperv.c has a NULL pointer dereference for certain accesses to the SynIC Hyper-V context, aka CID-919f4ebc5987.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-30178"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-07T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in the Linux kernel through 5.11.11. synic_get in arch/x86/kvm/hyperv.c has a NULL pointer dereference for certain accesses to the SynIC Hyper-V context, aka CID-919f4ebc5987.",
  "id": "GHSA-5qhm-686w-6256",
  "modified": "2022-05-24T17:46:49Z",
  "published": "2022-05-24T17:46:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30178"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=919f4ebc598701670e80e31573a58f1f2d2bf918"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IJ5GEETMX3ERQ4DF3GSS2XPNSOOK44OB"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TGQDVYCDM3F5VXUZIADIV2ERL3AJXNJS"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/W5YFGIIF24475A2LNW3UWHW2SNCS3G7M"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-5QJX-3F5W-QJ49

Vulnerability from github – Published: 2026-07-24 18:31 – Updated: 2026-08-11 18:30
VLAI
Details

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

powerpc/time: Remove redundant preempt_disable|enable() calls from arch_irq_work_raise()

A kernel panic is observed when handling machine check exceptions from real mode.

BUG: Unable to handle kernel data access on read at 0xc00000006be21300 Oops: Kernel access of bad area, sig: 11 [#1] MSR: 8000000000001003 CR: 88222248 XER: 00000005 CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0 NIP [c000000000029e40] arch_irq_work_raise+0x10/0x70 LR [c00000000003ffc8] machine_check_queue_event+0xa8/0x150 Call Trace: [c0000000179d3c70] [c00000000003ff64] machine_check_queue_event+0x44/0x150 [c0000000179d3d30] [c0000000000084e0] machine_check_early_common+0x1f0/0x2c0

The crash occurs because arch_irq_work_raise() calls preempt_disable() from machine check exception (MCE) handlers running in real mode. In this context, accessing the preempt_count can fault, leading to the panic.

The preempt_disable()/preempt_enable() pair in arch_irq_work_raise() was originally added by commit 0fe1ac48bef0 ("powerpc/perf_event: Fix oops due to perf_event_do_pending call") to avoid races while raising irq work from exception context.

Later, commit 471ba0e686cb ("irq_work: Do not raise an IPI when queueing work on the local CPU") added preemption protection in irq_work_queue() path, while commit 20b876918c06 ("irq_work: Use per cpu atomics instead of regular atomics") added equivalent protection in irq_work_queue_on() before reaching arch_irq_work_raise():

irq_work_queue() / irq_work_queue_on() -> preempt_disable() -> __irq_work_queue_local() -> irq_work_raise() -> arch_irq_work_raise()

As a result, callers other than mce_irq_work_raise() already execute with preemption disabled, making the additional preempt_disable()/preempt_enable() pair in arch_irq_work_raise() redundant.

The arch_irq_work_raise() function executes in NMI context when called from MCE handler. Hence we will not be preempted or scheduled out since we are in NMI context with MSR[EE]=0. Therefore, it is safe to remove the preempt_disable()/preempt_enable() calls from here.

Remove it to avoid accessing preempt_count from real mode context.

[Maddy: Fixed the commit title]

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-64214"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-24T16:16:49Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/time: Remove redundant preempt_disable|enable() calls from arch_irq_work_raise()\n\nA kernel panic is observed when handling machine check exceptions from\nreal mode.\n\n  BUG: Unable to handle kernel data access on read at 0xc00000006be21300\n  Oops: Kernel access of bad area, sig: 11 [#1]\n  MSR:  8000000000001003 \u003cSF,ME,RI,LE\u003e  CR: 88222248  XER: 00000005\n  CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0\n  NIP [c000000000029e40] arch_irq_work_raise+0x10/0x70\n  LR [c00000000003ffc8] machine_check_queue_event+0xa8/0x150\n  Call Trace:\n  [c0000000179d3c70] [c00000000003ff64] machine_check_queue_event+0x44/0x150\n  [c0000000179d3d30] [c0000000000084e0] machine_check_early_common+0x1f0/0x2c0\n\nThe crash occurs because arch_irq_work_raise() calls preempt_disable()\nfrom machine check exception (MCE) handlers running in real mode. In\nthis context, accessing the preempt_count can fault, leading to the panic.\n\nThe preempt_disable()/preempt_enable() pair in arch_irq_work_raise()\nwas originally added by commit 0fe1ac48bef0 (\"powerpc/perf_event: Fix\noops due to perf_event_do_pending call\") to avoid races while raising\nirq work from exception context.\n\nLater, commit 471ba0e686cb (\"irq_work: Do not raise an IPI when\nqueueing work on the local CPU\") added preemption protection in\nirq_work_queue() path, while commit 20b876918c06 (\"irq_work: Use per\ncpu atomics instead of regular atomics\") added equivalent\nprotection in irq_work_queue_on() before reaching arch_irq_work_raise():\n\n  irq_work_queue() / irq_work_queue_on()\n    -\u003e preempt_disable()\n      -\u003e __irq_work_queue_local()\n        -\u003e irq_work_raise()\n          -\u003e arch_irq_work_raise()\n\nAs a result, callers other than mce_irq_work_raise() already execute\nwith preemption disabled, making the additional\npreempt_disable()/preempt_enable() pair in arch_irq_work_raise()\nredundant.\n\nThe arch_irq_work_raise() function executes in NMI context when called\nfrom MCE handler. Hence we will not be preempted or scheduled out since\nwe are in NMI context with MSR[EE]=0. Therefore, it is safe to remove\nthe preempt_disable()/preempt_enable() calls from here.\n\nRemove it to avoid accessing preempt_count from real mode context.\n\n[Maddy: Fixed the commit title]",
  "id": "GHSA-5qjx-3f5w-qj49",
  "modified": "2026-08-11T18:30:39Z",
  "published": "2026-07-24T18:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64214"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/31467b23823ffec1f6fff407f8e3ca9af8b7491a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/51860e423592893cd7bfa7287d99a3aff4dc3a9d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6dcd072a5ae3aed336e4a67a7d4cc5205b240065"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/72d8d1c36452a4d3ee134b1da48de7518c1329f9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8079acc5ee5235a627e4586d4f42082a9000ea64"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a09d07ac45e283c9861a9ceea06f56d0ba851d22"
    }
  ],
  "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-5QQG-7VMR-GJG2

Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-07 21:31
VLAI
Details

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

netfs: Fix missing xas_retry() calls in xarray iteration

netfslib has a number of places in which it performs iteration of an xarray whilst being under the RCU read lock. It should call xas_retry() as the first thing inside of the loop and do "continue" if it returns true in case the xarray walker passed out a special value indicating that the walk needs to be redone from the root[*].

Fix this by adding the missing retry checks.

[*] I wonder if this should be done inside xas_find(), xas_next_node() and suchlike, but I'm told that's not an simple change to effect.

This can cause an oops like that below. Note the faulting address - this is an internal value (|0x2) returned from xarray.

BUG: kernel NULL pointer dereference, address: 0000000000000402 ... RIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs] ... Call Trace: netfs_rreq_assess+0xa6/0x240 [netfs] netfs_readpage+0x173/0x3b0 [netfs] ? init_wait_var_entry+0x50/0x50 filemap_read_page+0x33/0xf0 filemap_get_pages+0x2f2/0x3f0 filemap_read+0xaa/0x320 ? do_filp_open+0xb2/0x150 ? rmqueue+0x3be/0xe10 ceph_read_iter+0x1fe/0x680 [ceph] ? new_sync_read+0x115/0x1a0 new_sync_read+0x115/0x1a0 vfs_read+0xf3/0x180 ksys_read+0x5f/0xe0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae

Changes:

ver #2) - Changed an unsigned int to a size_t to reduce the likelihood of an overflow as per Willy's suggestion. - Added an additional patch to fix the maths.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49810"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-01T15:16:04Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix missing xas_retry() calls in xarray iteration\n\nnetfslib has a number of places in which it performs iteration of an xarray\nwhilst being under the RCU read lock.  It *should* call xas_retry() as the\nfirst thing inside of the loop and do \"continue\" if it returns true in case\nthe xarray walker passed out a special value indicating that the walk needs\nto be redone from the root[*].\n\nFix this by adding the missing retry checks.\n\n[*] I wonder if this should be done inside xas_find(), xas_next_node() and\n    suchlike, but I\u0027m told that\u0027s not an simple change to effect.\n\nThis can cause an oops like that below.  Note the faulting address - this\nis an internal value (|0x2) returned from xarray.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000402\n...\nRIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs]\n...\nCall Trace:\n netfs_rreq_assess+0xa6/0x240 [netfs]\n netfs_readpage+0x173/0x3b0 [netfs]\n ? init_wait_var_entry+0x50/0x50\n filemap_read_page+0x33/0xf0\n filemap_get_pages+0x2f2/0x3f0\n filemap_read+0xaa/0x320\n ? do_filp_open+0xb2/0x150\n ? rmqueue+0x3be/0xe10\n ceph_read_iter+0x1fe/0x680 [ceph]\n ? new_sync_read+0x115/0x1a0\n new_sync_read+0x115/0x1a0\n vfs_read+0xf3/0x180\n ksys_read+0x5f/0xe0\n do_syscall_64+0x38/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nChanges:\n========\nver #2)\n - Changed an unsigned int to a size_t to reduce the likelihood of an\n   overflow as per Willy\u0027s suggestion.\n - Added an additional patch to fix the maths.",
  "id": "GHSA-5qqg-7vmr-gjg2",
  "modified": "2025-11-07T21:31:19Z",
  "published": "2025-05-01T15:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49810"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7e043a80b5dae5c2d2cf84031501de7827fd6c00"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b2cc07a76f1eb12de3b22caf5fdbf856a7bef16d"
    }
  ],
  "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-5QR9-CJJ5-7M79

Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2025-12-03 21:31
VLAI
Details

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

xsk: check IFF_UP earlier in Tx path

Xsk Tx can be triggered via either sendmsg() or poll() syscalls. These two paths share a call to common function xsk_xmit() which has two sanity checks within. A pseudo code example to show the two paths:

__xsk_sendmsg() : xsk_poll(): if (unlikely(!xsk_is_bound(xs))) if (unlikely(!xsk_is_bound(xs))) return -ENXIO; return mask; if (unlikely(need_wait)) (...) return -EOPNOTSUPP; xsk_xmit() mark napi id (...) xsk_xmit()

xsk_xmit(): if (unlikely(!(xs->dev->flags & IFF_UP))) return -ENETDOWN; if (unlikely(!xs->tx)) return -ENOBUFS;

As it can be observed above, in sendmsg() napi id can be marked on interface that was not brought up and this causes a NULL ptr dereference:

[31757.505631] BUG: kernel NULL pointer dereference, address: 0000000000000018 [31757.512710] #PF: supervisor read access in kernel mode [31757.517936] #PF: error_code(0x0000) - not-present page [31757.523149] PGD 0 P4D 0 [31757.525726] Oops: 0000 [#1] PREEMPT SMP NOPTI [31757.530154] CPU: 26 PID: 95641 Comm: xdpsock Not tainted 6.2.0-rc5+ #40 [31757.536871] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [31757.547457] RIP: 0010:xsk_sendmsg+0xde/0x180 [31757.551799] Code: 00 75 a2 48 8b 00 a8 04 75 9b 84 d2 74 69 8b 85 14 01 00 00 85 c0 75 1b 48 8b 85 28 03 00 00 48 8b 80 98 00 00 00 48 8b 40 20 <8b> 40 18 89 85 14 01 00 00 8b bd 14 01 00 00 81 ff 00 01 00 00 0f [31757.570840] RSP: 0018:ffffc90034f27dc0 EFLAGS: 00010246 [31757.576143] RAX: 0000000000000000 RBX: ffffc90034f27e18 RCX: 0000000000000000 [31757.583389] RDX: 0000000000000001 RSI: ffffc90034f27e18 RDI: ffff88984cf3c100 [31757.590631] RBP: ffff88984714a800 R08: ffff88984714a800 R09: 0000000000000000 [31757.597877] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000fffffffa [31757.605123] R13: 0000000000000000 R14: 0000000000000003 R15: 0000000000000000 [31757.612364] FS: 00007fb4c5931180(0000) GS:ffff88afdfa00000(0000) knlGS:0000000000000000 [31757.620571] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [31757.626406] CR2: 0000000000000018 CR3: 000000184b41c003 CR4: 00000000007706e0 [31757.633648] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [31757.640894] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [31757.648139] PKRU: 55555554 [31757.650894] Call Trace: [31757.653385] [31757.655524] sock_sendmsg+0x8f/0xa0 [31757.659077] ? sockfd_lookup_light+0x12/0x70 [31757.663416] __sys_sendto+0xfc/0x170 [31757.667051] ? do_sched_setscheduler+0xdb/0x1b0 [31757.671658] __x64_sys_sendto+0x20/0x30 [31757.675557] do_syscall_64+0x38/0x90 [31757.679197] entry_SYSCALL_64_after_hwframe+0x72/0xdc [31757.687969] Code: 8e f6 ff 44 8b 4c 24 2c 4c 8b 44 24 20 41 89 c4 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 3a 44 89 e7 48 89 44 24 08 e8 b5 8e f6 ff 48 [31757.707007] RSP: 002b:00007ffd49c73c70 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [31757.714694] RAX: ffffffffffffffda RBX: 000055a996565380 RCX: 00007fb4c5727c16 [31757.721939] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 [31757.729184] RBP: 0000000000000040 R08: 0000000000000000 R09: 0000000000000000 [31757.736429] R10: 0000000000000040 R11: 0000000000000293 R12: 0000000000000000 [31757.743673] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [31757.754940]

To fix this, let's make xsk_xmit a function that will be responsible for generic Tx, where RCU is handled accordingly and pull out sanity checks and xs->zc handling. Populate sanity checks to __xsk_sendmsg() and xsk_poll().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-53240"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-15T15:15:51Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: check IFF_UP earlier in Tx path\n\nXsk Tx can be triggered via either sendmsg() or poll() syscalls. These\ntwo paths share a call to common function xsk_xmit() which has two\nsanity checks within. A pseudo code example to show the two paths:\n\n__xsk_sendmsg() :                       xsk_poll():\nif (unlikely(!xsk_is_bound(xs)))        if (unlikely(!xsk_is_bound(xs)))\n    return -ENXIO;                          return mask;\nif (unlikely(need_wait))                (...)\n    return -EOPNOTSUPP;                 xsk_xmit()\nmark napi id\n(...)\nxsk_xmit()\n\nxsk_xmit():\nif (unlikely(!(xs-\u003edev-\u003eflags \u0026 IFF_UP)))\n\treturn -ENETDOWN;\nif (unlikely(!xs-\u003etx))\n\treturn -ENOBUFS;\n\nAs it can be observed above, in sendmsg() napi id can be marked on\ninterface that was not brought up and this causes a NULL ptr\ndereference:\n\n[31757.505631] BUG: kernel NULL pointer dereference, address: 0000000000000018\n[31757.512710] #PF: supervisor read access in kernel mode\n[31757.517936] #PF: error_code(0x0000) - not-present page\n[31757.523149] PGD 0 P4D 0\n[31757.525726] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[31757.530154] CPU: 26 PID: 95641 Comm: xdpsock Not tainted 6.2.0-rc5+ #40\n[31757.536871] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019\n[31757.547457] RIP: 0010:xsk_sendmsg+0xde/0x180\n[31757.551799] Code: 00 75 a2 48 8b 00 a8 04 75 9b 84 d2 74 69 8b 85 14 01 00 00 85 c0 75 1b 48 8b 85 28 03 00 00 48 8b 80 98 00 00 00 48 8b 40 20 \u003c8b\u003e 40 18 89 85 14 01 00 00 8b bd 14 01 00 00 81 ff 00 01 00 00 0f\n[31757.570840] RSP: 0018:ffffc90034f27dc0 EFLAGS: 00010246\n[31757.576143] RAX: 0000000000000000 RBX: ffffc90034f27e18 RCX: 0000000000000000\n[31757.583389] RDX: 0000000000000001 RSI: ffffc90034f27e18 RDI: ffff88984cf3c100\n[31757.590631] RBP: ffff88984714a800 R08: ffff88984714a800 R09: 0000000000000000\n[31757.597877] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000fffffffa\n[31757.605123] R13: 0000000000000000 R14: 0000000000000003 R15: 0000000000000000\n[31757.612364] FS:  00007fb4c5931180(0000) GS:ffff88afdfa00000(0000) knlGS:0000000000000000\n[31757.620571] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[31757.626406] CR2: 0000000000000018 CR3: 000000184b41c003 CR4: 00000000007706e0\n[31757.633648] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[31757.640894] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[31757.648139] PKRU: 55555554\n[31757.650894] Call Trace:\n[31757.653385]  \u003cTASK\u003e\n[31757.655524]  sock_sendmsg+0x8f/0xa0\n[31757.659077]  ? sockfd_lookup_light+0x12/0x70\n[31757.663416]  __sys_sendto+0xfc/0x170\n[31757.667051]  ? do_sched_setscheduler+0xdb/0x1b0\n[31757.671658]  __x64_sys_sendto+0x20/0x30\n[31757.675557]  do_syscall_64+0x38/0x90\n[31757.679197]  entry_SYSCALL_64_after_hwframe+0x72/0xdc\n[31757.687969] Code: 8e f6 ff 44 8b 4c 24 2c 4c 8b 44 24 20 41 89 c4 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 \u003c48\u003e 3d 00 f0 ff ff 77 3a 44 89 e7 48 89 44 24 08 e8 b5 8e f6 ff 48\n[31757.707007] RSP: 002b:00007ffd49c73c70 EFLAGS: 00000293 ORIG_RAX: 000000000000002c\n[31757.714694] RAX: ffffffffffffffda RBX: 000055a996565380 RCX: 00007fb4c5727c16\n[31757.721939] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\n[31757.729184] RBP: 0000000000000040 R08: 0000000000000000 R09: 0000000000000000\n[31757.736429] R10: 0000000000000040 R11: 0000000000000293 R12: 0000000000000000\n[31757.743673] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[31757.754940]  \u003c/TASK\u003e\n\nTo fix this, let\u0027s make xsk_xmit a function that will be responsible for\ngeneric Tx, where RCU is handled accordingly and pull out sanity checks\nand xs-\u003ezc handling. Populate sanity checks to __xsk_sendmsg() and\nxsk_poll().",
  "id": "GHSA-5qr9-cjj5-7m79",
  "modified": "2025-12-03T21:31:00Z",
  "published": "2025-09-15T15:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53240"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1596dae2f17ec5c6e8c8f0e3fec78c5ae55c1e0b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cecc68559cd57fffb2be50685f262b9af2318e16"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ffe19750e68d0bb21e8110b398346eef20b156a7"
    }
  ],
  "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-5QVX-CMVH-V55M

Vulnerability from github – Published: 2024-09-13 06:30 – Updated: 2024-09-13 18:31
VLAI
Details

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

soc: qcom: pmic_glink: Fix race during initialization

As pointed out by Stephen Boyd it is possible that during initialization of the pmic_glink child drivers, the protection-domain notifiers fires, and the associated work is scheduled, before the client registration returns and as a result the local "client" pointer has been initialized.

The outcome of this is a NULL pointer dereference as the "client" pointer is blindly dereferenced.

Timeline provided by Stephen: CPU0 CPU1 ---- ---- ucsi->client = NULL; devm_pmic_glink_register_client() client->pdr_notify(client->priv, pg->client_state) pmic_glink_ucsi_pdr_notify() schedule_work(&ucsi->register_work) pmic_glink_ucsi_register() ucsi_register() pmic_glink_ucsi_read_version() pmic_glink_ucsi_read() pmic_glink_ucsi_read() pmic_glink_send(ucsi->client) ucsi->client = client // Too late!

This code is identical across the altmode, battery manager and usci child drivers.

Resolve this by splitting the allocation of the "client" object and the registration thereof into two operations.

This only happens if the protection domain registry is populated at the time of registration, which by the introduction of commit '1ebcde047c54 ("soc: qcom: add pd-mapper implementation")' became much more likely.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-46693"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-13T06:15:14Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: pmic_glink: Fix race during initialization\n\nAs pointed out by Stephen Boyd it is possible that during initialization\nof the pmic_glink child drivers, the protection-domain notifiers fires,\nand the associated work is scheduled, before the client registration\nreturns and as a result the local \"client\" pointer has been initialized.\n\nThe outcome of this is a NULL pointer dereference as the \"client\"\npointer is blindly dereferenced.\n\nTimeline provided by Stephen:\n CPU0                               CPU1\n ----                               ----\n ucsi-\u003eclient = NULL;\n devm_pmic_glink_register_client()\n  client-\u003epdr_notify(client-\u003epriv, pg-\u003eclient_state)\n   pmic_glink_ucsi_pdr_notify()\n    schedule_work(\u0026ucsi-\u003eregister_work)\n    \u003cschedule away\u003e\n                                    pmic_glink_ucsi_register()\n                                     ucsi_register()\n                                      pmic_glink_ucsi_read_version()\n                                       pmic_glink_ucsi_read()\n                                        pmic_glink_ucsi_read()\n                                         pmic_glink_send(ucsi-\u003eclient)\n                                         \u003cclient is NULL BAD\u003e\n ucsi-\u003eclient = client // Too late!\n\nThis code is identical across the altmode, battery manager and usci\nchild drivers.\n\nResolve this by splitting the allocation of the \"client\" object and the\nregistration thereof into two operations.\n\nThis only happens if the protection domain registry is populated at the\ntime of registration, which by the introduction of commit \u00271ebcde047c54\n(\"soc: qcom: add pd-mapper implementation\")\u0027 became much more likely.",
  "id": "GHSA-5qvx-cmvh-v55m",
  "modified": "2024-09-13T18:31:46Z",
  "published": "2024-09-13T06:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46693"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1efdbf5323c9360e05066049b97414405e94e087"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3568affcddd68743e25aa3ec1647d9b82797757b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/943b0e7cc646a624bb20a68080f8f1a4a55df41c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/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.