summaryrefslogtreecommitdiff
path: root/fs/namei.c
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2015-05-08 03:37:40 +0300
committerAl Viro <viro@zeniv.linux.org.uk>2015-05-11 15:13:13 +0300
commit31956502dd2c9432523d01373a9dc0e5931cfa1c (patch)
tree113687c758ac261f3a72c4027baf0007ab6d5647 /fs/namei.c
parent6548fae2eca6b66c7257af6663fdbdf5a50745fd (diff)
downloadlinux-31956502dd2c9432523d01373a9dc0e5931cfa1c.tar.xz
namei: make may_follow_link() safe in RCU mode
We *can't* call that audit garbage in RCU mode - it's doing a weird mix of allocations (GFP_NOFS, immediately followed by GFP_KERNEL) and I'm not touching that... thing again. So if this security sclero^Whardening feature gets triggered when we are in RCU mode, tough - we'll fail with -ECHILD and have everything restarted in non-RCU mode. Only to hit the same test and fail, this time with EACCES and with (oh, rapture) an audit spew produced. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs/namei.c')
-rw-r--r--fs/namei.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/fs/namei.c b/fs/namei.c
index 998c3c2c9488..20bf494307c9 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -794,6 +794,9 @@ static inline int may_follow_link(struct nameidata *nd)
if (uid_eq(parent->i_uid, inode->i_uid))
return 0;
+ if (nd->flags & LOOKUP_RCU)
+ return -ECHILD;
+
audit_log_link_denied("follow_link", &nd->stack[0].link);
return -EACCES;
}