linux-kernel - Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 13 Nov 2018 09:29:29 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     cai@....us
Cc:     Eric Paris <eparis@...isplace.org>, linux-kernel@...r.kernel.org,
        selinux@...r.kernel.org, Stephen Smalley <sds@...ho.nsa.gov>
Subject: Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150

On Tue, Nov 13, 2018 at 8:52 AM Qian Cai <cai@....us> wrote:
> On 11/13/18 at 8:33 AM, Paul Moore wrote:
> > On Mon, Nov 12, 2018 at 10:11 PM Qian Cai <cai@....us> wrote:
> > > > On Nov 12, 2018, at 10:09 PM, Paul Moore <paul@...l-moore.com> wrote:
> > > >
> > > > On Mon, Nov 12, 2018 at 7:59 PM Qian Cai <cai@....us> wrote:
> > > >>> On Nov 12, 2018, at 7:41 PM, Paul Moore <paul@...l-moore.com> wrote:
> > > >>> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <cai@....us> wrote:
> > > >>>>
> > > >>>> Running the trinity fuzzer on the latest mainline (rc2) generates this,
> > > >>>>
> > > >>>> [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150
> > > >>>> [15029.887275] Read of size 2 at addr ffff801ec53c5080 by task trinity-main/18081
> > > >>>> [15029.887294]
> > > >>>> [15029.887304] CPU: 28 PID: 18081 Comm: trinity-main Tainted: G        W  OE     4.20.0-rc2+ #15
> > > >>>> [15029.887311] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.50 06/01/2018
> > > >>>> [15000.084786] [15029.887320] Call trace:
> > > >>>> [15029.915511]  dump_backtrace+0x0/0x2c8
> > > >>>> [15029.920046]  show_stack+0x24/0x30
> > > >>>> [15029.923367]  dump_stack+0x118/0x19c
> > > >>>> [15029.927539]  print_address_description+0x68/0x2a0
> > > >>>> [15029.932245]  kasan_report+0x1b4/0x348
> > > >>>> [15029.938760]  __asan_load2+0x7c/0xa0
> > > >>>> [15029.945098]  selinux_sctp_bind_connect+0x60/0x150
> > > >>>>
> > > >>>> [15029.950571]  security_sctp_bind_connect+0x58/0x90
> > > >>>> [15029.955493]  __sctp_setsockopt_connectx+0x68/0x128 [sctp]
> > > >>>> [15029.960943]  sctp_setsockopt+0x764/0x2928 [sctp]
> > > >>>> [15029.965564]  sock_common_setsockopt+0x6c/0x80
> > > >>>> [15029.969923]  __arm64_sys_setsockopt+0x13c/0x1f0
> > > >>>> [15029.974456]  el0_svc_handler+0xd4/0x198
> > > >>>> [15029.978293]  el0_svc+0x8/0xc
> > > >>>> [15029.981174]
> > > >>>> [15029.982667] Allocated by task 18081:
> > > >>>> [15029.986245]  kasan_kmalloc.part.1+0x40/0x108
> > > >>>> [15029.990517]  kasan_kmalloc+0xb4/0xc8
> > > >>>> [15029.994094]  __kmalloc_node+0x1c4/0x638
> > > >>>> [15029.997933]  kvmalloc_node+0x98/0xa8
> > > >>>> [15030.001511]  vmemdup_user+0x34/0x128
> > > >>>> [15030.005137]  __sctp_setsockopt_connectx+0x44/0x128 [sctp]
> > > >>>> [15030.010586]  sctp_setsockopt+0x764/0x2928 [sctp]
> > > >>>> [15030.015205]  sock_common_setsockopt+0x6c/0x80
> > > >>>> [15030.019564]  __arm64_sys_setsockopt+0x13c/0x1f0
> > > >>>> [15030.024096]  el0_svc_handler+0xd4/0x198
> > > >>>> [15030.027933]  el0_svc+0x8/0xc
> > > >>>> [15030.030814]
> > > >>>> [15030.032306] Freed by task 3025:
> > > >>>> [15030.035451]  __kasan_slab_free+0x114/0x228
> > > >>>> [15030.039548]  kasan_slab_free+0x10/0x18
> > > >>>> [15030.043299]  kfree+0x114/0x408
> > > >>>> [15030.046357]  selinux_sk_free_security+0x38/0x48
> > > >>>> [15030.050888]  security_sk_free+0x3c/0x58
> > > >>>> [15030.054727]  __sk_destruct+0x3e8/0x570
> > > >>>> [15030.058478]  sk_destruct+0x4c/0x58
> > > >>>> [15030.061881]  __sk_free+0x68/0x138
> > > >>>> [15030.065197]  sk_free+0x3c/0x48
> > > >>>> [15030.068255]  unix_release_sock+0x4a8/0x550
> > > >>>> [15030.072353]  unix_release+0x34/0x50
> > > >>>> [15030.075843]  __sock_release+0x74/0x110
> > > >>>> [15030.079593]  sock_close+0x24/0x38
> > > >>>> [15030.082913]  __fput+0x1b8/0x368
> > > >>>> [15030.086055]  ____fput+0x20/0x30
> > > >>>> [15030.089199]  task_work_run+0x14c/0x1a8
> > > >>>> [15030.092951]  do_notify_resume+0x1e4/0x200
> > > >>>> [15030.096961]  work_pending+0x8/0x14
> > > >>>
> > > >>> Any chance you have a reproducer for this?  Or at the very least a
> > > >>> line number inside selinux_sctp_bind_connect()?
> > > >>>
> > > >> Yes, running trinity as non-root will trigger it all the time on this
> > > >> aarch64 server so far.
> > > >
> > > > Is it just aarch64, or are you seeing it on other arches as well?
> > >
> > > I only have an aarch64 server to test so far.
> >
> > Did you see similar problems with 4.20-rc1?
>
> I did not test on -rc1.

I ran trinity a few times on my test kernel and nothing terrible
happened; this was expected since I don't have KASAN enabled in my
kernel builds at the moment.  I'm building a kernel with KASAN right
now to see if I can reproduce this on x86_64 (I don't have easy access
to a aarch64 system).

It might be helpful if you could also try to debug this issue just in
case it happens to be aarch64 specific or has something to do with
your particular configuration.

> > > >> $ trinity
> > > >>
> > > >> https://github.com/kernelslacker/trinity.git
> > > >>
> > > >> If you have a debug patch I am happy to try that as well if you
> > > >> need to gather more information.

-- 
paul moore
www.paul-moore.com