Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3664982pxv; Mon, 26 Jul 2021 09:00:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyXKK13XYtDps3QR+jrqOWHmQ4id+w7oz2gX7dj2qRawtsoi7DWrJXJH/pzeHyDBy2pyXWu X-Received: by 2002:a05:6638:3796:: with SMTP id w22mr16961891jal.34.1627315239612; Mon, 26 Jul 2021 09:00:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627315239; cv=none; d=google.com; s=arc-20160816; b=Tl3ywfMhxevqleM08DIXbii2tUbPZJ8DJSPik+HrHTaswe5g9BWAPqX3aa1OUqW7b1 nkwum6yCMx9Os4h0XCFpefW681LtfRA+UBY7HewKFzAvC/DoGIIwybH7NzoqConKmZ7i xCymeZT6kn4Tq83OjZsvP6fILuOTonV2vv3Y+V5FEn4CB7o0msZGHH9umLeb/BT8nnnB 7jkdJqiS81Ej8dSvC1l+Buvr16/hpcgFYdks1EpZPjqbs6WnOsb4xAr7BNnLhgHMkPpN oKcRCPM6UQLDxu/8HRga2X/gBFz8fbqfvP67gUOTtKmbWcGmW2p8R98q2V7IhdFHGR5Q fUfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=qBGqHAPxhJLfR9wymil8KPjIOm9bYUJdr/iMiM9C4LQ=; b=cAmhXD5xQPN6ppWmoYDkZYv+lwRjHFWV3IFj3n8qfZcuVWF50C3Uo4w9wdwHcxX1qT cAp25AVtzx2LtNbLpjx94MhzIXO2SVmz9eleUeElhqVvJl/dvQUuEKwL1WkypIqxheL4 h08TDIofGLOWQFEH78p+uSTEGTsddsUeU6ZeDaecKlvB7pAebW4VkWZo/HTyn7qGHAvn iybmQK8aWdIR5EpRighoXT6Xayyb+YbQoBu9Odc6cik6s+7DHsbXzGTccs4aXUzT2A6L Y1IBNjRb5vvbBGfQ9pG4cMxnNxJdeHEUtWlIlZcCmpc3a5wEqJfHPLxS2uo8mfHqrQw/ Bpjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=q8CEfIYX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w9si286864jad.35.2021.07.26.09.00.27; Mon, 26 Jul 2021 09:00:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=q8CEfIYX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236175AbhGZPTU (ORCPT + 99 others); Mon, 26 Jul 2021 11:19:20 -0400 Received: from mail.kernel.org ([198.145.29.99]:49276 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235908AbhGZPHz (ORCPT ); Mon, 26 Jul 2021 11:07:55 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E967360F5C; Mon, 26 Jul 2021 15:48:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1627314503; bh=Uv6UO7LLEiKLZKDVxDYywyZRgpFdV+MSx7H1T5AVbS0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q8CEfIYXZWADSEAGgnT5Cjxvyb68VlC5va4iJT8yyjBbSBXQYJsdnmPaMjoTZiL5c Xb5/0ifh+Gnsa5M7Xt0pSuNef6r3WOygFe5MnWDk67kBPZURGlK+QCkyO7rXgKGsfG ByuBwyP0fAULbDJoKuNf4c4NWR0FruIPj3CvEWgM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Linus Torvalds , Haoran Luo , "Steven Rostedt (VMware)" Subject: [PATCH 4.14 72/82] tracing: Fix bug in rb_per_cpu_empty() that might cause deadloop. Date: Mon, 26 Jul 2021 17:39:12 +0200 Message-Id: <20210726153830.517903948@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210726153828.144714469@linuxfoundation.org> References: <20210726153828.144714469@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Haoran Luo commit 67f0d6d9883c13174669f88adac4f0ee656cc16a upstream. The "rb_per_cpu_empty()" misinterpret the condition (as not-empty) when "head_page" and "commit_page" of "struct ring_buffer_per_cpu" points to the same buffer page, whose "buffer_data_page" is empty and "read" field is non-zero. An error scenario could be constructed as followed (kernel perspective): 1. All pages in the buffer has been accessed by reader(s) so that all of them will have non-zero "read" field. 2. Read and clear all buffer pages so that "rb_num_of_entries()" will return 0 rendering there's no more data to read. It is also required that the "read_page", "commit_page" and "tail_page" points to the same page, while "head_page" is the next page of them. 3. Invoke "ring_buffer_lock_reserve()" with large enough "length" so that it shot pass the end of current tail buffer page. Now the "head_page", "commit_page" and "tail_page" points to the same page. 4. Discard current event with "ring_buffer_discard_commit()", so that "head_page", "commit_page" and "tail_page" points to a page whose buffer data page is now empty. When the error scenario has been constructed, "tracing_read_pipe" will be trapped inside a deadloop: "trace_empty()" returns 0 since "rb_per_cpu_empty()" returns 0 when it hits the CPU containing such constructed ring buffer. Then "trace_find_next_entry_inc()" always return NULL since "rb_num_of_entries()" reports there's no more entry to read. Finally "trace_seq_to_user()" returns "-EBUSY" spanking "tracing_read_pipe" back to the start of the "waitagain" loop. I've also written a proof-of-concept script to construct the scenario and trigger the bug automatically, you can use it to trace and validate my reasoning above: https://github.com/aegistudio/RingBufferDetonator.git Tests has been carried out on linux kernel 5.14-rc2 (2734d6c1b1a089fb593ef6a23d4b70903526fe0c), my fixed version of kernel (for testing whether my update fixes the bug) and some older kernels (for range of affected kernels). Test result is also attached to the proof-of-concept repository. Link: https://lore.kernel.org/linux-trace-devel/YPaNxsIlb2yjSi5Y@aegistudio/ Link: https://lore.kernel.org/linux-trace-devel/YPgrN85WL9VyrZ55@aegistudio Cc: stable@vger.kernel.org Fixes: bf41a158cacba ("ring-buffer: make reentrant") Suggested-by: Linus Torvalds Signed-off-by: Haoran Luo Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman --- kernel/trace/ring_buffer.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -3054,10 +3054,30 @@ static bool rb_per_cpu_empty(struct ring if (unlikely(!head)) return true; - return reader->read == rb_page_commit(reader) && - (commit == reader || - (commit == head && - head->read == rb_page_commit(commit))); + /* Reader should exhaust content in reader page */ + if (reader->read != rb_page_commit(reader)) + return false; + + /* + * If writers are committing on the reader page, knowing all + * committed content has been read, the ring buffer is empty. + */ + if (commit == reader) + return true; + + /* + * If writers are committing on a page other than reader page + * and head page, there should always be content to read. + */ + if (commit != head) + return false; + + /* + * Writers are committing on the head page, we just need + * to care about there're committed data, and the reader will + * swap reader page with head page when it is to read data. + */ + return rb_page_commit(commit) == 0; } /**