CWE-476
AllowedNULL Pointer Dereference
Abstraction: Base · Status: Stable
The product dereferences a pointer that it expects to be valid but is NULL.
6397 vulnerabilities reference this CWE, most recent first.
GHSA-HP8R-5243-X9F3
Vulnerability from github – Published: 2022-05-13 01:28 – Updated: 2025-04-20 03:40libxar.so in xar 1.6.1 has a NULL pointer dereference in the xar_get_path function in util.c.
{
"affected": [],
"aliases": [
"CVE-2017-11125"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-10T03:29:00Z",
"severity": "CRITICAL"
},
"details": "libxar.so in xar 1.6.1 has a NULL pointer dereference in the xar_get_path function in util.c.",
"id": "GHSA-hp8r-5243-x9f3",
"modified": "2025-04-20T03:40:29Z",
"published": "2022-05-13T01:28:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11125"
},
{
"type": "WEB",
"url": "https://blogs.gentoo.org/ago/2017/06/28/xar-null-pointer-dereference-in-xar_get_path-util-c"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2S2KRIILUKBJHXDNYJQQX74TFUQRG5ND"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YV6RF6VWM7AFYFTTS7VY5TNH26QUEEFC"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2S2KRIILUKBJHXDNYJQQX74TFUQRG5ND"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YV6RF6VWM7AFYFTTS7VY5TNH26QUEEFC"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HPC7-GCQM-58FV
Vulnerability from github – Published: 2026-01-27 18:32 – Updated: 2026-03-20 15:31Issue summary: PBMAC1 parameters in PKCS#12 files are missing validation which can trigger a stack-based buffer overflow, invalid pointer or NULL pointer dereference during MAC verification.
Impact summary: The stack buffer overflow or NULL pointer dereference may cause a crash leading to Denial of Service for an application that parses untrusted PKCS#12 files. The buffer overflow may also potentially enable code execution depending on platform mitigations.
When verifying a PKCS#12 file that uses PBMAC1 for the MAC, the PBKDF2 salt and keylength parameters from the file are used without validation. If the value of keylength exceeds the size of the fixed stack buffer used for the derived key (64 bytes), the key derivation will overflow the buffer. The overflow length is attacker-controlled. Also, if the salt parameter is not an OCTET STRING type this can lead to invalid or NULL pointer dereference.
Exploiting this issue requires a user or application to process a maliciously crafted PKCS#12 file. It is uncommon to accept untrusted PKCS#12 files in applications as they are usually used to store private keys which are trusted by definition. For this reason the issue was assessed as Moderate severity.
The FIPS modules in 3.6, 3.5 and 3.4 are not affected by this issue, as PKCS#12 processing is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5 and 3.4 are vulnerable to this issue.
OpenSSL 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue as they do not support PBMAC1 in PKCS#12.
{
"affected": [],
"aliases": [
"CVE-2025-11187"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-27T16:16:14Z",
"severity": "MODERATE"
},
"details": "Issue summary: PBMAC1 parameters in PKCS#12 files are missing validation\nwhich can trigger a stack-based buffer overflow, invalid pointer or NULL\npointer dereference during MAC verification.\n\nImpact summary: The stack buffer overflow or NULL pointer dereference may\ncause a crash leading to Denial of Service for an application that parses\nuntrusted PKCS#12 files. The buffer overflow may also potentially enable\ncode execution depending on platform mitigations.\n\nWhen verifying a PKCS#12 file that uses PBMAC1 for the MAC, the PBKDF2\nsalt and keylength parameters from the file are used without validation.\nIf the value of keylength exceeds the size of the fixed stack buffer used\nfor the derived key (64 bytes), the key derivation will overflow the buffer.\nThe overflow length is attacker-controlled. Also, if the salt parameter is\nnot an OCTET STRING type this can lead to invalid or NULL pointer\ndereference.\n\nExploiting this issue requires a user or application to process\na maliciously crafted PKCS#12 file. It is uncommon to accept untrusted\nPKCS#12 files in applications as they are usually used to store private\nkeys which are trusted by definition. For this reason the issue was assessed\nas Moderate severity.\n\nThe FIPS modules in 3.6, 3.5 and 3.4 are not affected by this issue, as\nPKCS#12 processing is outside the OpenSSL FIPS module boundary.\n\nOpenSSL 3.6, 3.5 and 3.4 are vulnerable to this issue.\n\nOpenSSL 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue as they do\nnot support PBMAC1 in PKCS#12.",
"id": "GHSA-hpc7-gcqm-58fv",
"modified": "2026-03-20T15:31:04Z",
"published": "2026-01-27T18:32:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11187"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/205e3a55e16e4bd08c12fdbd3416ab829c0f6206"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/8caf359d6e46fb413e8f5f0df765d2e8a51df4e8"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/e1079bc17ed93ff16f6b86f33a2fe3336e78817e"
},
{
"type": "WEB",
"url": "https://github.com/metadust/CVE-2025-11187"
},
{
"type": "WEB",
"url": "https://openssl-library.org/news/secadv/20260127.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HPF6-962W-3G93
Vulnerability from github – Published: 2025-01-22 00:33 – Updated: 2025-01-23 18:31A Null pointer dereference vulnerability in the Mobile Management Entity (MME) in Magma <= 1.8.0 (fixed in v1.9 commit 08472ba98b8321f802e95f5622fa90fec2dea486) allows network-adjacent attackers to crash the MME via an S1AP E-RAB Release Response packet missing an expected MME_UE_S1AP_ID field.
{
"affected": [],
"aliases": [
"CVE-2023-37026"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-21T23:15:09Z",
"severity": "MODERATE"
},
"details": "A Null pointer dereference vulnerability in the Mobile Management Entity (MME) in Magma \u003c= 1.8.0 (fixed in v1.9 commit 08472ba98b8321f802e95f5622fa90fec2dea486) allows network-adjacent attackers to crash the MME via an S1AP `E-RAB Release Response` packet missing an expected `MME_UE_S1AP_ID` field.",
"id": "GHSA-hpf6-962w-3g93",
"modified": "2025-01-23T18:31:18Z",
"published": "2025-01-22T00:33:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37026"
},
{
"type": "WEB",
"url": "https://cellularsecurity.org/ransacked"
}
],
"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"
}
]
}
GHSA-HPJC-M442-8HRM
Vulnerability from github – Published: 2025-10-04 09:30 – Updated: 2026-01-23 21:30In the Linux kernel, the following vulnerability has been resolved:
drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ
If the interrupt occurs before resource initialization is complete, the interrupt handler/worker may access uninitialized data such as the I2C tcpc_client device, potentially leading to NULL pointer dereference.
{
"affected": [],
"aliases": [
"CVE-2025-39934"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T08:15:46Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: bridge: anx7625: Fix NULL pointer dereference with early IRQ\n\nIf the interrupt occurs before resource initialization is complete, the\ninterrupt handler/worker may access uninitialized data such as the I2C\ntcpc_client device, potentially leading to NULL pointer dereference.",
"id": "GHSA-hpjc-m442-8hrm",
"modified": "2026-01-23T21:30:36Z",
"published": "2025-10-04T09:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39934"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0da73f7827691a5e2265b110d5fe12f29535ec92"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/15a77e1ab0a994d69b471c76b8d01117128dda26"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1a7ea294d57fb61485d11b3f2241d631d73025cb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51a501e990a353a4f15da6bab295b28e5d118f64"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a10f910c77f280327b481e77eab909934ec508f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9a089d0a6d537d0f2061c8a37a7de535ce0310e"
}
],
"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-HPP4-8VC7-9FH4
Vulnerability from github – Published: 2024-05-19 09:34 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
net/rds: fix possible cp null dereference
cp might be null, calling cp->cp_conn would produce null dereference
[Simon Horman adds:]
Analysis:
-
cp is a parameter of __rds_rdma_map and is not reassigned.
-
The following call-sites pass a NULL cp argument to __rds_rdma_map()
-
rds_get_mr()
-
rds_get_mr_for_dest
-
Prior to the code above, the following assumes that cp may be NULL (which is indicative, but could itself be unnecessary)
trans_private = rs->rs_transport->get_mr( sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL, args->vec.addr, args->vec.bytes, need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);
-
The code modified by this patch is guarded by IS_ERR(trans_private), where trans_private is assigned as per the previous point in this analysis.
The only implementation of get_mr that I could locate is rds_ib_get_mr() which can return an ERR_PTR if the conn (4th) argument is NULL.
- ret is set to PTR_ERR(trans_private). rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL. Thus ret may be -ENODEV in which case the code in question will execute.
Conclusion: * cp may be NULL at the point where this patch adds a check; this patch does seem to address a possible bug
{
"affected": [],
"aliases": [
"CVE-2024-35902"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-19T09:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/rds: fix possible cp null dereference\n\ncp might be null, calling cp-\u003ecp_conn would produce null dereference\n\n[Simon Horman adds:]\n\nAnalysis:\n\n* cp is a parameter of __rds_rdma_map and is not reassigned.\n\n* The following call-sites pass a NULL cp argument to __rds_rdma_map()\n\n - rds_get_mr()\n - rds_get_mr_for_dest\n\n* Prior to the code above, the following assumes that cp may be NULL\n (which is indicative, but could itself be unnecessary)\n\n\ttrans_private = rs-\u003ers_transport-\u003eget_mr(\n\t\tsg, nents, rs, \u0026mr-\u003er_key, cp ? cp-\u003ecp_conn : NULL,\n\t\targs-\u003evec.addr, args-\u003evec.bytes,\n\t\tneed_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);\n\n* The code modified by this patch is guarded by IS_ERR(trans_private),\n where trans_private is assigned as per the previous point in this analysis.\n\n The only implementation of get_mr that I could locate is rds_ib_get_mr()\n which can return an ERR_PTR if the conn (4th) argument is NULL.\n\n* ret is set to PTR_ERR(trans_private).\n rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.\n Thus ret may be -ENODEV in which case the code in question will execute.\n\nConclusion:\n* cp may be NULL at the point where this patch adds a check;\n this patch does seem to address a possible bug",
"id": "GHSA-hpp4-8vc7-9fh4",
"modified": "2026-05-12T12:31:49Z",
"published": "2024-05-19T09:34:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35902"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62fc3357e079a07a22465b9b6ef71bb6ea75ee4b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6794090c742008c53b344b35b021d4a3093dc50a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92309bed3c5fbe2ccd4c45056efd42edbd06162d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bcd46782e2ec3825d10c1552fcb674d491cc09f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cbaac2e5488ed54833897264a5ffb2a341a9f196"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cfb786b03b03c5ff38882bee38525eb9987e4d14"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d275de8ea7be3a453629fddae41d4156762e814c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d49fac38479bfdaec52b3ea274d290c47a294029"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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-HQ23-GGCP-MX5X
Vulnerability from github – Published: 2025-09-23 06:30 – Updated: 2025-12-12 21:31In the Linux kernel, the following vulnerability has been resolved:
ceph: always call ceph_shift_unused_folios_left()
The function ceph_process_folio_batch() sets folio_batch entries to NULL, which is an illegal state. Before folio_batch_release() crashes due to this API violation, the function ceph_shift_unused_folios_left() is supposed to remove those NULLs from the array.
However, since commit ce80b76dd327 ("ceph: introduce
ceph_process_folio_batch() method"), this shifting doesn't happen
anymore because the "for" loop got moved to ceph_process_folio_batch(),
and now the i variable that remains in ceph_writepages_start()
doesn't get incremented anymore, making the shifting effectively
unreachable much of the time.
Later, commit 1551ec61dc55 ("ceph: introduce ceph_submit_write()
method") added more preconditions for doing the shift, replacing the
i check (with something that is still just as broken):
-
if ceph_process_folio_batch() fails, shifting never happens
-
if ceph_move_dirty_page_in_page_array() was never called (because ceph_process_folio_batch() has returned early for some of various reasons), shifting never happens
-
if
processed_in_fbatchis zero (because ceph_process_folio_batch() has returned early for some of the reasons mentioned above or because ceph_move_dirty_page_in_page_array() has failed), shifting never happens
Since those two commits, any problem in ceph_process_folio_batch() could crash the kernel, e.g. this way:
BUG: kernel NULL pointer dereference, address: 0000000000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 172 UID: 0 PID: 2342707 Comm: kworker/u778:8 Not tainted 6.15.10-cm4all1-es #714 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.10 12/08/2023 Workqueue: writeback wb_workfn (flush-ceph-1) RIP: 0010:folios_put_refs+0x85/0x140 Code: 83 c5 01 39 e8 7e 76 48 63 c5 49 8b 5c c4 08 b8 01 00 00 00 4d 85 ed 74 05 41 8b 44 ad 00 48 8b 15 b0 > RSP: 0018:ffffb880af8db778 EFLAGS: 00010207 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000003 RDX: ffffe377cc3b0000 RSI: 0000000000000000 RDI: ffffb880af8db8c0 RBP: 0000000000000000 R08: 000000000000007d R09: 000000000102b86f R10: 0000000000000001 R11: 00000000000000ac R12: ffffb880af8db8c0 R13: 0000000000000000 R14: 0000000000000000 R15: ffff9bd262c97000 FS: 0000000000000000(0000) GS:ffff9c8efc303000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000034 CR3: 0000000160958004 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ceph_writepages_start+0xeb9/0x1410
The crash can be reproduced easily by changing the
ceph_check_page_before_write() return value to -E2BIG.
(Interestingly, the crash happens only if huge_zero_folio has
already been allocated; without huge_zero_folio,
is_huge_zero_folio(NULL) returns true and folios_put_refs() skips NULL
entries instead of dereferencing them. That makes reproducing the bug
somewhat unreliable. See
https://lore.kernel.org/20250826231626.218675-1-max.kellermann@ionos.com
for a discussion of this detail.)
My suggestion is to move the ceph_shift_unused_folios_left() to right after ceph_process_folio_batch() to ensure it always gets called to fix up the illegal folio_batch state.
{
"affected": [],
"aliases": [
"CVE-2025-39879"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-23T06:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: always call ceph_shift_unused_folios_left()\n\nThe function ceph_process_folio_batch() sets folio_batch entries to\nNULL, which is an illegal state. Before folio_batch_release() crashes\ndue to this API violation, the function ceph_shift_unused_folios_left()\nis supposed to remove those NULLs from the array.\n\nHowever, since commit ce80b76dd327 (\"ceph: introduce\nceph_process_folio_batch() method\"), this shifting doesn\u0027t happen\nanymore because the \"for\" loop got moved to ceph_process_folio_batch(),\nand now the `i` variable that remains in ceph_writepages_start()\ndoesn\u0027t get incremented anymore, making the shifting effectively\nunreachable much of the time.\n\nLater, commit 1551ec61dc55 (\"ceph: introduce ceph_submit_write()\nmethod\") added more preconditions for doing the shift, replacing the\n`i` check (with something that is still just as broken):\n\n- if ceph_process_folio_batch() fails, shifting never happens\n\n- if ceph_move_dirty_page_in_page_array() was never called (because\n ceph_process_folio_batch() has returned early for some of various\n reasons), shifting never happens\n\n- if `processed_in_fbatch` is zero (because ceph_process_folio_batch()\n has returned early for some of the reasons mentioned above or\n because ceph_move_dirty_page_in_page_array() has failed), shifting\n never happens\n\nSince those two commits, any problem in ceph_process_folio_batch()\ncould crash the kernel, e.g. this way:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000034\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0002 [#1] SMP NOPTI\n CPU: 172 UID: 0 PID: 2342707 Comm: kworker/u778:8 Not tainted 6.15.10-cm4all1-es #714 NONE\n Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.10 12/08/2023\n Workqueue: writeback wb_workfn (flush-ceph-1)\n RIP: 0010:folios_put_refs+0x85/0x140\n Code: 83 c5 01 39 e8 7e 76 48 63 c5 49 8b 5c c4 08 b8 01 00 00 00 4d 85 ed 74 05 41 8b 44 ad 00 48 8b 15 b0 \u003e\n RSP: 0018:ffffb880af8db778 EFLAGS: 00010207\n RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000003\n RDX: ffffe377cc3b0000 RSI: 0000000000000000 RDI: ffffb880af8db8c0\n RBP: 0000000000000000 R08: 000000000000007d R09: 000000000102b86f\n R10: 0000000000000001 R11: 00000000000000ac R12: ffffb880af8db8c0\n R13: 0000000000000000 R14: 0000000000000000 R15: ffff9bd262c97000\n FS: 0000000000000000(0000) GS:ffff9c8efc303000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000034 CR3: 0000000160958004 CR4: 0000000000770ef0\n PKRU: 55555554\n Call Trace:\n \u003cTASK\u003e\n ceph_writepages_start+0xeb9/0x1410\n\nThe crash can be reproduced easily by changing the\nceph_check_page_before_write() return value to `-E2BIG`.\n\n(Interestingly, the crash happens only if `huge_zero_folio` has\nalready been allocated; without `huge_zero_folio`,\nis_huge_zero_folio(NULL) returns true and folios_put_refs() skips NULL\nentries instead of dereferencing them. That makes reproducing the bug\nsomewhat unreliable. See\nhttps://lore.kernel.org/20250826231626.218675-1-max.kellermann@ionos.com\nfor a discussion of this detail.)\n\nMy suggestion is to move the ceph_shift_unused_folios_left() to right\nafter ceph_process_folio_batch() to ensure it always gets called to\nfix up the illegal folio_batch state.",
"id": "GHSA-hq23-ggcp-mx5x",
"modified": "2025-12-12T21:31:32Z",
"published": "2025-09-23T06:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39879"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/289b6615cf553d98509a9b273195d9936da1cfb2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cce7c15faaac79b532a07ed6ab8332280ad83762"
}
],
"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-HQ29-FR4V-2847
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2024-07-03 18:42In the Linux kernel, the following vulnerability has been resolved:
s390/qeth: fix NULL deref in qeth_clear_working_pool_list()
When qeth_set_online() calls qeth_clear_working_pool_list() to roll back after an error exit from qeth_hardsetup_card(), we are at risk of accessing card->qdio.in_q before it was allocated by qeth_alloc_qdio_queues() via qeth_mpc_initialize().
qeth_clear_working_pool_list() then dereferences NULL, and by writing to queue->bufs[i].pool_entry scribbles all over the CPU's lowcore. Resulting in a crash when those lowcore areas are used next (eg. on the next machine-check interrupt).
Such a scenario would typically happen when the device is first set online and its queues aren't allocated yet. An early IO error or certain misconfigs (eg. mismatched transport mode, bad portno) then cause us to error out from qeth_hardsetup_card() with card->qdio.in_q still being NULL.
Fix it by checking the pointer for NULL before accessing it.
Note that we also have (rare) paths inside qeth_mpc_initialize() where a configuration change can cause us to free the existing queues, expecting that subsequent code will allocate them again. If we then error out before that re-allocation happens, the same bug occurs.
Root-caused-by: Heiko Carstens hca@linux.ibm.com
{
"affected": [],
"aliases": [
"CVE-2021-47369"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:22Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390/qeth: fix NULL deref in qeth_clear_working_pool_list()\n\nWhen qeth_set_online() calls qeth_clear_working_pool_list() to roll\nback after an error exit from qeth_hardsetup_card(), we are at risk of\naccessing card-\u003eqdio.in_q before it was allocated by\nqeth_alloc_qdio_queues() via qeth_mpc_initialize().\n\nqeth_clear_working_pool_list() then dereferences NULL, and by writing to\nqueue-\u003ebufs[i].pool_entry scribbles all over the CPU\u0027s lowcore.\nResulting in a crash when those lowcore areas are used next (eg. on\nthe next machine-check interrupt).\n\nSuch a scenario would typically happen when the device is first set\nonline and its queues aren\u0027t allocated yet. An early IO error or certain\nmisconfigs (eg. mismatched transport mode, bad portno) then cause us to\nerror out from qeth_hardsetup_card() with card-\u003eqdio.in_q still being\nNULL.\n\nFix it by checking the pointer for NULL before accessing it.\n\nNote that we also have (rare) paths inside qeth_mpc_initialize() where\na configuration change can cause us to free the existing queues,\nexpecting that subsequent code will allocate them again. If we then\nerror out before that re-allocation happens, the same bug occurs.\n\nRoot-caused-by: Heiko Carstens \u003chca@linux.ibm.com\u003e",
"id": "GHSA-hq29-fr4v-2847",
"modified": "2024-07-03T18:42:50Z",
"published": "2024-05-21T15:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47369"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/248f064af222a1f97ee02c84a98013dfbccad386"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b00fb12cdc9d8d1c3ffe82a78e74738127803fc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/db94f89e1dadf693c15c2d60de0c34777cea5779"
}
],
"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-HQ4C-8MM4-WQFV
Vulnerability from github – Published: 2025-01-19 12:31 – Updated: 2025-02-02 12:30In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: u_serial: Disable ep before setting port to null to fix the crash caused by port being null
Considering that in some extreme cases, when performing the unbinding operation, gserial_disconnect has cleared gser->ioport, which triggers gadget reconfiguration, and then calls gs_read_complete, resulting in access to a null pointer. Therefore, ep is disabled before gserial_disconnect sets port to null to prevent this from happening.
Call trace: gs_read_complete+0x58/0x240 usb_gadget_giveback_request+0x40/0x160 dwc3_remove_requests+0x170/0x484 dwc3_ep0_out_start+0xb0/0x1d4 __dwc3_gadget_start+0x25c/0x720 kretprobe_trampoline.cfi_jt+0x0/0x8 kretprobe_trampoline.cfi_jt+0x0/0x8 udc_bind_to_driver+0x1d8/0x300 usb_gadget_probe_driver+0xa8/0x1dc gadget_dev_desc_UDC_store+0x13c/0x188 configfs_write_iter+0x160/0x1f4 vfs_write+0x2d0/0x40c ksys_write+0x7c/0xf0 __arm64_sys_write+0x20/0x30 invoke_syscall+0x60/0x150 el0_svc_common+0x8c/0xf8 do_el0_svc+0x28/0xa0 el0_svc+0x24/0x84
{
"affected": [],
"aliases": [
"CVE-2024-57915"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-19T12:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: u_serial: Disable ep before setting port to null to fix the crash caused by port being null\n\nConsidering that in some extreme cases, when performing the\nunbinding operation, gserial_disconnect has cleared gser-\u003eioport,\nwhich triggers gadget reconfiguration, and then calls gs_read_complete,\nresulting in access to a null pointer. Therefore, ep is disabled before\ngserial_disconnect sets port to null to prevent this from happening.\n\nCall trace:\n gs_read_complete+0x58/0x240\n usb_gadget_giveback_request+0x40/0x160\n dwc3_remove_requests+0x170/0x484\n dwc3_ep0_out_start+0xb0/0x1d4\n __dwc3_gadget_start+0x25c/0x720\n kretprobe_trampoline.cfi_jt+0x0/0x8\n kretprobe_trampoline.cfi_jt+0x0/0x8\n udc_bind_to_driver+0x1d8/0x300\n usb_gadget_probe_driver+0xa8/0x1dc\n gadget_dev_desc_UDC_store+0x13c/0x188\n configfs_write_iter+0x160/0x1f4\n vfs_write+0x2d0/0x40c\n ksys_write+0x7c/0xf0\n __arm64_sys_write+0x20/0x30\n invoke_syscall+0x60/0x150\n el0_svc_common+0x8c/0xf8\n do_el0_svc+0x28/0xa0\n el0_svc+0x24/0x84",
"id": "GHSA-hq4c-8mm4-wqfv",
"modified": "2025-02-02T12:30:25Z",
"published": "2025-01-19T12:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57915"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c50f00cc29948184af05bda31392fff5821f4f3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1062b648bff63ed62b2d47a045e08ea9741d98ea"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13014969cbf07f18d62ceea40bd8ca8ec9d36cec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d730e8758c75b68a0152ee1ac48a270ea6725b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8e122d780a0f19aefd700dbd0b0e3ed3af0ae97f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2de56cc45ee447f005d63217e84988b4f02faa9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5f33fb57aae12e4b0add79e0242f458ea0bc510"
}
],
"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-HQ79-5P4Q-XV2W
Vulnerability from github – Published: 2024-07-30 09:31 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add NULL pointer check for kzalloc
[Why & How] Check return pointer of kzalloc before using it.
{
"affected": [],
"aliases": [
"CVE-2024-42122"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-30T08:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add NULL pointer check for kzalloc\n\n[Why \u0026 How]\nCheck return pointer of kzalloc before using it.",
"id": "GHSA-hq79-5p4q-xv2w",
"modified": "2025-11-03T21:31:11Z",
"published": "2024-07-30T09:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42122"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/062edd612fcd300f0f79a36fca5b8b6a5e2fce70"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/552e7938b4d7fe548fbf29b9950a14c6149d0470"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8e65a1b7118acf6af96449e1e66b7adbc9396912"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd1e565a5b7fa60c349ca8a16db1e61715fe8230"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.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-HQ82-5FCG-H8H8
Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2022-06-17 00:01Wind River VxWorks 6.9 and vx7 has an array index error in the IGMPv3 client component. There is an IPNET security vulnerability: DoS via NULL dereference in IGMP parsing.
{
"affected": [],
"aliases": [
"CVE-2019-12259"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-09T19:15:00Z",
"severity": "HIGH"
},
"details": "Wind River VxWorks 6.9 and vx7 has an array index error in the IGMPv3 client component. There is an IPNET security vulnerability: DoS via NULL dereference in IGMP parsing.",
"id": "GHSA-hq82-5fcg-h8h8",
"modified": "2022-06-17T00:01:23Z",
"published": "2022-05-24T16:53:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12259"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-189842.pdf"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-352504.pdf"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-632562.pdf"
},
{
"type": "WEB",
"url": "https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2019-0009"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190802-0001"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K41190253"
},
{
"type": "WEB",
"url": "https://support2.windriver.com/index.php?page=cve\u0026on=view\u0026id=CVE-2019-12259"
},
{
"type": "WEB",
"url": "https://support2.windriver.com/index.php?page=security-notices"
},
{
"type": "WEB",
"url": "https://www.windriver.com/security/announcements/tcp-ip-network-stack-ipnet-urgent11"
}
],
"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"
}
]
}
Mitigation MIT-56
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
Select a programming language that is not susceptible to these issues.
Mitigation
Check the results of all functions that return a value and verify that the value is non-null before acting upon it.
Mitigation
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
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.