linux-toradex.git/fs/xattr.c, branch v4.9.123

lsm: fix smack_inode_removexattr and xattr_getsecurity memleak

2017-10-12T09:51:19+00:00

commit 57e7ba04d422c3d41c8426380303ec9b7533ded9 upstream.

security_inode_getsecurity() provides the text string value
of a security attribute. It does not provide a "secctx".
The code in xattr_getsecurity() that calls security_inode_getsecurity()
and then calls security_release_secctx() happened to work because
SElinux and Smack treat the attribute and the secctx the same way.
It fails for cap_inode_getsecurity(), because that module has no
secctx that ever needs releasing. It turns out that Smack is the
one that's doing things wrong by not allocating memory when instructed
to do so by the "alloc" parameter.

The fix is simple enough. Change the security_release_secctx() to
kfree() because it isn't a secctx being returned by
security_inode_getsecurity(). Change Smack to allocate the string when
told to do so.

Note: this also fixes memory leaks for LSMs which implement
inode_getsecurity but not release_secctx, such as capabilities.

Signed-off-by: Casey Schaufler 
Reported-by: Konstantin Khlebnikov 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

fs/xattr.c: zero out memory copied to userspace in getxattr

2017-05-20T12:28:39+00:00

commit 81be3dee96346fbe08c31be5ef74f03f6b63cf68 upstream.

getxattr uses vmalloc to allocate memory if kzalloc fails.  This is
filled by vfs_getxattr and then copied to the userspace.  vmalloc,
however, doesn't zero out the memory so if the specific implementation
of the xattr handler is sloppy we can theoretically expose a kernel
memory.  There is no real sign this is really the case but let's make
sure this will not happen and use vzalloc instead.

Fixes: 779302e67835 ("fs/xattr.c:getxattr(): improve handling of allocation failures")
Link: http://lkml.kernel.org/r/20170306103327.2766-1-mhocko@kernel.org
Acked-by: Kees Cook 
Reported-by: Vlastimil Babka 
Signed-off-by: Michal Hocko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

xattr: Fix setting security xattrs on sockfs

2016-11-17T05:00:23+00:00

The IOP_XATTR flag is set on sockfs because sockfs supports getting the
"system.sockprotoname" xattr.  Since commit 6c6ef9f2, this flag is checked for
setxattr support as well.  This is wrong on sockfs because security xattr
support there is supposed to be provided by security_inode_setsecurity.  The
smack security module relies on socket labels (xattrs).

Fix this by adding a security xattr handler on sockfs that returns
-EAGAIN, and by checking for -EAGAIN in setxattr.

We cannot simply check for -EOPNOTSUPP in setxattr because there are
filesystems that neither have direct security xattr support nor support
via security_inode_setsecurity.  A more proper fix might be to move the
call to security_inode_setsecurity into sockfs, but it's not clear to me
if that is safe: we would end up calling security_inode_post_setxattr after
that as well.

Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Al Viro

vfs: Remove {get,set,remove}xattr inode operations

2016-10-08T01:48:36+00:00

These inode operations are no longer used; remove them.

Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Al Viro

xattr: Stop calling {get,set,remove}xattr inode operations

2016-10-08T00:10:44+00:00

All filesystems that support xattrs by now do so via xattr handlers.
They all define sb->s_xattr, and their getxattr, setxattr, and
removexattr inode operations use the generic inode operations.  On
filesystems that don't support xattrs, the xattr inode operations are
all NULL, and sb->s_xattr is also NULL.

This means that we can remove the getxattr, setxattr, and removexattr
inode operations and directly call the generic handlers, or better,
inline expand those handlers into fs/xattr.c.

Filesystems that do not support xattrs on some inodes should clear the
IOP_XATTR i_opflags flag in those inodes.  (Right now, some filesystems
have checks to disable xattrs on some inodes in the ->list, ->get, and
->set xattr handler operations instead.)  The IOP_XATTR flag is
automatically cleared in inodes of filesystems that don't have xattr
support.

In orangefs, symlinks do have a setxattr iop but no getxattr iop.  Add a
check for symlinks to orangefs_inode_getxattr to preserve the current,
weird behavior; that check may not be necessary though.

Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Al Viro

vfs: Check for the IOP_XATTR flag in listxattr

2016-10-08T00:10:44+00:00

When an inode doesn't support xattrs, turn listxattr off as well.

(When xattrs are "turned off", the VFS still passes security xattr
operations through to security modules, which can still expose inode
security labels that way.)

Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Al Viro

xattr: Add __vfs_{get,set,remove}xattr helpers

2016-10-08T00:10:44+00:00

Right now, various places in the kernel check for the existence of
getxattr, setxattr, and removexattr inode operations and directly call
those operations.  Switch to helper functions and test for the IOP_XATTR
flag instead.

Signed-off-by: Andreas Gruenbacher 
Acked-by: James Morris 
Signed-off-by: Al Viro

vfs: Use IOP_XATTR flag for bad-inode handling

2016-10-08T00:10:43+00:00

With this change, all the xattr handler based operations will produce an
-EIO result for bad inodes, and we no longer only depend on inode->i_op
to be set to bad_inode_ops.

Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Al Viro

vfs: Add IOP_XATTR inode operations flag

2016-10-08T00:10:42+00:00

The IOP_XATTR inode operations flag in inode->i_opflags indicates that
the inode has xattr support.  The flag is automatically set by
new_inode() on filesystems with xattr support (where sb->s_xattr is
defined), and cleared otherwise.  Filesystems can explicitly clear it
for inodes that should not have xattr support.

Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Al Viro

vfs: Move xattr_resolve_name to the front of fs/xattr.c

2016-10-08T00:10:42+00:00

Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Al Viro