CWE-476
AllowedNULL Pointer Dereference
Abstraction: Base · Status: Stable
The product dereferences a pointer that it expects to be valid but is NULL.
6775 vulnerabilities reference this CWE, most recent first.
GHSA-PPWX-W5V2-MFJ6
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 dump_method() located in abc.c. It allows an attacker to cause Denial of Service.
{
"affected": [],
"aliases": [
"CVE-2021-39575"
],
"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 dump_method() located in abc.c. It allows an attacker to cause Denial of Service.",
"id": "GHSA-ppwx-w5v2-mfj6",
"modified": "2022-05-24T19:15:06Z",
"published": "2022-05-24T19:15:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39575"
},
{
"type": "WEB",
"url": "https://github.com/matthiaskramm/swftools/issues/128"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PQ25-X76J-WRFP
Vulnerability from github – Published: 2022-11-10 19:01 – Updated: 2022-11-10 19:01NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where a local user with basic capabilities can cause a null-pointer dereference, which may lead to denial of service.
{
"affected": [],
"aliases": [
"CVE-2022-34666"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-10T16:15:00Z",
"severity": "MODERATE"
},
"details": "NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where a local user with basic capabilities can cause a null-pointer dereference, which may lead to denial of service.",
"id": "GHSA-pq25-x76j-wrfp",
"modified": "2022-11-10T19:01:07Z",
"published": "2022-11-10T19:01:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34666"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5383"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202310-02"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PQ4C-FM9X-V9HJ
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-30 03:37In the Linux kernel, the following vulnerability has been resolved:
drm/xe/dma-buf: handle empty bo and UAF races
There look to be some nasty races here when triggering the invalidate_mappings hook:
1) We do xe_bo_alloc() followed by the attach, before the actual full bo init step in xe_dma_buf_init_obj(). However the bo is visible on the attachments list after the attach. This is bad since exporter driver, say amdgpu, can at any time call back into our invalidate_mappings hook, with an empty/bogus bo, leading to potential bugs/crashes.
2) Similar to 1) but here we get a UAF, when the invalidate_mappings hook is triggered. For example, we get as far as xe_bo_init_locked() but this fails in some way. But here the bo will be freed on error, but we still have it attached from dma-buf pov, so if the invalidate_mappings is now triggered then the bo we access is gone and we trigger UAF and more bugs/crashes.
To fix this, move the attach step until after we actually have a fully set up buffer object. Note that the bo is not published to userspace until later, so not sure what the comment "Don't publish the bo until we have a valid attachment", is referring to.
We have at least two different customers reporting hitting a NULL ptr deref in evict_flags when importing something from amdgpu, followed by triggering the evict flow. Hit rate is also pretty low, which would hint at some kind of race, so something like 1) or 2) might explain this.
v2: - Shuffle the order of the ops slightly (no functional change) - Improve the comment to better explain the ordering (Matt B)
(cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)
{
"affected": [],
"aliases": [
"CVE-2026-52951"
],
"database_specific": {
"cwe_ids": [
"CWE-416",
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:05Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/dma-buf: handle empty bo and UAF races\n\nThere look to be some nasty races here when triggering the\ninvalidate_mappings hook:\n\n1) We do xe_bo_alloc() followed by the attach, before the actual full bo\n init step in xe_dma_buf_init_obj(). However the bo is visible on the\n attachments list after the attach. This is bad since exporter driver,\n say amdgpu, can at any time call back into our invalidate_mappings hook,\n with an empty/bogus bo, leading to potential bugs/crashes.\n\n2) Similar to 1) but here we get a UAF, when the invalidate_mappings\n hook is triggered. For example, we get as far as xe_bo_init_locked()\n but this fails in some way. But here the bo will be freed on error, but\n we still have it attached from dma-buf pov, so if the\n invalidate_mappings is now triggered then the bo we access is gone and\n we trigger UAF and more bugs/crashes.\n\nTo fix this, move the attach step until after we actually have a fully\nset up buffer object. Note that the bo is not published to userspace\nuntil later, so not sure what the comment \"Don\u0027t publish the bo\nuntil we have a valid attachment\", is referring to.\n\nWe have at least two different customers reporting hitting a NULL ptr\nderef in evict_flags when importing something from amdgpu, followed by\ntriggering the evict flow. Hit rate is also pretty low, which would\nhint at some kind of race, so something like 1) or 2) might explain\nthis.\n\nv2:\n - Shuffle the order of the ops slightly (no functional change)\n - Improve the comment to better explain the ordering (Matt B)\n\n(cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)",
"id": "GHSA-pq4c-fm9x-v9hj",
"modified": "2026-06-30T03:37:11Z",
"published": "2026-06-24T18:32:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52951"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-52951"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492353"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20a99ea1e2fd720856d6ba497ff26b82c604751f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/981bedbbe61364fcc3a3b87ebaf648a66cd07108"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9894731e513019df22a29e5c52f1c98890355ff1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c473ae25421fddc3dde247ba7b85225b10641d09"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52951.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PQ5R-RP8M-P9VH
Vulnerability from github – Published: 2024-03-29 00:30 – Updated: 2024-08-22 21:31Jerryscript 2.4.0 has SEGV at ./jerry-core/ecma/base/ecma-helpers.c:238:58 in ecma_get_object_type.
{
"affected": [],
"aliases": [
"CVE-2024-29489"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-28T23:15:46Z",
"severity": "MODERATE"
},
"details": "Jerryscript 2.4.0 has SEGV at ./jerry-core/ecma/base/ecma-helpers.c:238:58 in ecma_get_object_type.",
"id": "GHSA-pq5r-rp8m-p9vh",
"modified": "2024-08-22T21:31:27Z",
"published": "2024-03-29T00:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29489"
},
{
"type": "WEB",
"url": "https://github.com/jerryscript-project/jerryscript/issues/5101"
},
{
"type": "WEB",
"url": "https://github.com/jerryscript-project/jerryscript/pull/5129"
},
{
"type": "WEB",
"url": "https://github.com/jerryscript-project/jerryscript/commit/cefd391772529c8a9531d7b3c244d78d38be47c6"
},
{
"type": "WEB",
"url": "https://gist.github.com/gandalf4a/9826a897ae1e3c8d1c7e71a1ec71d415"
}
],
"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-PQ66-H8QJ-7XG9
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-01-16 18:30In the Linux kernel, the following vulnerability has been resolved:
cacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU
Commit
5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU")
adds functionality that architectures can use to optionally allocate and build cacheinfo early during boot. Commit
6539cffa9495 ("cacheinfo: Add arch specific early level initializer")
lets secondary CPUs correct (and reallocate memory) cacheinfo data if needed.
If the early build functionality is not used and cacheinfo does not need correction, memory for cacheinfo is never allocated. x86 does not use the early build functionality. Consequently, during the cacheinfo CPU hotplug callback, last_level_cache_is_valid() attempts to dereference a NULL pointer:
BUG: kernel NULL pointer dereference, address: 0000000000000100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not present page PGD 0 P4D 0 Oops: 0000 [#1] PREEPMT SMP NOPTI CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1 RIP: 0010: last_level_cache_is_valid+0x95/0xe0a
Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback if not done earlier.
Moreover, before determining the validity of the last-level cache info, ensure that it has been allocated. Simply checking for non-zero cache_leaves() is not sufficient, as some architectures (e.g., Intel processors) have non-zero cache_leaves() before allocation.
Dereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size(). This function iterates over all online CPUs. However, a CPU may have come online recently, but its cacheinfo may not have been allocated yet.
While here, remove an unnecessary indentation in allocate_cache_info().
[ bp: Massage. ]
{
"affected": [],
"aliases": [
"CVE-2024-56617"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T15:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU\n\nCommit\n\n 5944ce092b97 (\"arch_topology: Build cacheinfo from primary CPU\")\n\nadds functionality that architectures can use to optionally allocate and\nbuild cacheinfo early during boot. Commit\n\n 6539cffa9495 (\"cacheinfo: Add arch specific early level initializer\")\n\nlets secondary CPUs correct (and reallocate memory) cacheinfo data if\nneeded.\n\nIf the early build functionality is not used and cacheinfo does not need\ncorrection, memory for cacheinfo is never allocated. x86 does not use\nthe early build functionality. Consequently, during the cacheinfo CPU\nhotplug callback, last_level_cache_is_valid() attempts to dereference\na NULL pointer:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000100\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEPMT SMP NOPTI\n CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1\n RIP: 0010: last_level_cache_is_valid+0x95/0xe0a\n\nAllocate memory for cacheinfo during the cacheinfo CPU hotplug callback\nif not done earlier.\n\nMoreover, before determining the validity of the last-level cache info,\nensure that it has been allocated. Simply checking for non-zero\ncache_leaves() is not sufficient, as some architectures (e.g., Intel\nprocessors) have non-zero cache_leaves() before allocation.\n\nDereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size().\nThis function iterates over all online CPUs. However, a CPU may have come\nonline recently, but its cacheinfo may not have been allocated yet.\n\nWhile here, remove an unnecessary indentation in allocate_cache_info().\n\n [ bp: Massage. ]",
"id": "GHSA-pq66-h8qj-7xg9",
"modified": "2025-01-16T18:30:59Z",
"published": "2024-12-27T15:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56617"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/23b5908b11b77ff8d7b8f7b8f11cbab2e1f4bfc2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95e197354e0de07e9a20819bdae6562e4dda0f20"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3fce429a1e030b50c1c91351d69b8667eef627b"
}
],
"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-PQ7F-896M-7JG7
Vulnerability from github – Published: 2024-02-13 09:30 – Updated: 2024-02-13 09:30A vulnerability has been identified in Tecnomatix Plant Simulation V2201 (All versions), Tecnomatix Plant Simulation V2302 (All versions < V2302.0007). The affected applications contain a null pointer dereference vulnerability while parsing specially crafted SPP files. An attacker could leverage this vulnerability to crash the application causing denial of service condition.
{
"affected": [],
"aliases": [
"CVE-2024-23800"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-13T09:15:48Z",
"severity": "LOW"
},
"details": "A vulnerability has been identified in Tecnomatix Plant Simulation V2201 (All versions), Tecnomatix Plant Simulation V2302 (All versions \u003c V2302.0007). The affected applications contain a null pointer dereference vulnerability while parsing specially crafted SPP files. An attacker could leverage this vulnerability to crash the application causing denial of service condition.",
"id": "GHSA-pq7f-896m-7jg7",
"modified": "2024-02-13T09:30:33Z",
"published": "2024-02-13T09:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23800"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-017796.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:L",
"type": "CVSS_V3"
}
]
}
GHSA-PQC2-JW96-C94G
Vulnerability from github – Published: 2022-09-02 00:01 – Updated: 2022-09-08 00:00A NULL pointer dereference in the read_and_display_attr_value() function in binutils/dwarf.c may lead to program crash when parsing corrupt DWARF data.
{
"affected": [],
"aliases": [
"CVE-2022-38127"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-01T21:15:00Z",
"severity": "MODERATE"
},
"details": "A NULL pointer dereference in the read_and_display_attr_value() function in binutils/dwarf.c may lead to program crash when parsing corrupt DWARF data.",
"id": "GHSA-pqc2-jw96-c94g",
"modified": "2022-09-08T00:00:32Z",
"published": "2022-09-02T00:01:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38127"
},
{
"type": "WEB",
"url": "https://sourceware.org/bugzilla/show_bug.cgi?id=29290"
}
],
"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-PQC6-P826-C5QW
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-05-24 19:04Apache HTTP Server versions 2.4.41 to 2.4.46 mod_proxy_http can be made to crash (NULL pointer dereference) with specially crafted requests using both Content-Length and Transfer-Encoding headers, leading to a Denial of Service
{
"affected": [],
"aliases": [
"CVE-2020-13950"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-10T07:15:00Z",
"severity": "HIGH"
},
"details": "Apache HTTP Server versions 2.4.41 to 2.4.46 mod_proxy_http can be made to crash (NULL pointer dereference) with specially crafted requests using both Content-Length and Transfer-Encoding headers, leading to a Denial of Service",
"id": "GHSA-pqc6-p826-c5qw",
"modified": "2022-05-24T19:04:56Z",
"published": "2022-05-24T19:04:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13950"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7f2b70b621651548f4b6f027552f1dd91705d7111bb5d15cda0a68dd@%3Cdev.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbe197409ae4a58b629fb792d1aed541ccbbf865121a80e1c5938d223@%3Cannounce.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re026d3da9d7824bd93b9f871c0fdda978d960c7e62d8c43cba8d0bf3%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SPBR6WUYBJNACHKE65SPL7TJOHX7RHWD"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZNCYSR3BXT36FFF4XTCPL3HDQK4VP45R"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202107-38"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210702-0001"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "http://httpd.apache.org/security/vulnerabilities_24.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/06/10/4"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PQF9-M843-PPVG
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-11-19 18:31In the Linux kernel, the following vulnerability has been resolved:
spi: spi-qpic-snand: reallocate BAM transactions
Using the mtd_nandbiterrs module for testing the driver occasionally results in weird things like below.
- swiotlb mapping fails with the following message:
[ 85.926216] qcom_snand 79b0000.spi: swiotlb buffer is full (sz: 4294967294 bytes), total 512 (slots), used 0 (slots) [ 85.932937] qcom_snand 79b0000.spi: failure in mapping desc [ 87.999314] qcom_snand 79b0000.spi: failure to write raw page [ 87.999352] mtd_nandbiterrs: error: write_oob failed (-110)
Rebooting the board after this causes a panic due to a NULL pointer dereference.
- If the swiotlb mapping does not fail, rebooting the board may result in a different panic due to a bad spinlock magic:
[ 256.104459] BUG: spinlock bad magic on CPU#3, procd/2241 [ 256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b ...
Investigating the issue revealed that these symptoms are results of memory corruption which is caused by out of bounds access within the driver.
The driver uses a dynamically allocated structure for BAM transactions, which structure must have enough space for all possible variations of different flash operations initiated by the driver. The required space heavily depends on the actual number of 'codewords' which is calculated from the pagesize of the actual NAND chip.
Although the qcom_nandc_alloc() function allocates memory for the BAM transactions during probe, but since the actual number of 'codewords' is not yet know the allocation is done for one 'codeword' only.
Because of this, whenever the driver does a flash operation, and the number of the required transactions exceeds the size of the allocated arrays the driver accesses memory out of the allocated range.
To avoid this, change the code to free the initially allocated BAM transactions memory, and allocate a new one once the actual number of 'codewords' required for a given NAND chip is known.
{
"affected": [],
"aliases": [
"CVE-2025-38398"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T13:15:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: spi-qpic-snand: reallocate BAM transactions\n\nUsing the mtd_nandbiterrs module for testing the driver occasionally\nresults in weird things like below.\n\n1. swiotlb mapping fails with the following message:\n\n [ 85.926216] qcom_snand 79b0000.spi: swiotlb buffer is full (sz: 4294967294 bytes), total 512 (slots), used 0 (slots)\n [ 85.932937] qcom_snand 79b0000.spi: failure in mapping desc\n [ 87.999314] qcom_snand 79b0000.spi: failure to write raw page\n [ 87.999352] mtd_nandbiterrs: error: write_oob failed (-110)\n\n Rebooting the board after this causes a panic due to a NULL pointer\n dereference.\n\n2. If the swiotlb mapping does not fail, rebooting the board may result\n in a different panic due to a bad spinlock magic:\n\n [ 256.104459] BUG: spinlock bad magic on CPU#3, procd/2241\n [ 256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b\n ...\n\nInvestigating the issue revealed that these symptoms are results of\nmemory corruption which is caused by out of bounds access within the\ndriver.\n\nThe driver uses a dynamically allocated structure for BAM transactions,\nwhich structure must have enough space for all possible variations of\ndifferent flash operations initiated by the driver. The required space\nheavily depends on the actual number of \u0027codewords\u0027 which is calculated\nfrom the pagesize of the actual NAND chip.\n\nAlthough the qcom_nandc_alloc() function allocates memory for the BAM\ntransactions during probe, but since the actual number of \u0027codewords\u0027\nis not yet know the allocation is done for one \u0027codeword\u0027 only.\n\nBecause of this, whenever the driver does a flash operation, and the\nnumber of the required transactions exceeds the size of the allocated\narrays the driver accesses memory out of the allocated range.\n\nTo avoid this, change the code to free the initially allocated BAM\ntransactions memory, and allocate a new one once the actual number of\n\u0027codewords\u0027 required for a given NAND chip is known.",
"id": "GHSA-pqf9-m843-ppvg",
"modified": "2025-11-19T18:31:15Z",
"published": "2025-07-25T15:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38398"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/86fb36de1132b560f9305f0c78fa69f459fa0980"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d85d0380292a7e618915069c3579ae23c7c80339"
}
],
"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-PQFP-6QG3-J74H
Vulnerability from github – Published: 2025-07-03 09:30 – Updated: 2025-11-20 21:30In the Linux kernel, the following vulnerability has been resolved:
drm/connector: only call HDMI audio helper plugged cb if non-null
On driver remove, sound/soc/codecs/hdmi-codec.c calls the plugged_cb with NULL as the callback function and codec_dev, as seen in its hdmi_remove function.
The HDMI audio helper then happily tries calling said null function pointer, and produces an Oops as a result.
Fix this by only executing the callback if fn is non-null. This means the .plugged_cb and .plugged_cb_dev members still get appropriately cleared.
{
"affected": [],
"aliases": [
"CVE-2025-38130"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-03T09:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/connector: only call HDMI audio helper plugged cb if non-null\n\nOn driver remove, sound/soc/codecs/hdmi-codec.c calls the plugged_cb\nwith NULL as the callback function and codec_dev, as seen in its\nhdmi_remove function.\n\nThe HDMI audio helper then happily tries calling said null function\npointer, and produces an Oops as a result.\n\nFix this by only executing the callback if fn is non-null. This means\nthe .plugged_cb and .plugged_cb_dev members still get appropriately\ncleared.",
"id": "GHSA-pqfp-6qg3-j74h",
"modified": "2025-11-20T21:30:29Z",
"published": "2025-07-03T09:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38130"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/933f3eab1d489af8d734bff855b10d29dd5968a4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be9b3f9a54101c19226c25ba7163d291183777a0"
}
],
"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.