{"id":"CVE-2026-74359","summary":"configfs_lookup(): don't leave -\u003es_dentry dangling on failure","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nconfigfs_lookup(): don't leave -\u003es_dentry dangling on failure\n\nNormally -\u003es_dentry is cleared when dentry it's pointing to becomes\nnegative (on eviction, realistically).  However, that only happens\nif dentry gets to be positive in the first place; in case of inode\nallocation failure dentry never becomes positive, so -\u003ed_iput()\nis not called at all.\n\nWe do part of what normally would've been done by configfs_d_iput()\n(dropping the reference to configfs_dirent) manually, but we do\nnot clear -\u003es_dentry there.  Sloppy as it is, it does not matter in\ncase of configfs_create_{dir,link}() - there configfs_dirent does\nnot survive dropping the sole reference to it.\n\nHowever, for configfs_lookup() it *does* survive, with a dangling\npointer to soon to be freed dentry sitting it its -\u003es_dentry.\n\nSubsequent getdents(2) in that directory will end up dereferencing\nthat pointer in order to pick the inode number.  Use after free...\n\nThis is the minimal fix; the right approach is to set the linkage\nbetween dentry and configfs_dirent only after we know that we have\nan inode, but that takes more surgery and the bug had been there\nsince 2006, so...","modified":"2026-08-18T03:56:54.455308245Z","published":"2026-08-15T05:58:43.456Z","database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74359.json","cna_assigner":"Linux"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/10da12d352b7b2bb330a8609fdda9a58bf0e9856"},{"type":"WEB","url":"https://git.kernel.org/stable/c/3e83b2203aa59bd279e4f677ec793d49dc9d019e"},{"type":"WEB","url":"https://git.kernel.org/stable/c/57088b06109f3222963c639d8d743f42c2899b13"},{"type":"WEB","url":"https://git.kernel.org/stable/c/9c747dcee164ead300de90550ad9e4122f0d1bbb"},{"type":"WEB","url":"https://git.kernel.org/stable/c/b6e9c82522ddaa3ac0706b295ff4a71975d4f883"},{"type":"WEB","url":"https://git.kernel.org/stable/c/c3b073a209a9baa691b744318ac929fecdd8847c"},{"type":"WEB","url":"https://git.kernel.org/stable/c/eee07d769da5ac4e4f7bd0bc17828646a318d499"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74359.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74359"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"3d0f89bb169482d26d5aa4e82e763077e7e9bc4d"},{"fixed":"3e83b2203aa59bd279e4f677ec793d49dc9d019e"},{"fixed":"b6e9c82522ddaa3ac0706b295ff4a71975d4f883"},{"fixed":"eee07d769da5ac4e4f7bd0bc17828646a318d499"},{"fixed":"9c747dcee164ead300de90550ad9e4122f0d1bbb"},{"fixed":"c3b073a209a9baa691b744318ac929fecdd8847c"},{"fixed":"57088b06109f3222963c639d8d743f42c2899b13"},{"fixed":"10da12d352b7b2bb330a8609fdda9a58bf0e9856"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74359.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.6.16"},{"fixed":"5.15.212"}]},{"type":"ECOSYSTEM","events":[{"introduced":"5.16.0"},{"fixed":"6.1.178"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.2.0"},{"fixed":"6.6.145"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.7.0"},{"fixed":"6.12.97"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.40"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.1.5"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74359.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}]}