GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
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.

6649 vulnerabilities reference this CWE, most recent first.

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"
    }
  ]
}

GHSA-5QX2-HPG2-XVGJ

Vulnerability from github – Published: 2025-10-03 21:30 – Updated: 2025-10-08 21:30
VLAI
Details

A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.

We have already fixed the vulnerability in the following versions: QTS 5.2.6.3195 build 20250715 and later QuTS hero h5.2.6.3195 build 20250715 and later

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-52427"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-03T19:15:45Z",
    "severity": "MODERATE"
  },
  "details": "A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.\n\nWe have already fixed the vulnerability in the following versions:\nQTS 5.2.6.3195 build 20250715 and later\nQuTS hero h5.2.6.3195 build 20250715 and later",
  "id": "GHSA-5qx2-hpg2-xvgj",
  "modified": "2025-10-08T21:30:24Z",
  "published": "2025-10-03T21:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52427"
    },
    {
      "type": "WEB",
      "url": "https://www.qnap.com/en/security-advisory/qsa-25-36"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-5QX5-JPR4-RW99

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

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

Revert "drm/gem-framebuffer: Use dma_buf from GEM object instance"

This reverts commit cce16fcd7446dcff7480cd9d2b6417075ed81065.

The dma_buf field in struct drm_gem_object is not stable over the object instance's lifetime. The field becomes NULL when user space releases the final GEM handle on the buffer object. This resulted in a NULL-pointer deref.

Workarounds in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer: Acquire internal references on GEM handles") only solved the problem partially. They especially don't work for buffer objects without a DRM framebuffer associated.

Hence, this revert to going back to using .import_attach->dmabuf.

v3: - cc stable

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-38673"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-22T16:15:42Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"drm/gem-framebuffer: Use dma_buf from GEM object instance\"\n\nThis reverts commit cce16fcd7446dcff7480cd9d2b6417075ed81065.\n\nThe dma_buf field in struct drm_gem_object is not stable over the\nobject instance\u0027s lifetime. The field becomes NULL when user space\nreleases the final GEM handle on the buffer object. This resulted\nin a NULL-pointer deref.\n\nWorkarounds in commit 5307dce878d4 (\"drm/gem: Acquire references on\nGEM handles for framebuffers\") and commit f6bfc9afc751 (\"drm/framebuffer:\nAcquire internal references on GEM handles\") only solved the problem\npartially. They especially don\u0027t work for buffer objects without a DRM\nframebuffer associated.\n\nHence, this revert to going back to using .import_attach-\u003edmabuf.\n\nv3:\n- cc stable",
  "id": "GHSA-5qx5-jpr4-rw99",
  "modified": "2025-11-26T00:30:15Z",
  "published": "2025-08-22T18:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38673"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2712ca878b688682ac2ce02aefc413fc76019cd9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e31f5a1c2cd38bf977736cdfa79444e19d4005ec"
    }
  ],
  "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-5R3H-V82J-R7RR

Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-07-02 21:32
VLAI
Details

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

ipv6: Fix a potential NPD in cleanup_prefix_route()

addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1].

Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug:

  1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry.

  2. modify_prefix_route(): Fixed by commit a747e02430df ("ipv6: avoid possible NULL deref in modify_prefix_route()").

  3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error.

[1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) _syssendmsg (net/socket.c:2698) _sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-53214"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T09:16:39Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix a potential NPD in cleanup_prefix_route()\n\naddrconf_get_prefix_route() can return the fib6_null_entry sentinel\nentry which has a NULL fib6_table pointer. Therefore, before setting the\nroute\u0027s expiration time, check that we are not working with this entry,\nas otherwise a NPD will be triggered [1].\n\nNote that the other callers of addrconf_get_prefix_route() are not\nsusceptible to this bug:\n\n1. addrconf_prefix_rcv(): Requests a route with the \u0027RTF_ADDRCONF |\n   RTF_PREFIX_RT\u0027 flags which are not set on fib6_null_entry.\n\n2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid\n   possible NULL deref in modify_prefix_route()\").\n\n3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for\n   fib6_null_entry and returns an error.\n\n[1]\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[...]\nCall Trace:\n\u003cTASK\u003e\n__kasan_check_byte (mm/kasan/common.c:573)\nlock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1))\n_raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1))\ncleanup_prefix_route (net/ipv6/addrconf.c:1280)\nipv6_del_addr (net/ipv6/addrconf.c:1342)\ninet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119)\ninet6_rtm_deladdr (net/ipv6/addrconf.c:4812)\nrtnetlink_rcv_msg (net/core/rtnetlink.c:6997)\nnetlink_rcv_skb (net/netlink/af_netlink.c:2555)\nnetlink_unicast (net/netlink/af_netlink.c:1344)\nnetlink_sendmsg (net/netlink/af_netlink.c:1899)\n__sock_sendmsg (net/socket.c:802 (discriminator 4))\n____sys_sendmsg (net/socket.c:2698)\n___sys_sendmsg (net/socket.c:2752)\n__sys_sendmsg (net/socket.c:2784)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)",
  "id": "GHSA-5r3h-v82j-r7rr",
  "modified": "2026-07-02T21:32:05Z",
  "published": "2026-06-25T09:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53214"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/07d9a0870a178843cea44cfd58c27445dc94cf5f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/192df376a05c2db15564640f9da7e20907c1fa24"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5f82b02b4059ddc06e4fcfd057bfb59fd6885cd2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/653a2849305708f75260b5296f17b2a759ff9cc7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b70c687b7cf267fb08586667a3946c8851cad672"
    }
  ],
  "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-5R4M-496R-7WQM

Vulnerability from github – Published: 2023-01-17 18:30 – Updated: 2025-04-07 18:30
VLAI
Details

A flaw was found in the Linux kernel. A NULL pointer dereference may occur while a slip driver is in progress to detach in sl_tx_timeout in drivers/net/slip/slip.c. This issue could allow an attacker to crash the system or leak internal kernel information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-41858"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416",
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-17T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in the Linux kernel. A NULL pointer dereference may occur while a slip driver is in progress to detach in sl_tx_timeout in drivers/net/slip/slip.c. This issue could allow an attacker to crash the system or leak internal kernel information.",
  "id": "GHSA-5r4m-496r-7wqm",
  "modified": "2025-04-07T18:30:34Z",
  "published": "2023-01-17T18:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41858"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/ec4eb8a86ade4d22633e1da2a7d85a846b7d1798"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20230223-0006"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5R68-RPXC-F6CW

Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-07-04 12:30
VLAI
Details

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

usb: cdns3: gadget: fix NULL pointer dereference in ep_queue

When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash.

Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints.

This prevents potential crashes when ep_queue is called on endpoints that are not ready.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-31755"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-01T15:16:38Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: gadget: fix NULL pointer dereference in ep_queue\n\nWhen the gadget endpoint is disabled or not yet configured, the ep-\u003edesc\npointer can be NULL. This leads to a NULL pointer dereference when\n__cdns3_gadget_ep_queue() is called, causing a kernel crash.\n\nAdd a check to return -ESHUTDOWN if ep-\u003edesc is NULL, which is the\nstandard return code for unconfigured endpoints.\n\nThis prevents potential crashes when ep_queue is called on endpoints\nthat are not ready.",
  "id": "GHSA-5r68-rpxc-f6cw",
  "modified": "2026-07-04T12:30:27Z",
  "published": "2026-05-01T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31755"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/14bf08ab2cdfcdfd3f13e799d06692a1b3e0745f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/390536cc6af4ca5566bc3bf1f8b704700380cd2c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3cf0580a09d417eab41ce914a11f9cde3a121871"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3d1433fe34b224b90259e207e5389e95b504ef04"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7f6f127b9bc34bed35f56faf7ecb1561d6b39000"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9ab9b0e5fcdac325f950fc8b6caa08a9e22a0db9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d61446dfc9d387775bb1b95b081953201b9222af"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fb2ad0c1334a3eccfe4ed203f9eef5a4879226f6"
    }
  ],
  "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-5RCG-JQ54-2R8G

Vulnerability from github – Published: 2023-11-14 21:31 – Updated: 2023-11-14 21:31
VLAI
Details

NULL pointer dereference in some Intel(R) Arc(TM) & Iris(R) Xe Graphics - WHQL - Windows Drviers before version 31.0.101.4255 may allow authenticated user to potentially enable denial of service via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-25071"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-395",
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-14T19:15:18Z",
    "severity": "MODERATE"
  },
  "details": "NULL pointer dereference in some Intel(R) Arc(TM) \u0026 Iris(R) Xe Graphics - WHQL - Windows Drviers before version 31.0.101.4255 may allow authenticated user to potentially enable denial of service via local access.",
  "id": "GHSA-5rcg-jq54-2r8g",
  "modified": "2023-11-14T21:31:01Z",
  "published": "2023-11-14T21:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25071"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00864.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/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.