]> git.baikalelectronics.ru Git - kernel.git/commit
readdir: be more conservative with directory entry names
authorLinus Torvalds <torvalds@linux-foundation.org>
Thu, 23 Jan 2020 18:05:05 +0000 (10:05 -0800)
committerLinus Torvalds <torvalds@linux-foundation.org>
Thu, 23 Jan 2020 18:05:05 +0000 (10:05 -0800)
commitdf99fbd3e09a40a6f2fcd12e178d3b0c306abe49
tree8c8c596e7329bc7cd332ab80d3398633d0340612
parent7cc2a83a7dddaf67ec9929e4ac02c4f2b2b5422e
readdir: be more conservative with directory entry names

Commit 2ec5a2ba96d1 ("Make filldir[64]() verify the directory entry
filename is valid") added some minimal validity checks on the directory
entries passed to filldir[64]().  But they really were pretty minimal.

This fleshes out at least the name length check: we used to disallow
zero-length names, but really, negative lengths or oevr-long names
aren't ok either.  Both could happen if there is some filesystem
corruption going on.

Now, most filesystems tend to use just an "unsigned char" or similar for
the length of a directory entry name, so even with a corrupt filesystem
you should never see anything odd like that.  But since we then use the
name length to create the directory entry record length, let's make sure
it actually is half-way sensible.

Note how POSIX states that the size of a path component is limited by
NAME_MAX, but we actually use PATH_MAX for the check here.  That's
because while NAME_MAX is generally the correct maximum name length
(it's 255, for the same old "name length is usually just a byte on
disk"), there's nothing in the VFS layer that really cares.

So the real limitation at a VFS layer is the total pathname length you
can pass as a filename: PATH_MAX.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/readdir.c