CVE-2026-53244

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> VFS: fix possible failure to unlock in nfsd4_create_file()<br /> <br /> atomic_create() in fs/namei.c drops the reference to the dentry<br /> when it returns an error.<br /> This behaviour was imported into dentry_create() so that it<br /> will drop the reference if an error is returned from atomic_create(),<br /> though not if vfs_create() returns an error (in the case where<br /> -&gt;atomic_create is not supported).<br /> <br /> The caller - nfsd4_create_file() - is made aware of this by checking<br /> path-&gt;dentry, which will either be a counted reference to a dentry, or<br /> an error pointer.<br /> <br /> However the change to use start_creating()/end_creating() (which landed<br /> shortly before the dentry_create() change landed, though was likely<br /> developed around the same time) means that nfsd4_create_file() *needs* a<br /> valid dentry so that it can unlock the parent.<br /> <br /> The net result is that if NFSD exports a filesystem which uses<br /> -&gt;atomic_create, and if a call to -&gt;atomic_create returns an error, then<br /> nfsd4_create_file() will pass an error pointer to end_creating()<br /> and the parent will not be unlocked.<br /> <br /> Fix this by changing dentry_create() to make sure path-&gt;dentry is always<br /> a valid dentry, never an error-pointer. The actual error is already<br /> returned a different way.<br /> <br /> Note that if -&gt;atomic_create() returns a different dentry (which may not<br /> be possible in practice) we are guaranteed (because it is only ever<br /> provided by d_spliace_alias()) that it will have the same d_parent and<br /> so it will have the same effect when passed to end_creating().