5.4-stable patches

added patches:
	readdir-be-more-conservative-with-directory-entry-names.patch

diff --git a/queue-5.4/readdir-be-more-conservative-with-directory-entry-names.patch b/queue-5.4/readdir-be-more-conservative-with-directory-entry-names.patch
new file mode 100644 (file)
index 0000000..217b766
--- /dev/null
+++ b/queue-5.4/readdir-be-more-conservative-with-directory-entry-names.patch
@@ -0,0 +1,58 @@
+From 2c6b7bcd747201441923a0d3062577a8d1fbd8f8 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Thu, 23 Jan 2020 10:05:05 -0800
+Subject: readdir: be more conservative with directory entry names
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit 2c6b7bcd747201441923a0d3062577a8d1fbd8f8 upstream.
+
+Commit 8a23eb804ca4 ("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>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/readdir.c |    6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/fs/readdir.c
++++ b/fs/readdir.c
+@@ -102,10 +102,14 @@ EXPORT_SYMBOL(iterate_dir);
+  * filename length, and the above "soft error" worry means
+  * that it's probably better left alone until we have that
+  * issue clarified.
++ *
++ * Note the PATH_MAX check - it's arbitrary but the real
++ * kernel limit on a possible path component, not NAME_MAX,
++ * which is the technical standard limit.
+  */
+ static int verify_dirent_name(const char *name, int len)
+ {
+-      if (!len)
++      if (len <= 0 || len >= PATH_MAX)
+               return -EIO;
+       if (memchr(name, '/', len))
+               return -EIO;

diff --git a/queue-5.4/series b/queue-5.4/series
index cd06c12cc90a87bf8cb4d46ee7f097ee5e67b7b9..e7dc9414758f3a6545edd5da9cd17cf00d973cd6 100644 (file)
--- a/queue-5.4/series
+++ b/queue-5.4/series
@@ -84,3 +84,4 @@ xfrm-support-output_mark-for-offload-esp-packets.patch
 net-sk_msg-don-t-check-if-sock-is-locked-when-tearing-down-psock.patch
 do_last-fetch-directory-i_mode-and-i_uid-before-it-s-too-late.patch
 net-sonic-fix-cam-initialization.patch
+readdir-be-more-conservative-with-directory-entry-names.patch