linux-kernel - [tip:perf/core] perf/core: Don't WARN() for impossible ring-buffer sizes

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: <tip-9dff0aa95a324e262ffb03f425d00e4751f3294e@git.kernel.org>
Date:   Mon, 4 Feb 2019 00:49:21 -0800
From:   tip-bot for Mark Rutland <tipbot@...or.com>
To:     linux-tip-commits@...r.kernel.org
Cc:     acme@...hat.com, peterz@...radead.org, namhyung@...nel.org,
        tglx@...utronix.de, jolsa@...hat.com, hpa@...or.com,
        mark.rutland@....com, mingo@...nel.org,
        alexander.shishkin@...ux.intel.com, julien.thierry@....com,
        stable@...r.kernel.org, linux-kernel@...r.kernel.org,
        torvalds@...ux-foundation.org
Subject: [tip:perf/core] perf/core: Don't WARN() for impossible ring-buffer
 sizes

Commit-ID:  9dff0aa95a324e262ffb03f425d00e4751f3294e
Gitweb:     https://git.kernel.org/tip/9dff0aa95a324e262ffb03f425d00e4751f3294e
Author:     Mark Rutland <mark.rutland@....com>
AuthorDate: Thu, 10 Jan 2019 14:27:45 +0000
Committer:  Ingo Molnar <mingo@...nel.org>
CommitDate: Mon, 4 Feb 2019 08:45:25 +0100

perf/core: Don't WARN() for impossible ring-buffer sizes

The perf tool uses /proc/sys/kernel/perf_event_mlock_kb to determine how
large its ringbuffer mmap should be. This can be configured to arbitrary
values, which can be larger than the maximum possible allocation from
kmalloc.

When this is configured to a suitably large value (e.g. thanks to the
perf fuzzer), attempting to use perf record triggers a WARN_ON_ONCE() in
__alloc_pages_nodemask():

   WARNING: CPU: 2 PID: 5666 at mm/page_alloc.c:4511 __alloc_pages_nodemask+0x3f8/0xbc8

Let's avoid this by checking that the requested allocation is possible
before calling kzalloc.

Reported-by: Julien Thierry <julien.thierry@....com>
Signed-off-by: Mark Rutland <mark.rutland@....com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Reviewed-by: Julien Thierry <julien.thierry@....com>
Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
Cc: Jiri Olsa <jolsa@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Namhyung Kim <namhyung@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: <stable@...r.kernel.org>
Link: https://lkml.kernel.org/r/20190110142745.25495-1-mark.rutland@arm.com
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 kernel/events/ring_buffer.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index 4a9937076331..309ef5a64af5 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -734,6 +734,9 @@ struct ring_buffer *rb_alloc(int nr_pages, long watermark, int cpu, int flags)
 	size = sizeof(struct ring_buffer);
 	size += nr_pages * sizeof(void *);
 
+	if (order_base_2(size) >= MAX_ORDER)
+		goto fail;
+
 	rb = kzalloc(size, GFP_KERNEL);
 	if (!rb)
 		goto fail;