fkie_cve-2023-53311
Vulnerability from fkie_nvd
Published
2025-09-16 17:15
Modified
2025-09-17 14:18
Severity ?
Summary
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 nilfs_root structure after nilfs2 detaches its writer in nilfs_detach_log_writer(). Previously, nilfs_evict_inode() could cause use-after-free read for nilfs_root if inodes are left in "garbage_list" and released by nilfs_dispose_list at the end of nilfs_detach_log_writer(), and this bug was fixed by commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()"). However, it turned out that there is another possibility of UAF in the call path where mark_inode_dirty_sync() is called from iput(): nilfs_detach_log_writer() nilfs_dispose_list() iput() mark_inode_dirty_sync() __mark_inode_dirty() nilfs_dirty_inode() __nilfs_mark_inode_dirty() nilfs_load_inode_block() --> causes UAF of nilfs_root struct This can happen after commit 0ae45f63d4ef ("vfs: add support for a lazytime mount option"), which changed iput() to call mark_inode_dirty_sync() on its final reference if i_state has I_DIRTY_TIME 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 __nilfs_mark_inode_dirty(). Unlike commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()"), this patch does not rely on ns_writer to determine whether to skip operations, so as not to break recovery on mount. The nilfs_salvage_orphan_logs routine dirties the buffer of salvaged data before attaching the log writer, so changing __nilfs_mark_inode_dirty() to skip the operation when ns_writer is NULL will cause recovery write to fail. The purpose of using the cleanup-only flag is to allow for narrowing of such conditions.
Impacted products
Vendor Product Version



{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput\n\nDuring unmount process of nilfs2, nothing holds nilfs_root structure after\nnilfs2 detaches its writer in nilfs_detach_log_writer().  Previously,\nnilfs_evict_inode() could cause use-after-free read for nilfs_root if\ninodes are left in \"garbage_list\" and released by nilfs_dispose_list at\nthe end of nilfs_detach_log_writer(), and this bug was fixed by commit\n9b5a04ac3ad9 (\"nilfs2: fix use-after-free bug of nilfs_root in\nnilfs_evict_inode()\").\n\nHowever, it turned out that there is another possibility of UAF in the\ncall path where mark_inode_dirty_sync() is called from iput():\n\nnilfs_detach_log_writer()\n  nilfs_dispose_list()\n    iput()\n      mark_inode_dirty_sync()\n        __mark_inode_dirty()\n          nilfs_dirty_inode()\n            __nilfs_mark_inode_dirty()\n              nilfs_load_inode_block() --\u003e causes UAF of nilfs_root struct\n\nThis can happen after commit 0ae45f63d4ef (\"vfs: add support for a\nlazytime mount option\"), which changed iput() to call\nmark_inode_dirty_sync() on its final reference if i_state has I_DIRTY_TIME\nflag and i_nlink is non-zero.\n\nThis issue appears after commit 28a65b49eb53 (\"nilfs2: do not write dirty\ndata after degenerating to read-only\") when using the syzbot reproducer,\nbut the issue has potentially existed before.\n\nFix this issue by adding a \"purging flag\" to the nilfs structure, setting\nthat flag while disposing the \"garbage_list\" and checking it in\n__nilfs_mark_inode_dirty().\n\nUnlike commit 9b5a04ac3ad9 (\"nilfs2: fix use-after-free bug of nilfs_root\nin nilfs_evict_inode()\"), this patch does not rely on ns_writer to\ndetermine whether to skip operations, so as not to break recovery on\nmount.  The nilfs_salvage_orphan_logs routine dirties the buffer of\nsalvaged data before attaching the log writer, so changing\n__nilfs_mark_inode_dirty() to skip the operation when ns_writer is NULL\nwill cause recovery write to fail.  The purpose of using the cleanup-only\nflag is to allow for narrowing of such conditions."
    }
  ],
  "id": "CVE-2023-53311",
  "lastModified": "2025-09-17T14:18:55.093",
  "metrics": {},
  "published": "2025-09-16T17:15:36.967",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/11afd67f1b3c28eb216e50a3ca8dbcb69bb71793"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/3645510cf926e6af2f4d44899370d7e5331c93bd"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/37207240872456fbab44a110bde6640445233963"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5828d5f5dc877dcfdd7b23102e978e2ecfd86d82"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7532ff6edbf5242376b24a95a2fefb59bb653e5a"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/a3c3b4cbf9b8554120fb230e6516e980c6277487"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/d2c539c216cce74837a9cf5804eb205939b82227"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f8654743a0e6909dc634cbfad6db6816f10f3399"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…