Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150

[Paul Moore]

On Tue, Nov 13, 2018 at 8:52 AM Qian Cai <cai@xxxxxx> wrote:
> On 11/13/18 at 8:33 AM, Paul Moore wrote:
> > On Mon, Nov 12, 2018 at 10:11 PM Qian Cai <cai@xxxxxx> wrote:
> > > > On Nov 12, 2018, at 10:09 PM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > > >
> > > > On Mon, Nov 12, 2018 at 7:59 PM Qian Cai <cai@xxxxxx> wrote:
> > > >>> On Nov 12, 2018, at 7:41 PM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > > >>> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai <cai@xxxxxx> 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