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-HGMQ-893H-GWR8
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-15 21:31In the Linux kernel, the following vulnerability has been resolved:
interconnect: qcom: sm8450: Fix NULL pointer dereference in icc_link_nodes()
The change to dynamic IDs for SM8450 platform interconnects left two links unconverted, fix it to avoid the NULL pointer dereference in runtime, when a pointer to a destination interconnect is not valid:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
<...>
Call trace:
icc_link_nodes+0x3c/0x100 (P)
qcom_icc_rpmh_probe+0x1b4/0x528
platform_probe+0x64/0xc0
really_probe+0xc4/0x2a8
__driver_probe_device+0x80/0x140
driver_probe_device+0x48/0x170
__device_attach_driver+0xc0/0x148
bus_for_each_drv+0x88/0xf0
__device_attach+0xb0/0x1c0
device_initial_probe+0x58/0x68
bus_probe_device+0x40/0xb8
deferred_probe_work_func+0x90/0xd0
process_one_work+0x15c/0x3c0
worker_thread+0x2e8/0x400
kthread+0x150/0x208
ret_from_fork+0x10/0x20
Code: 900310f4 911d6294 91008280 94176078 (f94002a0)
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Oops: Fatal exception
{
"affected": [],
"aliases": [
"CVE-2026-43335"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ninterconnect: qcom: sm8450: Fix NULL pointer dereference in icc_link_nodes()\n\nThe change to dynamic IDs for SM8450 platform interconnects left two links\nunconverted, fix it to avoid the NULL pointer dereference in runtime,\nwhen a pointer to a destination interconnect is not valid:\n\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008\n \u003c...\u003e\n Call trace:\n icc_link_nodes+0x3c/0x100 (P)\n qcom_icc_rpmh_probe+0x1b4/0x528\n platform_probe+0x64/0xc0\n really_probe+0xc4/0x2a8\n __driver_probe_device+0x80/0x140\n driver_probe_device+0x48/0x170\n __device_attach_driver+0xc0/0x148\n bus_for_each_drv+0x88/0xf0\n __device_attach+0xb0/0x1c0\n device_initial_probe+0x58/0x68\n bus_probe_device+0x40/0xb8\n deferred_probe_work_func+0x90/0xd0\n process_one_work+0x15c/0x3c0\n worker_thread+0x2e8/0x400\n kthread+0x150/0x208\n ret_from_fork+0x10/0x20\n Code: 900310f4 911d6294 91008280 94176078 (f94002a0)\n ---[ end trace 0000000000000000 ]---\n Kernel panic - not syncing: Oops: Fatal exception",
"id": "GHSA-hgmq-893h-gwr8",
"modified": "2026-05-15T21:31:30Z",
"published": "2026-05-08T15:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43335"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/77d22bf3fc5d1bcdee035979b07840c9c2ece8f2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dbbd550d7c8d90d3af9fe8a12a9caff077ddb8e3"
}
],
"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-HGQW-CWMR-4H32
Vulnerability from github – Published: 2024-12-29 12:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c
Add error pointer check after calling otx2_mbox_get_rsp().
{
"affected": [],
"aliases": [
"CVE-2024-56726"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-29T12:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c\n\nAdd error pointer check after calling otx2_mbox_get_rsp().",
"id": "GHSA-hgqw-cwmr-4h32",
"modified": "2025-11-03T21:32:02Z",
"published": "2024-12-29T12:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56726"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41f39f4c67253f802809310be6846ff408c3c758"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/54abcec092616a4d01195355eb5d6036fb8fe363"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/856ad633e11869729be698df2287ecfe6ec31f27"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a374e7e79fbdd7574bd89344447b0d4b91ba9801"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac9183023b6a9c09467516abd8aab04f9a2f9564"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5a6c5af434671aea739a5a41c849819144f02c9"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.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-HGW6-479W-27JJ
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Properly link new fs rules into the tree
Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones.
These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL.
This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1].
This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle.
{
"affected": [],
"aliases": [
"CVE-2024-35960"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:11Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Properly link new fs rules into the tree\n\nPreviously, add_rule_fg would only add newly created rules from the\nhandle into the tree when they had a refcount of 1. On the other hand,\ncreate_flow_handle tries hard to find and reference already existing\nidentical rules instead of creating new ones.\n\nThese two behaviors can result in a situation where create_flow_handle\n1) creates a new rule and references it, then\n2) in a subsequent step during the same handle creation references it\n again,\nresulting in a rule with a refcount of 2 that is not linked into the\ntree, will have a NULL parent and root and will result in a crash when\nthe flow group is deleted because del_sw_hw_rule, invoked on rule\ndeletion, assumes node-\u003eparent is != NULL.\n\nThis happened in the wild, due to another bug related to incorrect\nhandling of duplicate pkt_reformat ids, which lead to the code in\ncreate_flow_handle incorrectly referencing a just-added rule in the same\nflow handle, resulting in the problem described above. Full details are\nat [1].\n\nThis patch changes add_rule_fg to add new rules without parents into\nthe tree, properly initializing them and avoiding the crash. This makes\nit more consistent with how rules are added to an FTE in\ncreate_flow_handle.",
"id": "GHSA-hgw6-479w-27jj",
"modified": "2026-05-12T12:31:51Z",
"published": "2024-05-20T12:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35960"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1263b0b26077b1183c3c45a0a2479573a351d423"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2e8dc5cffc844dacfa79f056dea88002312f253f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d90ca9145f6b97b38d0c2b6b30f6ca6af9c1801"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5cf5337ef701830f173b4eec00a4f984adeb57a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7aaee12b804c5e0374e7b132b6ec2158ff33dd64"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c6782ad4911cbee874e85630226ed389ff2e453"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/adf67a03af39095f05d82050f15813d6f700159d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de0139719cdda82806a47580ca0df06fc85e0bd2"
},
{
"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:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HH7M-36V5-42F5
Vulnerability from github – Published: 2022-05-17 02:25 – Updated: 2022-05-17 02:25An issue was discovered in certain Apple products. macOS before 10.12.2 is affected. The issue involves the "CoreStorage" component. It allows local users to cause a denial of service (NULL pointer dereference) via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2016-7603"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-02-20T08:59:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in certain Apple products. macOS before 10.12.2 is affected. The issue involves the \"CoreStorage\" component. It allows local users to cause a denial of service (NULL pointer dereference) via unspecified vectors.",
"id": "GHSA-hh7m-36v5-42f5",
"modified": "2022-05-17T02:25:30Z",
"published": "2022-05-17T02:25:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-7603"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT207423"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/94903"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1037469"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HH96-P296-X7M4
Vulnerability from github – Published: 2024-05-17 12:31 – Updated: 2024-07-03 18:42In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs
It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped.
Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames
In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list.
Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800
Lecroy shows one byte coming in extra confirming that the byte is coming in from PC:
Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)
According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize.
{
"affected": [],
"aliases": [
"CVE-2024-27405"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T12:15:10Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs\n\nIt is observed sometimes when tethering is used over NCM with Windows 11\nas host, at some instances, the gadget_giveback has one byte appended at\nthe end of a proper NTB. When the NTB is parsed, unwrap call looks for\nany leftover bytes in SKB provided by u_ether and if there are any pending\nbytes, it treats them as a separate NTB and parses it. But in case the\nsecond NTB (as per unwrap call) is faulty/corrupt, all the datagrams that\nwere parsed properly in the first NTB and saved in rx_list are dropped.\n\nAdding a few custom traces showed the following:\n[002] d..1 7828.532866: dwc3_gadget_giveback: ep1out:\nreq 000000003868811a length 1025/16384 zsI ==\u003e 0\n[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025\n[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342\n[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67\n[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400\n[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10\n[002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames\n\nIn this case, the giveback is of 1025 bytes and block length is 1024.\nThe rest 1 byte (which is 0x00) won\u0027t be parsed resulting in drop of\nall datagrams in rx_list.\n\nSame is case with packets of size 2048:\n[002] d..1 7828.557948: dwc3_gadget_giveback: ep1out:\nreq 0000000011dfd96e length 2049/16384 zsI ==\u003e 0\n[002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342\n[002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800\n\nLecroy shows one byte coming in extra confirming that the byte is coming\nin from PC:\n\n Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590)\n - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)\n --- Packet 4063861\n Data(1024 bytes)\n Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)\n --- Packet 4063863\n Data(1 byte)\n Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)\n\nAccording to Windows driver, no ZLP is needed if wBlockLength is non-zero,\nbecause the non-zero wBlockLength has already told the function side the\nsize of transfer to be expected. However, there are in-market NCM devices\nthat rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.\nTo deal with such devices, it pads an extra 0 at end so the transfer is no\nlonger multiple of wMaxPacketSize.",
"id": "GHSA-hh96-p296-x7m4",
"modified": "2024-07-03T18:42:21Z",
"published": "2024-05-17T12:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27405"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/059285e04ebb273d32323fbad5431c5b94f77e48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b7ec68869d50ea998908af43b643bca7e54577e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cb66b62a5d64ccf09b0591ab86fb085fa491fc5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35b604a37ec70d68b19dafd10bbacf1db505c9ca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/57ca0e16f393bb21d69734e536e383a3a4c665fd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/76c51146820c5dac629f21deafab0a7039bc3ccd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a31cf46d108dabce3df80b3e5c07661e24912151"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7f43900bc723203d7554d299a2ce844054fab8e"
},
{
"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:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HH9V-PV5P-4675
Vulnerability from github – Published: 2025-02-11 18:31 – Updated: 2025-02-11 18:31Substance3D - Stager versions 3.1.0 and earlier are affected by a NULL Pointer Dereference vulnerability that could result in an application denial-of-service. An attacker could exploit this vulnerability to crash the application, leading to a denial-of-service condition. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
{
"affected": [],
"aliases": [
"CVE-2025-21155"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-11T18:15:27Z",
"severity": "MODERATE"
},
"details": "Substance3D - Stager versions 3.1.0 and earlier are affected by a NULL Pointer Dereference vulnerability that could result in an application denial-of-service. An attacker could exploit this vulnerability to crash the application, leading to a denial-of-service condition. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
"id": "GHSA-hh9v-pv5p-4675",
"modified": "2025-02-11T18:31:36Z",
"published": "2025-02-11T18:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21155"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/substance3d_stager/apsb25-09.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HHHP-JPJM-PG9W
Vulnerability from github – Published: 2022-05-14 03:43 – Updated: 2022-05-14 03:43ccnl-ext-mgmt.c in CCN-lite before 2.00 allows context-dependent attackers to have unspecified impact by leveraging missing NULL pointer checks after ccnl_malloc.
{
"affected": [],
"aliases": [
"CVE-2017-12472"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-02-07T17:29:00Z",
"severity": "CRITICAL"
},
"details": "ccnl-ext-mgmt.c in CCN-lite before 2.00 allows context-dependent attackers to have unspecified impact by leveraging missing NULL pointer checks after ccnl_malloc.",
"id": "GHSA-hhhp-jpjm-pg9w",
"modified": "2022-05-14T03:43:37Z",
"published": "2022-05-14T03:43:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12472"
},
{
"type": "WEB",
"url": "https://github.com/cn-uofbasel/ccn-lite/issues/138"
},
{
"type": "WEB",
"url": "https://github.com/cn-uofbasel/ccn-lite/releases/tag/2.0.0"
}
],
"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-HHJ3-J6PG-F7MV
Vulnerability from github – Published: 2025-07-03 09:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
x86/iopl: Cure TIF_IO_BITMAP inconsistencies
io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork().
io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference.
There are two issues, which lead to that problem:
1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork().
2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated.
This happens when a kernel thread is created in the context of
a user space thread, which has TIF_IO_BITMAP set as the thread
flags are copied and the IO bitmap pointer is cleared.
Other than in the failed fork() case this has no impact because
kernel threads including IO workers never return to user space and
therefore never invoke tss_update_io_bitmap().
Cure this by adding the missing cleanups and checks:
1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task.
2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share().
For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state.
{
"affected": [],
"aliases": [
"CVE-2025-38100"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-03T09:15:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/iopl: Cure TIF_IO_BITMAP inconsistencies\n\nio_bitmap_exit() is invoked from exit_thread() when a task exists or\nwhen a fork fails. In the latter case the exit_thread() cleans up\nresources which were allocated during fork().\n\nio_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up\nin tss_update_io_bitmap(). tss_update_io_bitmap() operates on the\ncurrent task. If current has TIF_IO_BITMAP set, but no bitmap installed,\ntss_update_io_bitmap() crashes with a NULL pointer dereference.\n\nThere are two issues, which lead to that problem:\n\n 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when\n the task, which is cleaned up, is not the current task. That\u0027s a\n clear indicator for a cleanup after a failed fork().\n\n 2) A task should not have TIF_IO_BITMAP set and neither a bitmap\n installed nor IOPL emulation level 3 activated.\n\n This happens when a kernel thread is created in the context of\n a user space thread, which has TIF_IO_BITMAP set as the thread\n flags are copied and the IO bitmap pointer is cleared.\n\n Other than in the failed fork() case this has no impact because\n kernel threads including IO workers never return to user space and\n therefore never invoke tss_update_io_bitmap().\n\nCure this by adding the missing cleanups and checks:\n\n 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if\n the to be cleaned up task is not the current task.\n\n 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user\n space forks it is set later, when the IO bitmap is inherited in\n io_bitmap_share().\n\nFor paranoia sake, add a warning into tss_update_io_bitmap() to catch\nthe case, when that code is invoked with inconsistent state.",
"id": "GHSA-hhj3-j6pg-f7mv",
"modified": "2026-05-12T15:30:53Z",
"published": "2025-07-03T09:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38100"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cfcbe1554c119402e7382de974c26b0549899fe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2dace5e016c991424a3dc6e83b1ae5dca8992d08"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/73cfcc8445585b8af7e18be3c9246b851fdf336c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b68e978718f14fdcb080c2a7791c52a0d09bc6d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa5ce1485562f20235b4c759eee5ab0c41d2c220"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3b3b6366dc8eb5b22edba9adc4bff3cdacfd64c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d64b7b05a827f98d068f412969eef65489b0cf03"
},
{
"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-HHMV-6RQC-QRC8
Vulnerability from github – Published: 2025-04-14 15:31 – Updated: 2026-06-26 00:32A flaw was found in libsoup, where SoupAuthDigest is vulnerable to a NULL pointer dereference. The HTTP server may cause the libsoup client to crash.
{
"affected": [],
"aliases": [
"CVE-2025-32912"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-14T15:15:25Z",
"severity": "MODERATE"
},
"details": "A flaw was found in libsoup, where SoupAuthDigest is vulnerable to a NULL pointer dereference. The HTTP server may cause the libsoup client to crash.",
"id": "GHSA-hhmv-6rqc-qrc8",
"modified": "2026-06-26T00:32:00Z",
"published": "2025-04-14T15:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32912"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:7505"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-32912"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2359356"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/libsoup/-/issues/434"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/04/msg00036.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HHP5-2M4Q-MMRP
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15An issue was discovered in swftools through 20200710. A NULL pointer dereference exists in the function params_dump() located in abc.c. It allows an attacker to cause Denial of Service.
{
"affected": [],
"aliases": [
"CVE-2021-39590"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-20T16:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in swftools through 20200710. A NULL pointer dereference exists in the function params_dump() located in abc.c. It allows an attacker to cause Denial of Service.",
"id": "GHSA-hhp5-2m4q-mmrp",
"modified": "2022-05-24T19:15:05Z",
"published": "2022-05-24T19:15:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39590"
},
{
"type": "WEB",
"url": "https://github.com/matthiaskramm/swftools/issues/137"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.