From: Denis Efremov <efremov@linux.com>
To: Gaurav Kohli <gkohli@codeaurora.org>, rostedt@goodmis.org
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v1] trace: Fix race in trace_open and buffer resize call
Date: Thu, 21 Jan 2021 17:30:40 +0300 [thread overview]
Message-ID: <f06efd7b-c7b5-85c9-1a0e-6bb865111ede@linux.com> (raw)
In-Reply-To: <1601976833-24377-1-git-send-email-gkohli@codeaurora.org>
Hi,
This patch (CVE-2020-27825) was tagged with
Fixes: b23d7a5f4a07a ("ring-buffer: speed up buffer resets by avoiding synchronize_rcu for each CPU")
I'm not an expert here but it seems like b23d7a5f4a07a only refactored
ring_buffer_reset_cpu() by introducing reset_disabled_cpu_buffer() without
significant changes. Hence, mutex_lock(&buffer->mutex)/mutex_unlock(&buffer->mutex)
can be backported further than b23d7a5f4a07a~ and to all LTS kernels. Is
b23d7a5f4a07a the actual cause of the bug?
Thanks,
Denis
On 10/6/20 12:33 PM, Gaurav Kohli wrote:
> Below race can come, if trace_open and resize of
> cpu buffer is running parallely on different cpus
> CPUX CPUY
> ring_buffer_resize
> atomic_read(&buffer->resize_disabled)
> tracing_open
> tracing_reset_online_cpus
> ring_buffer_reset_cpu
> rb_reset_cpu
> rb_update_pages
> remove/insert pages
> resetting pointer
>
> This race can cause data abort or some times infinte loop in
> rb_remove_pages and rb_insert_pages while checking pages
> for sanity.
>
> Take buffer lock to fix this.
>
> Signed-off-by: Gaurav Kohli <gkohli@codeaurora.org>
> Cc: stable@vger.kernel.org
> ---
> Changes since v0:
> -Addressed Steven's review comments.
>
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 93ef0ab..15bf28b 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -4866,6 +4866,9 @@ void ring_buffer_reset_cpu(struct trace_buffer *buffer, int cpu)
> if (!cpumask_test_cpu(cpu, buffer->cpumask))
> return;
>
> + /* prevent another thread from changing buffer sizes */
> + mutex_lock(&buffer->mutex);
> +
> atomic_inc(&cpu_buffer->resize_disabled);
> atomic_inc(&cpu_buffer->record_disabled);
>
> @@ -4876,6 +4879,8 @@ void ring_buffer_reset_cpu(struct trace_buffer *buffer, int cpu)
>
> atomic_dec(&cpu_buffer->record_disabled);
> atomic_dec(&cpu_buffer->resize_disabled);
> +
> + mutex_unlock(&buffer->mutex);
> }
> EXPORT_SYMBOL_GPL(ring_buffer_reset_cpu);
>
> @@ -4889,6 +4894,9 @@ void ring_buffer_reset_online_cpus(struct trace_buffer *buffer)
> struct ring_buffer_per_cpu *cpu_buffer;
> int cpu;
>
> + /* prevent another thread from changing buffer sizes */
> + mutex_lock(&buffer->mutex);
> +
> for_each_online_buffer_cpu(buffer, cpu) {
> cpu_buffer = buffer->buffers[cpu];
>
> @@ -4907,6 +4915,8 @@ void ring_buffer_reset_online_cpus(struct trace_buffer *buffer)
> atomic_dec(&cpu_buffer->record_disabled);
> atomic_dec(&cpu_buffer->resize_disabled);
> }
> +
> + mutex_unlock(&buffer->mutex);
> }
>
> /**
>
next prev parent reply other threads:[~2021-01-21 14:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 9:33 [PATCH v1] trace: Fix race in trace_open and buffer resize call Gaurav Kohli
2021-01-21 14:30 ` Denis Efremov [this message]
2021-01-21 19:09 ` Steven Rostedt
2021-01-21 20:15 ` Denis Efremov
2021-01-21 20:37 ` Steven Rostedt
2021-01-22 10:59 ` Greg KH
2021-01-22 11:25 ` Gaurav Kohli
2021-01-22 14:37 ` Steven Rostedt
2021-01-23 10:49 ` Denis Efremov
2021-01-23 16:33 ` Gaurav Kohli
2021-01-24 3:21 ` Steven Rostedt
2021-01-24 9:57 ` Gaurav Kohli
2021-01-24 10:05 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2020-09-24 13:55 Gaurav Kohli
2020-10-05 4:39 ` Gaurav Kohli
2020-10-05 14:25 ` Steven Rostedt
2020-10-05 14:27 ` Steven Rostedt
2020-10-05 16:29 ` Gaurav Kohli
2020-10-05 16:32 ` Steven Rostedt
2020-10-05 17:38 ` Gaurav Kohli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f06efd7b-c7b5-85c9-1a0e-6bb865111ede@linux.com \
--to=efremov@linux.com \
--cc=gkohli@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.