Re: [linux-next:master] [slub] 3a34e8ea62: BUG:KASAN:slab-use-after-free_in_kmem_cache_rcu_uaf

[Oliver Sang <oliver.sang@intel.com>]

hi, Vlastimil Babka and Jann Horn,

On Mon, Aug 26, 2024 at 10:27:29PM +0200, Vlastimil Babka wrote:
> On 8/26/24 22:18, Jann Horn wrote:
> > Hi!
> > 
> > On Sun, Aug 25, 2024 at 11:45 AM kernel test robot
> > <oliver.sang@intel.com> wrote:
> >> Hello,
> >>
> >> kernel test robot noticed "BUG:KASAN:slab-use-after-free_in_kmem_cache_rcu_uaf" on:
> >>
> >> commit: 3a34e8ea62cdeba64a66fa4489059c59ba4ec285 ("slub: Introduce CONFIG_SLUB_RCU_DEBUG")
> >> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> >>
> >> [test failed on linux-next/master c79c85875f1af04040fe4492ed94ce37ad729c4d]
> >>
> >> in testcase: kunit
> >> version:
> >> with following parameters:
> >>
> >>         group: group-00
> >>
> >>
> >>
> >> compiler: gcc-12
> >> test machine: 36 threads 1 sockets Intel(R) Core(TM) i9-10980XE CPU @ 3.00GHz (Cascade Lake) with 128G memory
> >>
> >> (please refer to attached dmesg/kmsg for entire log/backtrace)
> >>
> >>
> >>
> >> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> >> the same patch/commit), kindly add following tags
> >> | Reported-by: kernel test robot <oliver.sang@intel.com>
> >> | Closes: https://lore.kernel.org/oe-lkp/202408251741.4ce3b34e-oliver.sang@intel.com
> >>
> >>
> >> The kernel config and materials to reproduce are available at:
> >> https://download.01.org/0day-ci/archive/20240825/202408251741.4ce3b34e-oliver.sang@intel.com
> > 
> > Oh, this is a weird one...
> 
> As I replied I think lkp simply reacts to the BUG: in dmesg and doesn't
> filter it out as an expected test output.

got it. we will follow to filter out expected test output.

> 
> > Do you happen to have either the vmlinux ELF file that this issue
> > happened with, or a version of the bug report that's been run through
> > scripts/decode_stacktrace.sh, so that we can tell whether the reported
> > slab-use-after-free is on line 1029 (which would mean that either ASAN
> > is not tracking the state of the object correctly or the object is
> 
> The reported freed stack suggests the object was already freed by rcu, so we
> should be past the rcu_read_unlock();
> 
> > freed earlier than it should) or line 1039 (which would mean the
> > KUNIT_EXPECT_KASAN_FAIL() is not working at it should)?
> 
> There's also "ok 38 kmem_cache_rcu_uaf" in the log so the kunit test macro
> is satisfied.

thanks a lot for information!