CWE-476
AllowedNULL Pointer Dereference
Abstraction: Base · Status: Stable
The product dereferences a pointer that it expects to be valid but is NULL.
6310 vulnerabilities reference this CWE, most recent first.
GHSA-5H7H-63PX-44W7
Vulnerability from github – Published: 2022-05-24 19:08 – Updated: 2022-05-24 19:08An issue has been found in function EmbedStream::getChar in PDF2JSON 0.70 that allows attackers to cause a Denial of Service due to a null pointer derefenrece (invalid read of size 8) .
{
"affected": [],
"aliases": [
"CVE-2020-19468"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-21T18:15:00Z",
"severity": "MODERATE"
},
"details": "An issue has been found in function EmbedStream::getChar in PDF2JSON 0.70 that allows attackers to cause a Denial of Service due to a null pointer derefenrece (invalid read of size 8) .",
"id": "GHSA-5h7h-63px-44w7",
"modified": "2022-05-24T19:08:33Z",
"published": "2022-05-24T19:08:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-19468"
},
{
"type": "WEB",
"url": "https://github.com/flexpaper/pdf2json/issues/29"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5H89-MF56-355J
Vulnerability from github – Published: 2025-06-08 12:30 – Updated: 2025-06-08 12:30in OpenHarmony v5.0.3 and prior versions allow a local attacker case DOS through NULL pointer dereference.
{
"affected": [],
"aliases": [
"CVE-2025-25217"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-08T12:15:21Z",
"severity": "LOW"
},
"details": "in OpenHarmony v5.0.3 and prior versions allow a local attacker case DOS through NULL pointer dereference.",
"id": "GHSA-5h89-mf56-355j",
"modified": "2025-06-08T12:30:33Z",
"published": "2025-06-08T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25217"
},
{
"type": "WEB",
"url": "https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2025/2025-06.md"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-5H99-7732-G93R
Vulnerability from github – Published: 2026-04-22 12:30 – Updated: 2026-04-22 12:30If you use the zoneToCache function with a malicious authoritative server, an attacker can send a zone that result in a null pointer dereference, caused by a missing consistency check and leading to a denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-33601"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T10:16:52Z",
"severity": "MODERATE"
},
"details": "If you use the zoneToCache function with a malicious authoritative server, an attacker can send a zone that result in a null pointer dereference, caused by a missing consistency check and leading to a denial of service.",
"id": "GHSA-5h99-7732-g93r",
"modified": "2026-04-22T12:30:30Z",
"published": "2026-04-22T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33601"
},
{
"type": "WEB",
"url": "https://docs.powerdns.com/recursor/security-advisories/powerdns-advisory-powerdns-2026-03.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5HFJ-3VGW-HM4R
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-19 15:33In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: Prevent NULL deref when RX memory exhausted
The CPU receives frames from the MAC through conventional DMA: the CPU allocates buffers for the MAC, then the MAC fills them and returns ownership to the CPU. For each hardware RX queue, the CPU and MAC coordinate through a shared ring array of DMA descriptors: one descriptor per DMA buffer. Each descriptor includes the buffer's physical address and a status flag ("OWN") indicating which side owns the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set the flag and the MAC is only allowed to clear it, and both must move through the ring in sequence: thus the ring is used for both "submissions" and "completions."
In the stmmac driver, stmmac_rx() bookmarks its position in the ring
with the cur_rx index. The main receive loop in that function checks
for rx_descs[cur_rx].own=0, gives the corresponding buffer to the
network stack (NULLing the pointer), and increments cur_rx modulo the
ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its
position with dirty_rx, allocates fresh buffers and rearms the
descriptors (setting OWN=1). If it fails any allocation, it simply stops
early (leaving OWN=0) and will retry where it left off when next called.
This means descriptors have a three-stage lifecycle (terms my own):
- empty (OWN=1, buffer valid)
- full (OWN=0, buffer valid and populated)
- dirty (OWN=0, buffer NULL)
But because stmmac_rx() only checks OWN, it confuses full/dirty. In
the past (see 'Fixes:'), there was a bug where the loop could cycle
cur_rx all the way back to the first descriptor it dirtied, resulting
in a NULL dereference when mistaken for full. The aforementioned
commit resolved that specific failure by capping the loop's iteration
limit at dma_rx_size - 1, but this is only a partial fix: if the
previous stmmac_rx_refill() didn't complete, then there are leftover
dirty descriptors that the loop might encounter without needing to
cycle fully around. The current code therefore panics (see 'Closes:')
when stmmac_rx_refill() is memory-starved long enough for cur_rx to
catch up to dirty_rx.
Fix this by explicitly checking, before advancing cur_rx, if the next
entry is dirty; exit the loop if so. This prevents processing of the
final, used descriptor until stmmac_rx_refill() succeeds, but
fully prevents the cur_rx == dirty_rx ambiguity as the previous bugfix
intended: so remove the clamp as well. Since stmmac_rx_zc() is a
copy-paste-and-tweak of stmmac_rx() and the code structure is identical,
any fix to stmmac_rx() will also need a corresponding fix for
stmmac_rx_zc(). Therefore, apply the same check there.
In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the
MAC sets OWN=0 on the final descriptor, it will be unable to send any
further DMA-complete IRQs until it's given more empty descriptors.
Currently, the driver simply hopes that the next stmmac_rx_refill()
succeeds, risking an indefinite stall of the receive process if not. But
this is not a regression, so it can be addressed in a future change.
{
"affected": [],
"aliases": [
"CVE-2026-46110"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:26Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: Prevent NULL deref when RX memory exhausted\n\nThe CPU receives frames from the MAC through conventional DMA: the CPU\nallocates buffers for the MAC, then the MAC fills them and returns\nownership to the CPU. For each hardware RX queue, the CPU and MAC\ncoordinate through a shared ring array of DMA descriptors: one\ndescriptor per DMA buffer. Each descriptor includes the buffer\u0027s\nphysical address and a status flag (\"OWN\") indicating which side owns\nthe buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set\nthe flag and the MAC is only allowed to clear it, and both must move\nthrough the ring in sequence: thus the ring is used for both\n\"submissions\" and \"completions.\"\n\nIn the stmmac driver, stmmac_rx() bookmarks its position in the ring\nwith the `cur_rx` index. The main receive loop in that function checks\nfor rx_descs[cur_rx].own=0, gives the corresponding buffer to the\nnetwork stack (NULLing the pointer), and increments `cur_rx` modulo the\nring size. After the loop exits, stmmac_rx_refill(), which bookmarks its\nposition with `dirty_rx`, allocates fresh buffers and rearms the\ndescriptors (setting OWN=1). If it fails any allocation, it simply stops\nearly (leaving OWN=0) and will retry where it left off when next called.\n\nThis means descriptors have a three-stage lifecycle (terms my own):\n- `empty` (OWN=1, buffer valid)\n- `full` (OWN=0, buffer valid and populated)\n- `dirty` (OWN=0, buffer NULL)\n\nBut because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In\nthe past (see \u0027Fixes:\u0027), there was a bug where the loop could cycle\n`cur_rx` all the way back to the first descriptor it dirtied, resulting\nin a NULL dereference when mistaken for `full`. The aforementioned\ncommit resolved that *specific* failure by capping the loop\u0027s iteration\nlimit at `dma_rx_size - 1`, but this is only a partial fix: if the\nprevious stmmac_rx_refill() didn\u0027t complete, then there are leftover\n`dirty` descriptors that the loop might encounter without needing to\ncycle fully around. The current code therefore panics (see \u0027Closes:\u0027)\nwhen stmmac_rx_refill() is memory-starved long enough for `cur_rx` to\ncatch up to `dirty_rx`.\n\nFix this by explicitly checking, before advancing `cur_rx`, if the next\nentry is dirty; exit the loop if so. This prevents processing of the\nfinal, used descriptor until stmmac_rx_refill() succeeds, but\nfully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix\nintended: so remove the clamp as well. Since stmmac_rx_zc() is a\ncopy-paste-and-tweak of stmmac_rx() and the code structure is identical,\nany fix to stmmac_rx() will also need a corresponding fix for\nstmmac_rx_zc(). Therefore, apply the same check there.\n\nIn stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the\nMAC sets OWN=0 on the final descriptor, it will be unable to send any\nfurther DMA-complete IRQs until it\u0027s given more `empty` descriptors.\nCurrently, the driver simply *hopes* that the next stmmac_rx_refill()\nsucceeds, risking an indefinite stall of the receive process if not. But\nthis is not a regression, so it can be addressed in a future change.",
"id": "GHSA-5hfj-3vgw-hm4r",
"modified": "2026-06-19T15:33:13Z",
"published": "2026-05-28T12:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46110"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0bb05e6adfa99a2ea1fee1125cc0953409f83ed8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4af2e62cbcda575a174acd230c3f3a208135e16d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c910f7708e3c507b037ca91ca5b09f8cfe71e65"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/950cb436165aad0f8f2cd49da3cd07677465bcde"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e1c50b273298c7cd9b08b113e7a7598b531a02f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fdeb95b1fc7de25c9362990efb9996a8d761055c"
}
],
"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-5HG4-WC97-MW4M
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-05-24 17:42In PHP versions 7.3.x below 7.3.27, 7.4.x below 7.4.15 and 8.0.x below 8.0.2, when using SOAP extension to connect to a SOAP server, a malicious SOAP server could return malformed XML data as a response that would cause PHP to access a null pointer and thus cause a crash.
{
"affected": [],
"aliases": [
"CVE-2021-21702"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-15T04:15:00Z",
"severity": "HIGH"
},
"details": "In PHP versions 7.3.x below 7.3.27, 7.4.x below 7.4.15 and 8.0.x below 8.0.2, when using SOAP extension to connect to a SOAP server, a malicious SOAP server could return malformed XML data as a response that would cause PHP to access a null pointer and thus cause a crash.",
"id": "GHSA-5hg4-wc97-mw4m",
"modified": "2022-05-24T17:42:15Z",
"published": "2022-05-24T17:42:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21702"
},
{
"type": "WEB",
"url": "https://bugs.php.net/bug.php?id=80672"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/07/msg00008.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202105-23"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210312-0005"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4856"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/tns-2021-14"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5HGQ-F2QX-82G9
Vulnerability from github – Published: 2024-08-21 09:31 – Updated: 2024-09-06 15:32In the Linux kernel, the following vulnerability has been resolved:
tty: fix possible null-ptr-defer in spk_ttyio_release
Run the following tests on the qemu platform:
syzkaller:~# modprobe speakup_audptr input: Speakup as /devices/virtual/input/input4 initialized device: /dev/synth, node (MAJOR 10, MINOR 125) speakup 3.1.6: initialized synth name on entry is: (null) synth probe
spk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned failed (errno -16), then remove the module, we will get a null-ptr-defer problem, as follow:
syzkaller:~# modprobe -r speakup_audptr releasing synth audptr BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1 RIP: 0010:mutex_lock+0x14/0x30 Call Trace: spk_ttyio_release+0x19/0x70 [speakup] synth_release.part.6+0xac/0xc0 [speakup] synth_remove+0x56/0x60 [speakup] __x64_sys_delete_module+0x156/0x250 ? fpregs_assert_state_consistent+0x1d/0x50 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Modules linked in: speakup_audptr(-) speakup Dumping ftrace buffer:
in_synth->dev was not initialized during modprobe, so we add check for in_synth->dev to fix this bug.
{
"affected": [],
"aliases": [
"CVE-2022-48870"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T07:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: fix possible null-ptr-defer in spk_ttyio_release\n\nRun the following tests on the qemu platform:\n\nsyzkaller:~# modprobe speakup_audptr\n input: Speakup as /devices/virtual/input/input4\n initialized device: /dev/synth, node (MAJOR 10, MINOR 125)\n speakup 3.1.6: initialized\n synth name on entry is: (null)\n synth probe\n\nspk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned\nfailed (errno -16), then remove the module, we will get a null-ptr-defer\nproblem, as follow:\n\nsyzkaller:~# modprobe -r speakup_audptr\n releasing synth audptr\n BUG: kernel NULL pointer dereference, address: 0000000000000080\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0\n Oops: 0002 [#1] PREEMPT SMP PTI\n CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1\n RIP: 0010:mutex_lock+0x14/0x30\n Call Trace:\n \u003cTASK\u003e\n spk_ttyio_release+0x19/0x70 [speakup]\n synth_release.part.6+0xac/0xc0 [speakup]\n synth_remove+0x56/0x60 [speakup]\n __x64_sys_delete_module+0x156/0x250\n ? fpregs_assert_state_consistent+0x1d/0x50\n do_syscall_64+0x37/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n \u003c/TASK\u003e\n Modules linked in: speakup_audptr(-) speakup\n Dumping ftrace buffer:\n\nin_synth-\u003edev was not initialized during modprobe, so we add check\nfor in_synth-\u003edev to fix this bug.",
"id": "GHSA-5hgq-f2qx-82g9",
"modified": "2024-09-06T15:32:56Z",
"published": "2024-08-21T09:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48870"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2da67bff29ab49caafb0766e8b8383b735ff796f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5abbeebd8296c2301023b8dc4b5a6c0d5229b4f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64152e05a4de3ebf59f1740a0985a6d5fba0c77b"
}
],
"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-5HP5-2VG6-W8H9
Vulnerability from github – Published: 2025-07-04 15:31 – Updated: 2025-12-18 18:30In the Linux kernel, the following vulnerability has been resolved:
calipso: Fix null-ptr-deref in calipso_req_{set,del}attr().
syzkaller reported a null-ptr-deref in sock_omalloc() while allocating a CALIPSO option. [0]
The NULL is of struct sock, which was fetched by sk_to_full_sk() in calipso_req_setattr().
Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"), reqsk->rsk_listener could be NULL when SYN Cookie is returned to its client, as hinted by the leading SYN Cookie log.
Here are 3 options to fix the bug:
1) Return 0 in calipso_req_setattr() 2) Return an error in calipso_req_setattr() 3) Alaways set rsk_listener
1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie for CALIPSO. 3) is also no go as there have been many efforts to reduce atomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood").
As of the blamed commit, SYN Cookie already did not need refcounting, and no one has stumbled on the bug for 9 years, so no CALIPSO user will care about SYN Cookie.
Let's return an error in calipso_req_setattr() and calipso_req_delattr() in the SYN Cookie case.
This can be reproduced by [1] on Fedora and now connect() of nc times out.
[0]: TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline] RIP: 0010:sock_net include/net/sock.h:655 [inline] RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806 Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b RSP: 0018:ffff88811af89038 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400 RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030 RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000 R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050 FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288 calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204 calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597 netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249 selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342 selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551 security_inet_conn_request+0x50/0xa0 security/security.c:4945 tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825 tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275 tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328 tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781 tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667 tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904 ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436 ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491 dst_input include/net/dst.h:469 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netf ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-38181"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-04T14:15:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncalipso: Fix null-ptr-deref in calipso_req_{set,del}attr().\n\nsyzkaller reported a null-ptr-deref in sock_omalloc() while allocating\na CALIPSO option. [0]\n\nThe NULL is of struct sock, which was fetched by sk_to_full_sk() in\ncalipso_req_setattr().\n\nSince commit a1a5344ddbe8 (\"tcp: avoid two atomic ops for syncookies\"),\nreqsk-\u003ersk_listener could be NULL when SYN Cookie is returned to its\nclient, as hinted by the leading SYN Cookie log.\n\nHere are 3 options to fix the bug:\n\n 1) Return 0 in calipso_req_setattr()\n 2) Return an error in calipso_req_setattr()\n 3) Alaways set rsk_listener\n\n1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie\nfor CALIPSO. 3) is also no go as there have been many efforts to reduce\natomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35\n(\"tcp/dccp: do not touch listener sk_refcnt under synflood\").\n\nAs of the blamed commit, SYN Cookie already did not need refcounting,\nand no one has stumbled on the bug for 9 years, so no CALIPSO user will\ncare about SYN Cookie.\n\nLet\u0027s return an error in calipso_req_setattr() and calipso_req_delattr()\nin the SYN Cookie case.\n\nThis can be reproduced by [1] on Fedora and now connect() of nc times out.\n\n[0]:\nTCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies.\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\nCPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:read_pnet include/net/net_namespace.h:406 [inline]\nRIP: 0010:sock_net include/net/sock.h:655 [inline]\nRIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806\nCode: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u003c80\u003e 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b\nRSP: 0018:ffff88811af89038 EFLAGS: 00010216\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400\nRDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030\nRBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e\nR10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000\nR13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050\nFS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0\nPKRU: 80000000\nCall Trace:\n \u003cIRQ\u003e\n ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288\n calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204\n calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597\n netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249\n selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342\n selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551\n security_inet_conn_request+0x50/0xa0 security/security.c:4945\n tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825\n tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275\n tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328\n tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781\n tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667\n tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904\n ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436\n ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480\n NF_HOOK include/linux/netfilter.h:314 [inline]\n NF_HOOK include/linux/netfilter.h:308 [inline]\n ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491\n dst_input include/net/dst.h:469 [inline]\n ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]\n ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69\n NF_HOOK include/linux/netfilter.h:314 [inline]\n NF_HOOK include/linux/netf\n---truncated---",
"id": "GHSA-5hp5-2vg6-w8h9",
"modified": "2025-12-18T18:30:28Z",
"published": "2025-07-04T15:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38181"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/058dd4a370f23a5553a9449f2db53d5bfa88d45e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10876da918fa1aec0227fb4c67647513447f53a9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/956f1499412ed0953f6a116df7fdb855e9f1fc66"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/988edde4d52d5c02ea4dd95d7619372a5e2fb7b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bde8833eb075ba8e8674de88e32de6b669966451"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d092c7fd8e220b23d6c47e03d7d0cc79e731f379"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dc724bd34d56f5589f7587a091a8cda2386826c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f4ae0f61dd9a63329ecb49b1e6356139d43240b8"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-5HR7-CGH9-28W9
Vulnerability from github – Published: 2024-04-11 21:30 – Updated: 2024-09-06 21:32Null Pointer Dereference vulnerability in swfdump in swftools 0.9.2 allows attackers to crash the appliation via the function compileSWFActionCode in action/actioncompiler.c.
{
"affected": [],
"aliases": [
"CVE-2024-28458"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-11T21:15:08Z",
"severity": "HIGH"
},
"details": "Null Pointer Dereference vulnerability in swfdump in swftools 0.9.2 allows attackers to crash the appliation via the function compileSWFActionCode in action/actioncompiler.c.",
"id": "GHSA-5hr7-cgh9-28w9",
"modified": "2024-09-06T21:32:27Z",
"published": "2024-04-11T21:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28458"
},
{
"type": "WEB",
"url": "https://github.com/keepinggg/poc/blob/main/poc_of_swfc"
}
],
"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-5HRP-C5G3-4MGQ
Vulnerability from github – Published: 2022-05-17 00:18 – Updated: 2022-05-17 00:18VMware Workstation (12.x before 12.5.8) and Fusion (8.x before 8.5.9) contain a guest RPC NULL pointer dereference vulnerability. Successful exploitation of this issue may allow attackers with normal user privileges to crash their VMs.
{
"affected": [],
"aliases": [
"CVE-2017-4938"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-17T14:29:00Z",
"severity": "MODERATE"
},
"details": "VMware Workstation (12.x before 12.5.8) and Fusion (8.x before 8.5.9) contain a guest RPC NULL pointer dereference vulnerability. Successful exploitation of this issue may allow attackers with normal user privileges to crash their VMs.",
"id": "GHSA-5hrp-c5g3-4mgq",
"modified": "2022-05-17T00:18:39Z",
"published": "2022-05-17T00:18:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-4938"
},
{
"type": "WEB",
"url": "https://www.vmware.com/security/advisories/VMSA-2017-0018.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/101887"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1039835"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5HV8-XRRG-HM72
Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-02-10 15:30In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Check for probe() id argument being NULL
The probe() id argument may be NULL in 2 scenarios:
-
brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe the device.
-
If a user tries to manually bind the driver from sysfs then the sdio / pcie / usb probe() function gets called with NULL as id argument.
-
Is being hit by users causing the following oops on resume and causing wifi to stop working:
BUG: kernel NULL pointer dereference, address: 0000000000000018 Hardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020 Workgueue: events_unbound async_run_entry_fn RIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac] Call Trace: brcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887] ? pci_pm_resume+0x5b/0xf0 ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x47/0x150 device_resume+0xa2/0x1f0 async_resume+0x1d/0x30
Fix this by checking for id being NULL.
In the PCI and USB cases try a manual lookup of the id so that manually binding the driver through sysfs and more importantly brcmf_pcie_probe() on resume will work.
For the SDIO case there is no helper to do a manual sdio_device_id lookup, so just directly error out on a NULL id there.
{
"affected": [],
"aliases": [
"CVE-2023-53565"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T16:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Check for probe() id argument being NULL\n\nThe probe() id argument may be NULL in 2 scenarios:\n\n1. brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe\n the device.\n\n2. If a user tries to manually bind the driver from sysfs then the sdio /\n pcie / usb probe() function gets called with NULL as id argument.\n\n1. Is being hit by users causing the following oops on resume and causing\nwifi to stop working:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000018\n\u003csnip\u003e\nHardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020\nWorkgueue: events_unbound async_run_entry_fn\nRIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac]\n\u003csnip\u003e\nCall Trace:\n \u003cTASK\u003e\n brcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887]\n ? pci_pm_resume+0x5b/0xf0\n ? pci_legacy_resume+0x80/0x80\n dpm_run_callback+0x47/0x150\n device_resume+0xa2/0x1f0\n async_resume+0x1d/0x30\n\u003csnip\u003e\n\nFix this by checking for id being NULL.\n\nIn the PCI and USB cases try a manual lookup of the id so that manually\nbinding the driver through sysfs and more importantly brcmf_pcie_probe()\non resume will work.\n\nFor the SDIO case there is no helper to do a manual sdio_device_id lookup,\nso just directly error out on a NULL id there.",
"id": "GHSA-5hv8-xrrg-hm72",
"modified": "2026-02-10T15:30:20Z",
"published": "2025-10-04T18:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53565"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60fc756fc8e6954a5618eecac73b255d651602e4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84766e77a5c35e2b60e34f570c62fc97adc05e09"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-56
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.