CWE-476
AllowedNULL Pointer Dereference
Abstraction: Base · Status: Stable
The product dereferences a pointer that it expects to be valid but is NULL.
6305 vulnerabilities reference this CWE, most recent first.
GHSA-P32H-PXRF-9H8J
Vulnerability from github – Published: 2025-07-08 18:31 – Updated: 2025-07-08 18:31After Effects versions 25.2, 24.6.6 and earlier are affected by a NULL Pointer Dereference vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to crash the application, causing disruption to services. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
{
"affected": [],
"aliases": [
"CVE-2025-47109"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-08T17:15:36Z",
"severity": "MODERATE"
},
"details": "After Effects versions 25.2, 24.6.6 and earlier are affected by a NULL Pointer Dereference vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to crash the application, causing disruption to services. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
"id": "GHSA-p32h-pxrf-9h8j",
"modified": "2025-07-08T18:31:44Z",
"published": "2025-07-08T18:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47109"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/after_effects/apsb25-49.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-P33R-FQW2-RQMM
Vulnerability from github – Published: 2026-02-24 15:32 – Updated: 2026-02-24 15:32In ReadSFWImage() (coders/sfw.c), when temporary file creation fails, read_info is destroyed before its filename member is accessed, causing a NULL pointer dereference and crash.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==1414421==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x56260222912f bp 0x7ffec0a193b0 sp 0x7ffec0a19360 T0)
#0 0x56260222912f (/data/ylwang/LargeScan/targets/ImageMagick/utilities/magick+0x235f12f)
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-AnyCPU"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-AnyCPU"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-OpenMP-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-OpenMP-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-HDRI-x86"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-OpenMP-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-OpenMP-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-OpenMP-x86"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q16-x86"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-AnyCPU"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-OpenMP-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-OpenMP-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-x64"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Magick.NET-Q8-x86"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "14.10.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25795"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-24T15:32:34Z",
"nvd_published_at": "2026-02-24T01:16:14Z",
"severity": "MODERATE"
},
"details": "In `ReadSFWImage()` (`coders/sfw.c`), when temporary file creation fails, `read_info` is destroyed before its `filename` member is accessed, causing a NULL pointer dereference and crash.\n\n```\nAddressSanitizer:DEADLYSIGNAL\n=================================================================\n==1414421==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x56260222912f bp 0x7ffec0a193b0 sp 0x7ffec0a19360 T0)\n #0 0x56260222912f (/data/ylwang/LargeScan/targets/ImageMagick/utilities/magick+0x235f12f)\n```",
"id": "GHSA-p33r-fqw2-rqmm",
"modified": "2026-02-24T15:32:34Z",
"published": "2026-02-24T15:32:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-p33r-fqw2-rqmm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25795"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/commit/332c1566acc2de77857032d3c2504ead6210ff50"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/commit/55c344f4b514213642da41194bab57b4476fb9f5"
},
{
"type": "PACKAGE",
"url": "https://github.com/ImageMagick/ImageMagick"
},
{
"type": "WEB",
"url": "https://github.com/dlemstra/Magick.NET/releases/tag/14.10.3"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "ImageMagick has NULL pointer dereference in ReadSFWImage after DestroyImageInfo (sfw.c)"
}
GHSA-P347-69W9-6826
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()
Temporarily clear the preallocation flag when explicitly requesting allocations. Pre-existing allocations are already counted against the request through mas_node_count_gfp(), but the allocations will not happen if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid re-allocating in bulk allocation mode, and to detect issues with preallocation calculations.
The MA_STATE_PREALLOC flag should also always be set on zero allocations so that detection of underflow allocations will print a WARN_ON() during consumption.
User visible effect of this flaw is a WARN_ON() followed by a null pointer dereference when subsequent requests for larger number of nodes is ignored, such as the vma merge retry in mmap_region() caused by drivers altering the vma flags (which happens in v6.6, at least)
{
"affected": [],
"aliases": [
"CVE-2025-38364"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T13:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmaple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()\n\nTemporarily clear the preallocation flag when explicitly requesting\nallocations. Pre-existing allocations are already counted against the\nrequest through mas_node_count_gfp(), but the allocations will not happen\nif the MA_STATE_PREALLOC flag is set. This flag is meant to avoid\nre-allocating in bulk allocation mode, and to detect issues with\npreallocation calculations.\n\nThe MA_STATE_PREALLOC flag should also always be set on zero allocations\nso that detection of underflow allocations will print a WARN_ON() during\nconsumption.\n\nUser visible effect of this flaw is a WARN_ON() followed by a null pointer\ndereference when subsequent requests for larger number of nodes is\nignored, such as the vma merge retry in mmap_region() caused by drivers\naltering the vma flags (which happens in v6.6, at least)",
"id": "GHSA-p347-69w9-6826",
"modified": "2026-05-12T15:30:56Z",
"published": "2025-07-25T15:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38364"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e32f4700867abbd5d19abfcf698dbd0d2ce36a4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf95f8426f889949b738f51ffcd72884411f3a6a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d69cd64bd5af41c6fd409313504089970edaf02f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e63032e66bca1d06e600033f3369ba3db3af0870"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fba46a5d83ca8decb338722fb4899026d8d9ead2"
},
{
"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-P36J-VMFC-M4V5
Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-07-26 00:00The Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.5 and 1.19.x before 1.19.3 has a NULL pointer dereference in kdc/do_tgs_req.c via a FAST inner body that lacks a server field.
{
"affected": [],
"aliases": [
"CVE-2021-37750"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-23T05:15:00Z",
"severity": "MODERATE"
},
"details": "The Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.5 and 1.19.x before 1.19.3 has a NULL pointer dereference in kdc/do_tgs_req.c via a FAST inner body that lacks a server field.",
"id": "GHSA-p36j-vmfc-m4v5",
"modified": "2022-07-26T00:00:47Z",
"published": "2022-05-24T19:11:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37750"
},
{
"type": "WEB",
"url": "https://github.com/krb5/krb5/commit/d775c95af7606a51bf79547a94fa52ddd1cb7f49"
},
{
"type": "WEB",
"url": "https://github.com/krb5/krb5/releases"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/09/msg00019.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MFCLW7D46E4VCREKKH453T5DA4XOLHU2"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210923-0002"
},
{
"type": "WEB",
"url": "https://web.mit.edu/kerberos/advisories"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2022.html"
},
{
"type": "WEB",
"url": "https://www.starwindsoftware.com/security/sw-20220817-0004"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P3C9-JPW2-54R7
Vulnerability from github – Published: 2022-05-14 03:18 – Updated: 2022-05-14 03:18A NULL pointer dereference was discovered in H5O__chunk_deserialize in H5Ocache.c in the HDF HDF5 1.10.2 library. It could allow a remote denial of service attack.
{
"affected": [],
"aliases": [
"CVE-2018-11204"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-05-16T15:29:00Z",
"severity": "MODERATE"
},
"details": "A NULL pointer dereference was discovered in H5O__chunk_deserialize in H5Ocache.c in the HDF HDF5 1.10.2 library. It could allow a remote denial of service attack.",
"id": "GHSA-p3c9-jpw2-54r7",
"modified": "2022-05-14T03:18:06Z",
"published": "2022-05-14T03:18:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11204"
},
{
"type": "WEB",
"url": "https://github.com/Twi1ight/fuzzing-pocs/tree/master/hdf5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P3CG-RHHG-WCGV
Vulnerability from github – Published: 2022-05-24 19:16 – Updated: 2022-05-24 19:16Acrobat Reader DC versions 2021.005.20060 (and earlier), 2020.004.30006 (and earlier) and 2017.011.30199 (and earlier) are affected by a Null pointer dereference vulnerability. An authenticated attacker could leverage this vulnerability to achieve an application denial-of-service in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
{
"affected": [],
"aliases": [
"CVE-2021-39850"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-29T16:15:00Z",
"severity": "MODERATE"
},
"details": "Acrobat Reader DC versions 2021.005.20060 (and earlier), 2020.004.30006 (and earlier) and 2017.011.30199 (and earlier) are affected by a Null pointer dereference vulnerability. An authenticated attacker could leverage this vulnerability to achieve an application denial-of-service in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
"id": "GHSA-p3cg-rhhg-wcgv",
"modified": "2022-05-24T19:16:05Z",
"published": "2022-05-24T19:16:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39850"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/acrobat/apsb21-55.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-P3FQ-HHF9-6F56
Vulnerability from github – Published: 2022-05-17 01:19 – Updated: 2025-04-20 03:43NULL Pointer Dereference in the id3v2AddAudioDuration function in libmp3lame/id3tag.c in LAME 3.99.5 allows attackers to perform Denial of Service by triggering a NULL first argument.
{
"affected": [],
"aliases": [
"CVE-2017-13712"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-28T19:29:00Z",
"severity": "HIGH"
},
"details": "NULL Pointer Dereference in the id3v2AddAudioDuration function in libmp3lame/id3tag.c in LAME 3.99.5 allows attackers to perform Denial of Service by triggering a NULL first argument.",
"id": "GHSA-p3fq-hhf9-6f56",
"modified": "2025-04-20T03:43:57Z",
"published": "2022-05-17T01:19:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-13712"
},
{
"type": "WEB",
"url": "https://sourceforge.net/p/lame/bugs/472"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100525"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P3GJ-WQ33-QG67
Vulnerability from github – Published: 2022-05-13 01:09 – Updated: 2025-04-20 03:39In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, mod_ssl may dereference a NULL pointer when third-party modules call ap_hook_process_connection() during an HTTP request to an HTTPS port.
{
"affected": [],
"aliases": [
"CVE-2017-3169"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-20T01:29:00Z",
"severity": "CRITICAL"
},
"details": "In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, mod_ssl may dereference a NULL pointer when third-party modules call ap_hook_process_connection() during an HTTP request to an HTTPS port.",
"id": "GHSA-p3gj-wq33-qg67",
"modified": "2025-04-20T03:39:23Z",
"published": "2022-05-13T01:09:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-3169"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2478"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9ea3538f229874c80a10af473856a81fbf5f694cd7f471cc679ba70b@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rad01d817195e6cc871cb1d73b207ca326379a20a6e7f30febaf56d24%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rad01d817195e6cc871cb1d73b207ca326379a20a6e7f30febaf56d24@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc998b18880df98bafaade071346690c2bc1444adaa1a1ea464b93f0a%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc998b18880df98bafaade071346690c2bc1444adaa1a1ea464b93f0a@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcc44594d4d6579b90deccd4536b5d31f099ef563df39b094be286b9e%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcc44594d4d6579b90deccd4536b5d31f099ef563df39b094be286b9e@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd18c3c43602e66f9cdcf09f1de233804975b9572b0456cc582390b6f%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd18c3c43602e66f9cdcf09f1de233804975b9572b0456cc582390b6f@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd336919f655b7ff309385e34a143e41c503e133da80414485b3abcc9%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd336919f655b7ff309385e34a143e41c503e133da80414485b3abcc9@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rdca61ae990660bacb682295f2a09d34612b7bb5f457577fe17f4d064%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rdca61ae990660bacb682295f2a09d34612b7bb5f457577fe17f4d064@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re3d27b6250aa8548b8845d314bb8a350b3df326cacbbfdfe4d455234%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re3d27b6250aa8548b8845d314bb8a350b3df326cacbbfdfe4d455234@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfbaf647d52c1cb843e726a0933f156366a806cead84fbd430951591b%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfbaf647d52c1cb843e726a0933f156366a806cead84fbd430951591b@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfcf929bd33a6833e3f0c35eebdad70d5060665f9c4e17ea467c66770%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfcf929bd33a6833e3f0c35eebdad70d5060665f9c4e17ea467c66770@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201710-32"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20180601-0002"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT208221"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbux03908en_us"
},
{
"type": "WEB",
"url": "https://www.nomachine.com/SU08O00185"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/tns-2019-09"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2479"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2483"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:3193"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:3194"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:3195"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:3475"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:3476"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:3477"
},
{
"type": "WEB",
"url": "https://github.com/gottburgm/Exploits/tree/master/CVE-2017-3169"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/56c2e7cc9deb1c12a843d0dc251ea7fd3e7e80293cde02fcd65286ba%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/56c2e7cc9deb1c12a843d0dc251ea7fd3e7e80293cde02fcd65286ba@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/84a3714f0878781f6ed84473d1a503d2cc382277e100450209231830%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/84a3714f0878781f6ed84473d1a503d2cc382277e100450209231830@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/84bf7fcc5cad35d355f11839cbdd13cbc5ffc1d34675090bff0f96ae%40%3Cdev.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/84bf7fcc5cad35d355f11839cbdd13cbc5ffc1d34675090bff0f96ae@%3Cdev.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/8d63cb8e9100f28a99429b4328e4e7cebce861d5772ac9863ba2ae6f%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/8d63cb8e9100f28a99429b4328e4e7cebce861d5772ac9863ba2ae6f@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/f7f95ac1cd9895db2714fa3ebaa0b94d0c6df360f742a40951384a53%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/f7f95ac1cd9895db2714fa3ebaa0b94d0c6df360f742a40951384a53@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r04e89e873d54116a0635ef2f7061c15acc5ed27ef7500997beb65d6f%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r04e89e873d54116a0635ef2f7061c15acc5ed27ef7500997beb65d6f@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r476d175be0aaf4a17680ef98c5153b4d336eaef76fb2224cc94c463a%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r476d175be0aaf4a17680ef98c5153b4d336eaef76fb2224cc94c463a@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r57608dc51b79102f3952ae06f54d5277b649c86d6533dcd6a7d201f7%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r57608dc51b79102f3952ae06f54d5277b649c86d6533dcd6a7d201f7@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6521a7f62276340eabdb3339b2aa9a38c5f59d978497a1f794af53be%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6521a7f62276340eabdb3339b2aa9a38c5f59d978497a1f794af53be@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r75cbe9ea3e2114e4271bbeca7aff96117b50c1b6eb7c4772b0337c1f%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r75cbe9ea3e2114e4271bbeca7aff96117b50c1b6eb7c4772b0337c1f@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9ea3538f229874c80a10af473856a81fbf5f694cd7f471cc679ba70b%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3896"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/99134"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1038711"
}
],
"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-P3HP-QCHJ-85WC
Vulnerability from github – Published: 2026-04-24 15:32 – Updated: 2026-04-28 21:36In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Protect all of sev_mem_enc_register_region() with kvm->lock
Take and hold kvm->lock for before checking sev_guest() in sev_mem_enc_register_region(), as sev_guest() isn't stable unless kvm->lock is held (or KVM can guarantee KVM_SEV_INIT{2} has completed and can't rollack state). If KVM_SEV_INIT{2} fails, KVM can end up trying to add to a not-yet-initialized sev->regions_list, e.g. triggering a #GP
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G U W O 6.16.0-smp-DEV #1 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h:83 Code: <41> 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00 RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256 RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000 RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000 R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000 R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000 FS: 00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0 Call Trace: kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371 kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363 __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c:51 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f34e9f7e9a9 Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9 RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007 RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8
with a syzlang reproducer that looks like:
syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000040)={0x0, &(0x7f0000000180)=ANY=[], 0x70}) (async) syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000080)={0x0, &(0x7f0000000180)=ANY=[@ANYBLOB="..."], 0x4f}) (async) r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000200), 0x0, 0x0) r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0) r2 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000240), 0x0, 0x0) r3 = ioctl$KVM_CREATE_VM(r2, 0xae01, 0x0) ioctl$KVM_SET_CLOCK(r3, 0xc008aeba, &(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async) ioctl$KVM_SET_PIT2(r3, 0x8010aebb, &(0x7f0000000280)={[...], 0x5}) (async) ioctl$KVM_SET_PIT2(r1, 0x4070aea0, 0x0) (async) r4 = ioctl$KVM_CREATE_VM(0xffffffffffffffff, 0xae01, 0x0) openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async) ioctl$KVM_SET_USER_MEMORY_REGION(r4, 0x4020ae46, &(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, &(0x7f0000001000/0x2000)=nil}) (async) r5 = ioctl$KVM_CREATE_VCPU(r4, 0xae41, 0x2) close(r0) (async) openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x8000, 0x0) (async) ioctl$KVM_SET_GUEST_DEBUG(r5, 0x4048ae9b, &(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async) ioctl$KVM_RUN(r5, 0xae80, 0x0)
Opportunistically use guard() to avoid having to define a new error label and goto usage.
{
"affected": [],
"aliases": [
"CVE-2026-31592"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T15:16:36Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm-\u003elock\n\nTake and hold kvm-\u003elock for before checking sev_guest() in\nsev_mem_enc_register_region(), as sev_guest() isn\u0027t stable unless kvm-\u003elock\nis held (or KVM can guarantee KVM_SEV_INIT{2} has completed and can\u0027t\nrollack state). If KVM_SEV_INIT{2} fails, KVM can end up trying to add to\na not-yet-initialized sev-\u003eregions_list, e.g. triggering a #GP\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G U W O 6.16.0-smp-DEV #1 NONE\n Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024\n RIP: 0010:sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h:83\n Code: \u003c41\u003e 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00\n RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256\n RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000\n RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000\n RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000\n R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000\n R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000\n FS: 00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0\n Call Trace:\n \u003cTASK\u003e\n kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371\n kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363\n __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c:51\n do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f34e9f7e9a9\n Code: \u003c48\u003e 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\n RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9\n RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007\n RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8\n \u003c/TASK\u003e\n\nwith a syzlang reproducer that looks like:\n\n syz_kvm_add_vcpu$x86(0x0, \u0026(0x7f0000000040)={0x0, \u0026(0x7f0000000180)=ANY=[], 0x70}) (async)\n syz_kvm_add_vcpu$x86(0x0, \u0026(0x7f0000000080)={0x0, \u0026(0x7f0000000180)=ANY=[@ANYBLOB=\"...\"], 0x4f}) (async)\n r0 = openat$kvm(0xffffffffffffff9c, \u0026(0x7f0000000200), 0x0, 0x0)\n r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)\n r2 = openat$kvm(0xffffffffffffff9c, \u0026(0x7f0000000240), 0x0, 0x0)\n r3 = ioctl$KVM_CREATE_VM(r2, 0xae01, 0x0)\n ioctl$KVM_SET_CLOCK(r3, 0xc008aeba, \u0026(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async)\n ioctl$KVM_SET_PIT2(r3, 0x8010aebb, \u0026(0x7f0000000280)={[...], 0x5}) (async)\n ioctl$KVM_SET_PIT2(r1, 0x4070aea0, 0x0) (async)\n r4 = ioctl$KVM_CREATE_VM(0xffffffffffffffff, 0xae01, 0x0)\n openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async)\n ioctl$KVM_SET_USER_MEMORY_REGION(r4, 0x4020ae46, \u0026(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, \u0026(0x7f0000001000/0x2000)=nil}) (async)\n r5 = ioctl$KVM_CREATE_VCPU(r4, 0xae41, 0x2)\n close(r0) (async)\n openat$kvm(0xffffffffffffff9c, \u0026(0x7f0000000000), 0x8000, 0x0) (async)\n ioctl$KVM_SET_GUEST_DEBUG(r5, 0x4048ae9b, \u0026(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async)\n ioctl$KVM_RUN(r5, 0xae80, 0x0)\n\nOpportunistically use guard() to avoid having to define a new error label\nand goto usage.",
"id": "GHSA-p3hp-qchj-85wc",
"modified": "2026-04-28T21:36:02Z",
"published": "2026-04-24T15:32:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31592"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ff93ff0ba82e9511770e175fa50682a1ab14fb6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35a0963d361f98bba798fd15d229dcb166c04684"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab725ac3022469ecd4d7aa7d5646712e98b249d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b6408b6cec5df76a165575777800ef2aba12b109"
}
],
"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-P3JM-9F4H-XP4F
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-28 21:36In the Linux kernel, the following vulnerability has been resolved:
btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create
We have recently observed a number of subvolumes with broken dentries. ls-ing the parent dir looks like:
drwxrwxrwt 1 root root 16 Jan 23 16:49 . drwxr-xr-x 1 root root 24 Jan 23 16:48 .. d????????? ? ? ? ? ? broken_subvol
and similarly stat-ing the file fails.
In this state, deleting the subvol fails with ENOENT, but attempting to create a new file or subvol over it errors out with EEXIST and even aborts the fs. Which leaves us a bit stuck.
dmesg contains a single notable error message reading: "could not do orphan cleanup -2"
2 is ENOENT and the error comes from the failure handling path of btrfs_orphan_cleanup(), with the stack leading back up to btrfs_lookup().
btrfs_lookup btrfs_lookup_dentry btrfs_orphan_cleanup // prints that message and returns -ENOENT
After some detailed inspection of the internal state, it became clear that: - there are no orphan items for the subvol - the subvol is otherwise healthy looking, it is not half-deleted or anything, there is no drop progress, etc. - the subvol was created a while ago and does the meaningful first btrfs_orphan_cleanup() call that sets BTRFS_ROOT_ORPHAN_CLEANUP much later. - after btrfs_orphan_cleanup() fails, btrfs_lookup_dentry() returns -ENOENT, which results in a negative dentry for the subvolume via d_splice_alias(NULL, dentry), leading to the observed behavior. The bug can be mitigated by dropping the dentry cache, at which point we can successfully delete the subvolume if we want.
i.e., btrfs_lookup() btrfs_lookup_dentry() if (!sb_rdonly(inode->vfs_inode)->vfs_inode) btrfs_orphan_cleanup(sub_root) test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) btrfs_search_slot() // finds orphan item for inode N ... prints "could not do orphan cleanup -2" if (inode == ERR_PTR(-ENOENT)) inode = NULL; return d_splice_alias(NULL, dentry) // NEGATIVE DENTRY for valid subvolume
btrfs_orphan_cleanup() does test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) on the root when it runs, so it cannot run more than once on a given root, so something else must run concurrently. However, the obvious routes to deleting an orphan when nlinks goes to 0 should not be able to run without first doing a lookup into the subvolume, which should run btrfs_orphan_cleanup() and set the bit.
The final important observation is that create_subvol() calls d_instantiate_new() but does not set BTRFS_ROOT_ORPHAN_CLEANUP, so if the dentry cache gets dropped, the next lookup into the subvolume will make a real call into btrfs_orphan_cleanup() for the first time. This opens up the possibility of concurrently deleting the inode/orphan items but most typical evict() paths will be holding a reference on the parent dentry (child dentry holds parent->d_lockref.count via dget in d_alloc(), released in __dentry_kill()) and prevent the parent from being removed from the dentry cache.
The one exception is delayed iputs. Ordered extent creation calls igrab() on the inode. If the file is unlinked and closed while those refs are held, iput() in __dentry_kill() decrements i_count but does not trigger eviction (i_count > 0). The child dentry is freed and the subvol dentry's d_lockref.count drops to 0, making it evictable while the inode is still alive.
Since there are two races (the race between writeback and unlink and the race between lookup and delayed iputs), and there are too many moving parts, the following three diagrams show the complete picture. (Only the second and third are races)
Phase 1: Create Subvol in dentry cache without BTRFS_ROOT_ORPHAN_CLEANUP set
btrfs_mksubvol() lookup_one_len() __lookup_slow() d_alloc_parallel() __d_alloc() // d_lockref.count = 1 create_subvol(dentry) // doesn't touch the bit.. d_instantiate_new(dentry, inode) // dentry in cache with d_lockref.c ---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-31519"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create\n\nWe have recently observed a number of subvolumes with broken dentries.\nls-ing the parent dir looks like:\n\ndrwxrwxrwt 1 root root 16 Jan 23 16:49 .\ndrwxr-xr-x 1 root root 24 Jan 23 16:48 ..\nd????????? ? ? ? ? ? broken_subvol\n\nand similarly stat-ing the file fails.\n\nIn this state, deleting the subvol fails with ENOENT, but attempting to\ncreate a new file or subvol over it errors out with EEXIST and even\naborts the fs. Which leaves us a bit stuck.\n\ndmesg contains a single notable error message reading:\n\"could not do orphan cleanup -2\"\n\n2 is ENOENT and the error comes from the failure handling path of\nbtrfs_orphan_cleanup(), with the stack leading back up to\nbtrfs_lookup().\n\nbtrfs_lookup\nbtrfs_lookup_dentry\nbtrfs_orphan_cleanup // prints that message and returns -ENOENT\n\nAfter some detailed inspection of the internal state, it became clear\nthat:\n- there are no orphan items for the subvol\n- the subvol is otherwise healthy looking, it is not half-deleted or\n anything, there is no drop progress, etc.\n- the subvol was created a while ago and does the meaningful first\n btrfs_orphan_cleanup() call that sets BTRFS_ROOT_ORPHAN_CLEANUP much\n later.\n- after btrfs_orphan_cleanup() fails, btrfs_lookup_dentry() returns -ENOENT,\n which results in a negative dentry for the subvolume via\n d_splice_alias(NULL, dentry), leading to the observed behavior. The\n bug can be mitigated by dropping the dentry cache, at which point we\n can successfully delete the subvolume if we want.\n\ni.e.,\nbtrfs_lookup()\n btrfs_lookup_dentry()\n if (!sb_rdonly(inode-\u003evfs_inode)-\u003evfs_inode)\n btrfs_orphan_cleanup(sub_root)\n test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP)\n btrfs_search_slot() // finds orphan item for inode N\n ...\n prints \"could not do orphan cleanup -2\"\n if (inode == ERR_PTR(-ENOENT))\n inode = NULL;\n return d_splice_alias(NULL, dentry) // NEGATIVE DENTRY for valid subvolume\n\nbtrfs_orphan_cleanup() does test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP)\non the root when it runs, so it cannot run more than once on a given\nroot, so something else must run concurrently. However, the obvious\nroutes to deleting an orphan when nlinks goes to 0 should not be able to\nrun without first doing a lookup into the subvolume, which should run\nbtrfs_orphan_cleanup() and set the bit.\n\nThe final important observation is that create_subvol() calls\nd_instantiate_new() but does not set BTRFS_ROOT_ORPHAN_CLEANUP, so if\nthe dentry cache gets dropped, the next lookup into the subvolume will\nmake a real call into btrfs_orphan_cleanup() for the first time. This\nopens up the possibility of concurrently deleting the inode/orphan items\nbut most typical evict() paths will be holding a reference on the parent\ndentry (child dentry holds parent-\u003ed_lockref.count via dget in\nd_alloc(), released in __dentry_kill()) and prevent the parent from\nbeing removed from the dentry cache.\n\nThe one exception is delayed iputs. Ordered extent creation calls\nigrab() on the inode. If the file is unlinked and closed while those\nrefs are held, iput() in __dentry_kill() decrements i_count but does\nnot trigger eviction (i_count \u003e 0). The child dentry is freed and the\nsubvol dentry\u0027s d_lockref.count drops to 0, making it evictable while\nthe inode is still alive.\n\nSince there are two races (the race between writeback and unlink and\nthe race between lookup and delayed iputs), and there are too many moving\nparts, the following three diagrams show the complete picture.\n(Only the second and third are races)\n\nPhase 1:\nCreate Subvol in dentry cache without BTRFS_ROOT_ORPHAN_CLEANUP set\n\nbtrfs_mksubvol()\n lookup_one_len()\n __lookup_slow()\n d_alloc_parallel()\n __d_alloc() // d_lockref.count = 1\n create_subvol(dentry)\n // doesn\u0027t touch the bit..\n d_instantiate_new(dentry, inode) // dentry in cache with d_lockref.c\n---truncated---",
"id": "GHSA-p3jm-9f4h-xp4f",
"modified": "2026-04-28T21:36:01Z",
"published": "2026-04-22T15:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31519"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2ec578e6452138ab76f6c9a9c18711fcd197649f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5131fa077f9bb386a1b901bf5b247041f0ec8f80"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/696683f214495db3cdacab9a713efaaced8660f8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a41a9b8d19a98b45591528c6e54d31cc66271d1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c57276ced3c3207f42182dfa2f0d8e860357e111"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d43da8de0ed376abafbad8a245a1835e8f66cb0f"
}
],
"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.