linux-kernel - Re: [RFC PATCH v3] UML: add support for KASAN under x86

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+bhBMDn80u=W8VBbn4uZg1oD8zsE3RJJC-YJRS2i8Q2oA@mail.gmail.com>
Date:   Fri, 27 May 2022 15:18:34 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     David Gow <davidgow@...gle.com>,
        Vincent Whitchurch <vincent.whitchurch@...s.com>,
        Patricia Alfonso <trishalfonso@...gle.com>,
        Jeff Dike <jdike@...toit.com>,
        Richard Weinberger <richard@....at>,
        anton.ivanov@...bridgegreys.com,
        Brendan Higgins <brendanhiggins@...gle.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        linux-um@...ts.infradead.org, LKML <linux-kernel@...r.kernel.org>,
        Daniel Latypov <dlatypov@...gle.com>
Subject: Re: [RFC PATCH v3] UML: add support for KASAN under x86_64

On Fri, 27 May 2022 at 15:15, Johannes Berg <johannes@...solutions.net> wrote:
>
> On Fri, 2022-05-27 at 15:09 +0200, Dmitry Vyukov wrote:
> > > I did note (this is more for kasan-dev@) that the "freed by" is fairly
> > > much useless when using kfree_rcu(), it might be worthwhile to annotate
> > > that somehow, so the stack trace is recorded by kfree_rcu() already,
> > > rather than just showing the RCU callback used for that.
> >
> > KASAN is doing it for several years now, see e.g.:
> > https://groups.google.com/g/syzkaller-bugs/c/eTW9zom4O2o/m/_v7cOo2RFwAJ
> >
>
> Hm. It didn't for me:

Please post a full report with line numbers and kernel version.

> > BUG: KASAN: use-after-free in ieee80211_vif_use_reserved_context+0x32d/0x40f [mac80211]
> > Read of size 4 at addr 0000000065c73340 by task kworker/u2:1/17
>
> Yes.
>
> > CPU: 0 PID: 17 Comm: kworker/u2:1 Tainted: G           O      5.18.0-rc1 #5
> > Workqueue: phy0 ieee80211_chswitch_work [mac80211]
> > Stack:
> >  60ba783f 00000000 10000c268f4e 60ba783f
> >  60e60847 70dc9928 719f6e99 00000000
> >  71883b20 60bb0b42 60bb0b19 65c73340
> > Call Trace:
> >  [<600447ea>] show_stack+0x13e/0x14d
> >  [<60bb0b42>] dump_stack_lvl+0x29/0x2e
> >  [<602ef7c0>] print_report+0x15d/0x60b
> >  [<602efdc0>] kasan_report+0x98/0xbd
> >  [<602f0cc2>] __asan_report_load4_noabort+0x1b/0x1d
> >  [<719f6e99>] ieee80211_vif_use_reserved_context+0x32d/0x40f [mac80211]
>
> This is the user, it just got freed during a function call a few lines
> up.
>
> > Allocated by task 16:
> >  save_stack_trace+0x2e/0x30
> >  stack_trace_save+0x81/0x9b
> >  kasan_save_stack+0x2d/0x54
> >  kasan_set_track+0x34/0x3e
> >  ____kasan_kmalloc+0x8d/0x99
> >  __kasan_kmalloc+0x10/0x12
> >  __kmalloc+0x1f6/0x20b
> >  ieee80211_alloc_chanctx+0xdc/0x35f [mac80211]
>
> This makes sense too.
>
> > Freed by task 8:
> >  save_stack_trace+0x2e/0x30
> >  stack_trace_save+0x81/0x9b
> >  kasan_save_stack+0x2d/0x54
> >  kasan_set_track+0x34/0x3e
> >  kasan_set_free_info+0x33/0x44
> >  ____kasan_slab_free+0x12b/0x149
> >  __kasan_slab_free+0x19/0x1b
> >  slab_free_freelist_hook+0x10b/0x16a
> >  kfree+0x10d/0x1fa
> >  kvfree+0x38/0x3a
> >  rcu_process_callbacks+0x2c5/0x349
>
> This is the RCU callback.
>
> > Last potentially related work creation:
> >  save_stack_trace+0x2e/0x30
> >  stack_trace_save+0x81/0x9b
> >  kasan_save_stack+0x2d/0x54
> >  __kasan_record_aux_stack+0xd5/0xe2
> >  kasan_record_aux_stack_noalloc+0x12/0x14
> >  insert_work+0x50/0xd7
> >  __queue_work+0x805/0x95c
> >  queue_work_on+0xba/0x131
> >  call_usermodehelper_exec+0x242/0x361
> >  kobject_uevent_env+0xe46/0xeaf
> >  kobject_uevent+0x12/0x14
> >  driver_register+0x37e/0x38d
> >  pcie_port_service_register+0x19d/0x1a5
>
> This stuff is completely unrelated.
>
> > The buggy address belongs to the object at 0000000065c73300
> >  which belongs to the cache kmalloc-192 of size 192
> > The buggy address is located 64 bytes inside of
> >  192-byte region [0000000065c73300, 0000000065c733c0)
> >
>
> and that's it?
>
> johannes
>
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@...glegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/6fa1ebe49b8d574fb1c82aefeeb54439d9c98750.camel%40sipsolutions.net.