[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200919165558.GH3421308@ZenIV.linux.org.uk>
Date: Sat, 19 Sep 2020 17:55:58 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Eric Biggers <ebiggers@...nel.org>, linux-fsdevel@...r.kernel.org,
Anant Thazhemadam <anant.thazhemadam@...il.com>,
linux-kernel-mentees@...ts.linuxfoundation.org,
syzbot+4191a44ad556eacc1a7a@...kaller.appspotmail.com,
linux-kernel@...r.kernel.org
Subject: Re: [Linux-kernel-mentees] [PATCH] fs: fix KMSAN uninit-value bug by
initializing nd in do_file_open_root
On Sat, Sep 19, 2020 at 05:17:27PM +0100, Al Viro wrote:
> Lovely... That would get an empty path and non-directory for a starting
> point, but it should end up with LAST_ROOT in nd->last_type. Which should
> not be able to reach the readers of those fields... Which kernel had
> that been on?
Yecchhh... I see what's going on; I suspect that this ought to be enough.
Folks, could somebody test it on the original reproducer setup?
diff --git a/fs/namei.c b/fs/namei.c
index e99e2a9da0f7..3f02cae7e73f 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2113,8 +2113,10 @@ static int link_path_walk(const char *name, struct nameidata *nd)
return PTR_ERR(name);
while (*name=='/')
name++;
- if (!*name)
+ if (!*name) {
+ nd->dir_mode = 0; // short-circuit the 'hardening' idiocy
return 0;
+ }
/* At this point we know we have a real path component. */
for(;;) {
Powered by blists - more mailing lists