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

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: <20171205144718.GA27916@danjae.aot.lge.com>
Date:   Tue, 5 Dec 2017 23:47:18 +0900
From:   Namhyung Kim <namhyung@...nel.org>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Fengguang Wu <fengguang.wu@...el.com>,
        linux-kernel@...r.kernel.org, Wang Nan <wangnan0@...wei.com>,
        Ingo Molnar <mingo@...hat.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Will Deacon <will.deacon@....com>, lkp@...org,
        Dmitry Vyukov <dvyukov@...gle.com>, kasan-dev@...glegroups.com,
        kernel-team@....com
Subject: Re: BUG: KASAN: slab-out-of-bounds in perf_callchain_user+0x494/0x530

Hi Arnaldo,

On Tue, Dec 05, 2017 at 10:37:40AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Dec 05, 2017 at 05:11:56PM +0900, Namhyung Kim escreveu:
> > Also I'm not sure that the allocation failure check would work
> > correctly since it decrements nr_callchain_events when it fails.
> 
> Can you elaborate a bit more?

Sure, I mean the following code:

	mutex_lock(&callchain_mutex);

	count = atomic_inc_return(&nr_callchain_events);
	if (WARN_ON_ONCE(count < 1)) {
		err = -EINVAL;
		goto exit;
	}

	if (count > 1) {
		/* If the allocation failed, give up */
		if (!callchain_cpus_entries)
			err = -ENOMEM;

		goto exit;
	}

	err = alloc_callchain_buffers();
exit:
	if (err)
		atomic_dec(&nr_callchain_events);

	mutex_unlock(&callchain_mutex);


The callchain_cpus_entries is allocated in alloc_callchain_buffers()
only when the count is 1.  But if it failed to allocate, it decrease
the count so next event would try to allocate it again.  Thus it seems
not possible to see the callchain_cpus_entries being NULL in the
'if (count > 1)' block.  If you want to make next event give up, it'd
need to take an additional count IMHO.

Thanks,
Namhyung