CVE-2026-98539 affecting package kernel 6.6.157.1-1
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot's "WARNING in do_new_mount" saga ntfs_create_inode() creates a new inode via ntfs_new_inode(). It hashes it with insert_inode_locked() and so it's marked as I_NEW until unlock_new_inode(). ntfs 3 calls d_instantiate() in between though... Since the dentry was already hashed by the lookup before the create any path walk finds it without touching the parent's i_rwsem and so can lock the inode. If the inode is a directory unlock_new_inode() calls lockdep_annotate_inode_mutex_key() and marks i_rwsem with the i_mutex_dir_key class. That resets the count and the owner of a lock somebody else may already hold by now... syzbot has been spamming us with the same godforsaken bug "WARNING in do_new_mount" since 2023. I can't take it anymore so I went looking. Afaict, syzbot's executor chdirs into a freshly mounted ntfs3 image, creates a directory and then mounts some pseudofs on it. Everytime the mkdir() takes longer than syzbot waits mount() runs concurrently: mkdir("./sys") mount(NULL, "./sys", "sysfs") ntfs_create_inode() d_instantiate() user_path_at() finds the dentry do_lock_mount() inode_lock(inode) namespace_lock() unlock_new_inode() lockdep_annotate_inode_mutex_key() init_rwsem(&inode->i_rwsem) unlock_mount() inode_unlock(inode) The mount side then releases a lock that according to the rwsem nobody holds: DEBUG_RWSEMS_WARN_ON((rwsem_owner
- Products
- kernel
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-98539
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 1 Nov 2026, 17:24 UTC · Revision 1
Source evidence
CVE-2026-98539 affecting package kernel 6.6.157.1-1
core-osv · Original sourcePublished 18 Oct 2026, 16:17 UTC
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot's "WARNING in do_new_mount" saga ntfs_create_inode() creates a new inode via ntfs_new_inode(). It hashes it with insert_inode_locked() and so it's marked as I_NEW until unlock_new_inode(). ntfs 3 calls d_instantiate() in between though... Since the dentry was already hashed by the lookup before the create any path walk finds it without touching the parent's i_rwsem and so can lock the inode. If the inode is a directory unlock_new_inode() calls lockdep_annotate_inode_mutex_key() and marks i_rwsem with the i_mutex_dir_key class. That resets the count and the owner of a lock somebody else may already hold by now... syzbot has been spamming us with the same godforsaken bug "WARNING in do_new_mount" since 2023. I can't take it anymore so I went looking. Afaict, syzbot's executor chdirs into a freshly mounted ntfs3 image, creates a directory and then mounts some pseudofs on it. Everytime the mkdir() takes longer than syzbot waits mount() runs concurrently: mkdir("./sys") mount(NULL, "./sys", "sysfs") ntfs_create_inode() d_instantiate() user_path_at() finds the dentry do_lock_mount() inode_lock(inode) namespace_lock() unlock_new_inode() lockdep_annotate_inode_mutex_key() init_rwsem(&inode->i_rwsem) unlock_mount() inode_unlock(inode) The mount side then releases a lock that according to the rwsem nobody holds: DEBUG_RWSEMS_WARN_ON((rwsem_owner
osv:AZL-109007
kernel
Fixed versions: Not specified
Complete source record
{
"id": "9b98641db92acc95b8b8b3e9a3ddfda4430a1d16986369cb9c8168049e383652",
"url": "https://osv.dev/vulnerability/AZL-109007",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "CVE-2026-98539 affecting package kernel 6.6.157.1-1",
"summary": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot's \"WARNING in do_new_mount\" saga ntfs_create_inode() creates a new inode via ntfs_new_inode(). It hashes it with insert_inode_locked() and so it's marked as I_NEW until unlock_new_inode(). ntfs 3 calls d_instantiate() in between though... Since the dentry was already hashed by the lookup before the create any path walk finds it without touching the parent's i_rwsem and so can lock the inode. If the inode is a directory unlock_new_inode() calls lockdep_annotate_inode_mutex_key() and marks i_rwsem with the i_mutex_dir_key class. That resets the count and the owner of a lock somebody else may already hold by now... syzbot has been spamming us with the same godforsaken bug \"WARNING in do_new_mount\" since 2023. I can't take it anymore so I went looking. Afaict, syzbot's executor chdirs into a freshly mounted ntfs3 image, creates a directory and then mounts some pseudofs on it. Everytime the mkdir() takes longer than syzbot waits mount() runs concurrently: mkdir(\"./sys\") mount(NULL, \"./sys\", \"sysfs\") ntfs_create_inode() d_instantiate() user_path_at() finds the dentry do_lock_mount() inode_lock(inode) namespace_lock() unlock_new_inode() lockdep_annotate_inode_mutex_key() init_rwsem(&inode->i_rwsem) unlock_mount() inode_unlock(inode) The mount side then releases a lock that according to the rwsem nobody holds: DEBUG_RWSEMS_WARN_ON((rwsem_owner",
"evidence": "osv:AZL-109007",
"products": [
{
"name": {
"value": "kernel",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "AZL-109007",
"aliases": [
"AZL-109007"
],
"affected": [
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"last_affected": "6.6.157.1-1"
}
]
}
],
"package": {
"name": "kernel",
"purl": "pkg:rpm/azure-linux/kernel",
"ecosystem": "Azure Linux:3"
},
"database_specific": {
"source": "https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-109007.json"
}
}
],
"modified": "2026-10-27T05:36:16Z",
"provider": "osv",
"upstream": [
"CVE-2026-98539"
],
"references": [
"https://nvd.nist.gov/vuln/detail/CVE-2026-98539"
]
},
"related_cves": [
{
"value": "CVE-2026-98539",
"evidence": "/upstream"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 460427,
"published_at": "2026-10-18T16:17:05+00:00"
}