user/sven/linux.git/security, branch v4.19.225

selinux: initialize proto variable in selinux_ip_postroute_compat()

2022-01-05T11:34:58Z

commit 732bc2ff080c447f8524f40c970c481f5da6eed3 upstream. Clang static analysis reports this warning hooks.c:5765:6: warning: 4th function call argument is an uninitialized value if (selinux_xfrm_postroute_last(sksec->sid, skb, &ad, proto)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ selinux_parse_skb() can return ok without setting proto. The later call to selinux_xfrm_postroute_last() does an early check of proto and can return ok if the garbage proto value matches. So initialize proto. Cc: stable@vger.kernel.org Fixes: eef9b41622f2 ("selinux: cleanup selinux_xfrm_sock_rcv_skb() and selinux_xfrm_postroute_last()") Signed-off-by: Tom Rix [PM: typo/spelling and checkpatch.pl description fixes] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman

fortify: Explicitly disable Clang support

2021-11-26T10:36:18Z

commit a52f8a59aef46b59753e583bf4b28fccb069ce64 upstream. Clang has never correctly compiled the FORTIFY_SOURCE defenses due to a couple bugs: Eliding inlines with matching __builtin_* names https://bugs.llvm.org/show_bug.cgi?id=50322 Incorrect __builtin_constant_p() of some globals https://bugs.llvm.org/show_bug.cgi?id=41459 In the process of making improvements to the FORTIFY_SOURCE defenses, the first (silent) bug (coincidentally) becomes worked around, but exposes the latter which breaks the build. As such, Clang must not be used with CONFIG_FORTIFY_SOURCE until at least latter bug is fixed (in Clang 13), and the fortify routines have been rearranged. Update the Kconfig to reflect the reality of the current situation. Signed-off-by: Kees Cook Acked-by: Nick Desaulniers Link: https://lore.kernel.org/lkml/CAKwvOd=A+ueGV2ihdy5GtgR2fQbcXjjAtVxv3=cPjffpebZB7A@mail.gmail.com Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

apparmor: fix error check

2021-11-26T10:36:14Z

[ Upstream commit d108370c644b153382632b3e5511ade575c91c86 ] clang static analysis reports this representative problem: label.c:1463:16: warning: Assigned value is garbage or undefined label->hname = name; ^ ~~~~ In aa_update_label_name(), this the problem block of code if (aa_label_acntsxprint(&name, ...) == -1) return res; On failure, aa_label_acntsxprint() has a more complicated return that just -1. So check for a negative return. It was also noted that the aa_label_acntsxprint() main comment refers to a nonexistent parameter, so clean up the comment. Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels") Signed-off-by: Tom Rix Reviewed-by: Nick Desaulniers Signed-off-by: John Johansen Signed-off-by: Sasha Levin

smackfs: use netlbl_cfg_cipsov4_del() for deleting cipso_v4_doi

2021-11-26T10:36:10Z

[ Upstream commit 0934ad42bb2c5df90a1b9de690f93de735b622fe ] syzbot is reporting UAF at cipso_v4_doi_search() [1], for smk_cipso_doi() is calling kfree() without removing from the cipso_v4_doi_list list after netlbl_cfg_cipsov4_map_add() returned an error. We need to use netlbl_cfg_cipsov4_del() in order to remove from the list and wait for RCU grace period before kfree(). Link: https://syzkaller.appspot.com/bug?extid=93dba5b91f0fed312cbd [1] Reported-by: syzbot Signed-off-by: Tetsuo Handa Fixes: 6c2e8ac0953fccdd ("netlabel: Update kernel configuration API") Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin

smackfs: use __GFP_NOFAIL for smk_cipso_doi()

2021-11-26T10:36:06Z

[ Upstream commit f91488ee15bd3cac467e2d6a361fc2d34d1052ae ] syzbot is reporting kernel panic at smk_cipso_doi() due to memory allocation fault injection [1]. The reason for need to use panic() was not explained. But since no fix was proposed for 18 months, for now let's use __GFP_NOFAIL for utilizing syzbot resource on other bugs. Link: https://syzkaller.appspot.com/bug?extid=89731ccb6fec15ce1c22 [1] Reported-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin

smackfs: Fix use-after-free in netlbl_catmap_walk()

2021-11-26T10:36:04Z

[ Upstream commit 0817534ff9ea809fac1322c5c8c574be8483ea57 ] Syzkaller reported use-after-free bug as described in [1]. The bug is triggered when smk_set_cipso() tries to free stale category bitmaps while there are concurrent reader(s) using the same bitmaps. Wait for RCU grace period to finish before freeing the category bitmaps in smk_set_cipso(). This makes sure that there are no more readers using the stale bitmaps and freeing them should be safe. [1] https://lore.kernel.org/netdev/000000000000a814c505ca657a4e@google.com/ Reported-by: syzbot+3f91de0b813cc3d19a80@syzkaller.appspotmail.com Signed-off-by: Pawan Gupta Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin

evm: mark evm_fixmode as __ro_after_init

2021-11-26T10:36:01Z

commit 32ba540f3c2a7ef61ed5a577ce25069a3d714fc9 upstream. The evm_fixmode is only configurable by command-line option and it is never modified outside initcalls, so declaring it with __ro_after_init is better. Signed-off-by: Austin Kim Cc: stable@vger.kernel.org Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman

binder: use cred instead of task for selinux checks

2021-11-26T10:35:56Z

commit 52f88693378a58094c538662ba652aff0253c4fe upstream. Since binder was integrated with selinux, it has passed 'struct task_struct' associated with the binder_proc to represent the source and target of transactions. The conversion of task to SID was then done in the hook implementations. It turns out that there are race conditions which can result in an incorrect security context being used. Fix by using the 'struct cred' saved during binder_open and pass it to the selinux subsystem. Cc: stable@vger.kernel.org # 5.14 (need backport for earlier stables) Fixes: 79af73079d75 ("Add security hooks to binder and implement the hooks for SELinux.") Suggested-by: Jann Horn Signed-off-by: Todd Kjos Acked-by: Casey Schaufler Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman

apparmor: remove duplicate macro list_entry_is_head()

2021-09-26T11:39:47Z

commit 9801ca279ad37f72f71234fa81722afd95a3f997 upstream. Strangely I hadn't had noticed the existence of the list_entry_is_head() in apparmor code when added the same one in the list.h. Luckily it's fully identical and didn't break builds. In any case we don't need a duplicate anymore, thus remove it from apparmor code. Link: https://lkml.kernel.org/r/20201208100639.88182-1-andriy.shevchenko@linux.intel.com Fixes: e130816164e244 ("include/linux/list.h: add a macro to test if entry is pointing to the head") Signed-off-by: Andy Shevchenko Acked-by: John Johansen Cc: James Morris Cc: "Serge E . Hallyn " Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Nobuhiro Iwamatsu (CIP) Signed-off-by: Greg Kroah-Hartman

Smack: Fix wrong semantics in smk_access_entry()

2021-09-22T09:48:03Z

[ Upstream commit 6d14f5c7028eea70760df284057fe198ce7778dd ] In the smk_access_entry() function, if no matching rule is found in the rust_list, a negative error code will be used to perform bit operations with the MAY_ enumeration value. This is semantically wrong. This patch fixes this issue. Signed-off-by: Tianjia Zhang Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin