In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput
During unmount process of nilfs2, nothing holds nilfsroot structure after nilfs2 detaches its writer in nilfsdetachlogwriter(). Previously, nilfsevictinode() could cause use-after-free read for nilfsroot if inodes are left in "garbagelist" and released by nilfsdisposelist at the end of nilfsdetachlogwriter(), and this bug was fixed by commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfsroot in nilfsevictinode()").
However, it turned out that there is another possibility of UAF in the call path where markinodedirty_sync() is called from iput():
nilfsdetachlogwriter() nilfsdisposelist() iput() markinodedirtysync() __markinodedirty() nilfsdirtyinode() _nilfsmarkinodedirty() nilfsloadinodeblock() --> causes UAF of nilfsroot struct
This can happen after commit 0ae45f63d4ef ("vfs: add support for a lazytime mount option"), which changed iput() to call markinodedirtysync() on its final reference if istate has IDIRTYTIME flag and i_nlink is non-zero.
This issue appears after commit 28a65b49eb53 ("nilfs2: do not write dirty data after degenerating to read-only") when using the syzbot reproducer, but the issue has potentially existed before.
Fix this issue by adding a "purging flag" to the nilfs structure, setting that flag while disposing the "garbage_list" and checking it in _nilfsmarkinodedirty().
Unlike commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfsroot in nilfsevictinode()"), this patch does not rely on nswriter to determine whether to skip operations, so as not to break recovery on mount. The nilfssalvageorphan_logs routine dirties the buffer of salvaged data before attaching the log writer, so changing __nilfsmarkinodedirty() to skip the operation when nswriter is NULL will cause recovery write to fail. The purpose of using the cleanup-only flag is to allow for narrowing of such conditions.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/53xxx/CVE-2023-53311.json"
}