linux-kernel - Re: [PATCH] selinux: KASAN; slab-out-of-bounds in avc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHC9VhSNc5AeVDh69SV9-pSLgsC1T0Fip=Y3nepYCdc8FBFijg@mail.gmail.com>
Date: Wed, 11 Dec 2024 13:02:46 -0500
From: Paul Moore <paul@...l-moore.com>
To: Joey Jiao <quic_jiangenj@...cinc.com>
Cc: Stephen Smalley <stephen.smalley.work@...il.com>, Ondrej Mosnacek <omosnace@...hat.com>, 
	"open list:SELINUX SECURITY MODULE" <selinux@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>, 
	kernel@...cinc.com
Subject: Re: [PATCH] selinux: KASAN; slab-out-of-bounds in avc_lookup

On Mon, Dec 9, 2024 at 8:00 PM Joey Jiao <quic_jiangenj@...cinc.com> wrote:
> From: "Jiao, Joey" <quic_jiangenj@...cinc.com>
>
> BUG: KASAN: slab-out-of-bounds in avc_lookup+0x174/0x298
> Read of size 8 at addr ffffff8846ef70b1 by task spdaemon/1037
>
> Call trace:
>  dump_backtrace+0xf0/0x13c
>  show_stack+0x18/0x28
>  dump_stack_lvl+0xd0/0x128
>  print_report+0x13c/0x6f8
>  kasan_report+0xe8/0x148
>  __asan_load8+0x98/0xa0
>  avc_lookup+0x174/0x298
>  avc_has_perm_noaudit+0x60/0x12c
>  selinux_inode_permission+0x278/0x3cc
>  security_inode_permission+0x84/0xc8
>  inode_permission+0xb8/0x2b8
>  link_path_walk+0x178/0x7c0
>  path_lookupat+0x6c/0x298
>  filename_lookup+0x11c/0x2e4
>  vfs_statx+0xb4/0x3f0
>  vfs_fstatat+0xfc/0x3e4
>  __arm64_sys_newfstatat+0x88/0x340
>  invoke_syscall+0x6c/0x17c
>  el0_svc_common+0xf8/0x138
>  do_el0_svc+0x30/0x40
>  el0_svc+0x3c/0x70
>  el0t_64_sync_handler+0x68/0xbc
>  el0t_64_sync+0x19c/0x1a0
>
> To fix this, protect the rcu read access
>
> Signed-off-by: Jiao, Joey <quic_jiangenj@...cinc.com>
> ---
>  security/selinux/avc.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/security/selinux/avc.c b/security/selinux/avc.c
> index 32eb67fb3e42..ded3823d4451 100644
> --- a/security/selinux/avc.c
> +++ b/security/selinux/avc.c
> @@ -528,6 +528,7 @@ static inline struct avc_node *avc_search_node(u32 ssid, u32 tsid, u16 tclass)
>
>         hvalue = avc_hash(ssid, tsid, tclass);
>         head = &selinux_avc.avc_cache.slots[hvalue];
> +       rcu_read_lock();
>         hlist_for_each_entry_rcu(node, head, list) {
>                 if (ssid == node->ae.ssid &&
>                     tclass == node->ae.tclass &&
> @@ -536,6 +537,7 @@ static inline struct avc_node *avc_search_node(u32 ssid, u32 tsid, u16 tclass)
>                         break;
>                 }
>         }
> +       rcu_read_unlock();
>
>         return ret;
>  }
> --
> 2.47.1

Thanks for the bug report, do you have any more information about the
kernel that demonstrated this problem?

I'm asking because when I look at the kernel sources, all callers of
avc_search_node() should already be holding the RCU read lock:

  avc_has_extended_perms() or avc_has_perm_noaudit()
    avc_lookup()
      avc_search_node()

-- 
paul-moore.com