GHSA-462H-76X8-CCQR
Vulnerability from github – Published: 2026-09-17 18:31 – Updated: 2026-10-30 15:33In the Linux kernel, the following vulnerability has been resolved:
fuse: check for NULL root inode in fuse_fill_super_submount
fuse_iget() can return NULL when its inode allocation fails, but fuse_fill_super_submount() passed the result straight to get_fuse_inode() and decremented fi->nlookup without checking it:
root = fuse_iget(sb, parent_fi->nodeid, ...);
fi = get_fuse_inode(root);
fi->nlookup--;
Inside fuse_iget() the inode allocation can fail and return NULL. The submount root takes the iget5_locked() path, whose alloc_inode() can fail under memory pressure (the auto-submount branch can fail the same way in new_inode() or fuse_alloc_submount_lookup()):
inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set,
&nodeid);
if (!inode)
return NULL;
A NULL root makes get_fuse_inode() a container_of() on NULL and the nlookup decrement a write to a bogus address, oopsing the mount. With CONFIG_KASAN the following null pointer dereference is reported when the root inode allocation of an auto-submount fails (e.g. under memory pressure):
================================================================== BUG: KASAN: null-ptr-deref in fuse_get_tree_submount+0x656/0x8b0 Read of size 8 at addr 00000000000002b0 by task ls/942 CPU: 0 PID: 942 Comm: ls Tainted: G W 6.6 #15 Call Trace: fuse_get_tree_submount+0x656/0x8b0 vfs_get_tree+0x48/0x140 fc_mount+0x13/0x50 fuse_dentry_automount+0x7a/0xb0 __traverse_mounts+0xca/0x330 step_into+0x339/0xac0 path_lookupat+0xc5/0x2f0 filename_lookup+0x163/0x2a0 vfs_statx+0xd5/0x200 do_statx+0x83/0xd0 __x64_sys_statx+0xa0/0xc0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ==================================================================
Return -ENOMEM instead; the caller tears down the partially built superblock on error, matching the other error returns in this function.
{
"affected": [],
"aliases": [
"CVE-2026-90139"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-17T17:17:06Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfuse: check for NULL root inode in fuse_fill_super_submount\n\nfuse_iget() can return NULL when its inode allocation fails, but\nfuse_fill_super_submount() passed the result straight to get_fuse_inode()\nand decremented fi-\u003enlookup without checking it:\n\n root = fuse_iget(sb, parent_fi-\u003enodeid, ...);\n fi = get_fuse_inode(root);\n fi-\u003enlookup--;\n\nInside fuse_iget() the inode allocation can fail and return NULL. The\nsubmount root takes the iget5_locked() path, whose alloc_inode() can fail\nunder memory pressure (the auto-submount branch can fail the same way in\nnew_inode() or fuse_alloc_submount_lookup()):\n\n inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set,\n \u0026nodeid);\n if (!inode)\n return NULL;\n\nA NULL root makes get_fuse_inode() a container_of() on NULL and the\nnlookup decrement a write to a bogus address, oopsing the mount. With\nCONFIG_KASAN the following null pointer dereference is reported when the\nroot inode allocation of an auto-submount fails (e.g. under memory\npressure):\n\n==================================================================\nBUG: KASAN: null-ptr-deref in fuse_get_tree_submount+0x656/0x8b0\nRead of size 8 at addr 00000000000002b0 by task ls/942\nCPU: 0 PID: 942 Comm: ls Tainted: G W 6.6 #15\nCall Trace:\n \u003cTASK\u003e\n fuse_get_tree_submount+0x656/0x8b0\n vfs_get_tree+0x48/0x140\n fc_mount+0x13/0x50\n fuse_dentry_automount+0x7a/0xb0\n __traverse_mounts+0xca/0x330\n step_into+0x339/0xac0\n path_lookupat+0xc5/0x2f0\n filename_lookup+0x163/0x2a0\n vfs_statx+0xd5/0x200\n do_statx+0x83/0xd0\n __x64_sys_statx+0xa0/0xc0\n do_syscall_64+0x37/0x90\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\n \u003c/TASK\u003e\n==================================================================\n\nReturn -ENOMEM instead; the caller tears down the partially built\nsuperblock on error, matching the other error returns in this\nfunction.",
"id": "GHSA-462h-76x8-ccqr",
"modified": "2026-10-30T15:33:32Z",
"published": "2026-09-17T18:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90139"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17120c5bfb16808509ea18d7fab6027802d93eba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4844aeb0de5fb0de4f7c9aaf2bf05cb8cffe60d5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/509f4a09bae7f03c87f67f053648874a5e177867"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/928f659a3e3650978a5b4829cc982324f72b474b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5129155ca9fba40d77ff19ffead8244e88d6f9c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e0b7f2922f6bd4c23cbddb7d1fc2bada570d27d1"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.