From 4f891a2ff14d1a0228ef23435c29ba46b0a3fc05 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 27 Jan 2020 21:06:57 +0100 Subject: [PATCH] 5.4-stable patches added patches: readdir-be-more-conservative-with-directory-entry-names.patch --- ...servative-with-directory-entry-names.patch | 58 +++++++++++++++++++ queue-5.4/series | 1 + 2 files changed, 59 insertions(+) create mode 100644 queue-5.4/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 index 00000000000..217b7662238 --- /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 +Date: Thu, 23 Jan 2020 10:05:05 -0800 +Subject: readdir: be more conservative with directory entry names + +From: Linus Torvalds + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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 cd06c12cc90..e7dc9414758 100644 --- 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 -- 2.47.3