diff options
| author | Darrick J. Wong <djwong@kernel.org> | 2024-04-15 14:55:05 -0700 |
|---|---|---|
| committer | Darrick J. Wong <djwong@kernel.org> | 2024-04-15 14:58:59 -0700 |
| commit | 5f204051d998ec3d7306db0d749bddcbf4c97693 (patch) | |
| tree | fbf4b51ab481d698a0e7186efe382fed5ca87112 /fs/xfs/scrub/nlinks.c | |
| parent | 2935213a6831a0087442d406301c2cdcc87b0f61 (diff) | |
xfs: pin inodes that would otherwise overflow link count
The VFS inc_nlink function does not explicitly check for integer
overflows in the i_nlink field. Instead, it checks the link count
against s_max_links in the vfs_{link,create,rename} functions. XFS
sets the maximum link count to 2.1 billion, so integer overflows should
not be a problem.
However. It's possible that online repair could find that a file has
more than four billion links, particularly if the link count got
corrupted while creating hardlinks to the file. The di_nlinkv2 field is
not large enough to store a value larger than 2^32, so we ought to
define a magic pin value of ~0U which means that the inode never gets
deleted. This will prevent a UAF error if the repair finds this
situation and users begin deleting links to the file.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'fs/xfs/scrub/nlinks.c')
| -rw-r--r-- | fs/xfs/scrub/nlinks.c | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/fs/xfs/scrub/nlinks.c b/fs/xfs/scrub/nlinks.c index c456523fac9c..fcb9c473f372 100644 --- a/fs/xfs/scrub/nlinks.c +++ b/fs/xfs/scrub/nlinks.c @@ -607,9 +607,11 @@ xchk_nlinks_compare_inode( * this as a corruption. The VFS won't let users increase the link * count, but it will let them decrease it. */ - if (total_links > XFS_MAXLINK) { + if (total_links > XFS_NLINK_PINNED) { xchk_ino_set_corrupt(sc, ip->i_ino); goto out_corrupt; + } else if (total_links > XFS_MAXLINK) { + xchk_ino_set_warning(sc, ip->i_ino); } /* Link counts should match. */ |