kernel/linux.git/security/smack, branch v5.4.50

Smack: slab-out-of-bounds in vsscanf

2020-06-17T14:40:36+00:00

commit 84e99e58e8d1e26f04c097f4266e431a33987f36 upstream. Add barrier to soob. Return -EOVERFLOW if the buffer is exceeded. Suggested-by: Hillf Danton Reported-by: syzbot+bfdd4a2f07be52351350@syzkaller.appspotmail.com Signed-off-by: Casey Schaufler Signed-off-by: Greg Kroah-Hartman

smack: avoid unused 'sip' variable warning

2020-06-17T14:40:22+00:00

[ Upstream commit 00720f0e7f288d29681d265c23b22bb0f0f4e5b4 ] The mix of IS_ENABLED() and #ifdef checks has left a combination that causes a warning about an unused variable: security/smack/smack_lsm.c: In function 'smack_socket_connect': security/smack/smack_lsm.c:2838:24: error: unused variable 'sip' [-Werror=unused-variable] 2838 | struct sockaddr_in6 *sip = (struct sockaddr_in6 *)sap; Change the code to use C-style checks consistently so the compiler can handle it correctly. Fixes: 87fbfffcc89b ("broken ping to ipv6 linklocal addresses on debian buster") Signed-off-by: Arnd Bergmann Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin

broken ping to ipv6 linklocal addresses on debian buster

2020-02-11T12:35:43+00:00

commit 87fbfffcc89b92a4281b0aa53bd06af714087889 upstream. I am seeing ping failures to IPv6 linklocal addresses with Debian buster. Easiest example to reproduce is: $ ping -c1 -w1 ff02::1%eth1 connect: Invalid argument $ ping -c1 -w1 ff02::1%eth1 PING ff02::01%eth1(ff02::1%eth1) 56 data bytes 64 bytes from fe80::e0:f9ff:fe0c:37%eth1: icmp_seq=1 ttl=64 time=0.059 ms git bisect traced the failure to commit b9ef5513c99b ("smack: Check address length before reading address family") Arguably ping is being stupid since the buster version is not setting the address family properly (ping on stretch for example does): $ strace -e connect ping6 -c1 -w1 ff02::1%eth1 connect(5, {sa_family=AF_UNSPEC, sa_data="\4\1\0\0\0\0\377\2\0\0\0\0\0\0\0\0\0\0\0\0\0\1\3\0\0\0"}, 28) = -1 EINVAL (Invalid argument) but the command works fine on kernels prior to this commit, so this is breakage which goes against the Linux paradigm of "don't break userspace" Cc: stable@vger.kernel.org Reported-by: David Ahern Suggested-by: Tetsuo Handa Signed-off-by: Casey Schaufler Signed-off-by: Greg Kroah-Hartman security/smack/smack_lsm.c | 41 +++++++++++++++++++---------------------- security/smack/smack_lsm.c | 41 +++++++++++++++++++---------------------- 1 file changed, 19 insertions(+), 22 deletions(-)

Merge tag 'smack-for-5.4-rc1' of git://github.com/cschaufler/smack-next

2019-09-23T21:25:45+00:00

Pull smack updates from Casey Schaufler: "Four patches for v5.4. Nothing is major. All but one are in response to mechanically detected potential issues. The remaining patch cleans up kernel-doc notations" * tag 'smack-for-5.4-rc1' of git://github.com/cschaufler/smack-next: smack: use GFP_NOFS while holding inode_smack::smk_lock security: smack: Fix possible null-pointer dereferences in smack_socket_sock_rcv_skb() smack: fix some kernel-doc notations Smack: Don't ignore other bprm->unsafe flags if LSM_UNSAFE_PTRACE is set

smack: use GFP_NOFS while holding inode_smack::smk_lock

2019-09-04T16:37:07+00:00

inode_smack::smk_lock is taken during smack_d_instantiate(), which is called during a filesystem transaction when creating a file on ext4. Therefore to avoid a deadlock, all code that takes this lock must use GFP_NOFS, to prevent memory reclaim from waiting for the filesystem transaction to complete. Reported-by: syzbot+0eefc1e06a77d327a056@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Casey Schaufler

security: smack: Fix possible null-pointer dereferences in smack_socket_sock_rcv_skb()

2019-09-04T16:37:07+00:00

In smack_socket_sock_rcv_skb(), there is an if statement on line 3920 to check whether skb is NULL: if (skb && skb->secmark != 0) This check indicates skb can be NULL in some cases. But on lines 3931 and 3932, skb is used: ad.a.u.net->netif = skb->skb_iif; ipv6_skb_to_auditdata(skb, &ad.a, NULL); Thus, possible null-pointer dereferences may occur when skb is NULL. To fix these possible bugs, an if statement is added to check skb. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai Signed-off-by: Casey Schaufler

smack: fix some kernel-doc notations

2019-09-04T16:37:07+00:00

Fix/add kernel-doc notation and fix typos in security/smack/. Signed-off-by: Liguang Zhang Signed-off-by: Casey Schaufler

Smack: Don't ignore other bprm->unsafe flags if LSM_UNSAFE_PTRACE is set

2019-09-04T16:36:57+00:00

There is a logic bug in the current smack_bprm_set_creds(): If LSM_UNSAFE_PTRACE is set, but the ptrace state is deemed to be acceptable (e.g. because the ptracer detached in the meantime), the other ->unsafe flags aren't checked. As far as I can tell, this means that something like the following could work (but I haven't tested it): - task A: create task B with fork() - task B: set NO_NEW_PRIVS - task B: install a seccomp filter that makes open() return 0 under some conditions - task B: replace fd 0 with a malicious library - task A: attach to task B with PTRACE_ATTACH - task B: execve() a file with an SMACK64EXEC extended attribute - task A: while task B is still in the middle of execve(), exit (which destroys the ptrace relationship) Make sure that if any flags other than LSM_UNSAFE_PTRACE are set in bprm->unsafe, we reject the execve(). Cc: stable@vger.kernel.org Fixes: 5663884caab1 ("Smack: unify all ptrace accesses in the smack") Signed-off-by: Jann Horn Signed-off-by: Casey Schaufler

Merge branch 'work.mount0' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2019-07-19T17:42:02+00:00

Pull vfs mount updates from Al Viro: "The first part of mount updates. Convert filesystems to use the new mount API" * 'work.mount0' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (63 commits) mnt_init(): call shmem_init() unconditionally constify ksys_mount() string arguments don't bother with registering rootfs init_rootfs(): don't bother with init_ramfs_fs() vfs: Convert smackfs to use the new mount API vfs: Convert selinuxfs to use the new mount API vfs: Convert securityfs to use the new mount API vfs: Convert apparmorfs to use the new mount API vfs: Convert openpromfs to use the new mount API vfs: Convert xenfs to use the new mount API vfs: Convert gadgetfs to use the new mount API vfs: Convert oprofilefs to use the new mount API vfs: Convert ibmasmfs to use the new mount API vfs: Convert qib_fs/ipathfs to use the new mount API vfs: Convert efivarfs to use the new mount API vfs: Convert configfs to use the new mount API vfs: Convert binfmt_misc to use the new mount API convenience helper: get_tree_single() convenience helper get_tree_nodev() vfs: Kill sget_userns() ...

Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs"

2019-07-11T01:43:43+00:00

This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus effectively commits 7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by: Eric Biggers Cc: David Howells Cc: James Morris Signed-off-by: Linus Torvalds