From patchwork Thu Feb 22 01:18:16 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Rostedt X-Patchwork-Id: 204515 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp1398244dyc; Wed, 21 Feb 2024 17:16:42 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWXY9fR/28dU8U6O3xKqS+Jrz7HrPFNd7KoLJCVYl4pblvzyCr5LzRn+9n9CigiafZwiFXKb3if7pMfB6+uZFO/RWfHOg== X-Google-Smtp-Source: AGHT+IGvS4VmmCAhZdFGJBoEQOJVWiIZpH6sD81E7HdSdGz92K/3iq6Z47Ok52kmndHqbV0n6SVZ X-Received: by 2002:a05:6871:713:b0:21a:1b9d:6ca1 with SMTP id f19-20020a056871071300b0021a1b9d6ca1mr21622259oap.40.1708564601995; Wed, 21 Feb 2024 17:16:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708564601; cv=pass; d=google.com; s=arc-20160816; b=SoEsd71NP9KsjDCB6NroDzTnOc4VwrWpKNoSKfdq6P6ZUSVDfCTbF8OhG0YEleTVjM Z20toXbiYFIo/+f5nJ/+Wbd0FhT+RcMhGUnhnE04K8SgfuRXyehwyUw/KKie2uIwOfXq 7NkddFcTj9MZmqXUoDjfdqk5mFxwsMY8ycYQ2GTFgS3cn+z7AhSWwIvMVUQr8ZkPxGTq ve3c3hImE6ntjXgHcwAIaTBb5hS4WQ7/h2tYQeyy7W/YYsKI+QUz50ynKRVBhbw8H0mu mctu5lnPRQgx7tAV2Hlg5zf8NSDyHkAr1Lwf5XHscUyRGl+cl5Dh5lUofpcSea4NDOTR LhPw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:subject:cc:to:from :date; bh=HzFijEKRNxMofhfW80OJhwoyuU3bylY3SYI2eH3/Zhc=; fh=BJjscmstiuwSmMpx+EuWwz/EH9XNPUTFyivEKBLydzI=; b=T7DCyfx4L5AVADXLLOE/bIa62k9xbjVjbUo4ZOPrc1ZEXKmbrKRJL0MORD669d9Px9 qE30HJM0JRmCd4TvLezoLVuC6DMgWLQbs8wTnT9y5kjJHAUocX7DwihQMrgD8kjZU6Gi cMDN/u4gn1g43Bh9AlKOlFyIomxmJHoM5HYnWnNJkigt1EkummU41yDTs/o3cqVZWNpp pr6itEqmDHO5RXzDT7SaldnOVV5OS+k9eTuzgxd+vKoquLS0tyZgYeTFWzs5ZAvmA0HI vYrFGx7is89da6xVt//An19EUxL88GvDnt5QgqEFCG3cQVppWkYYpfDK1CttHL8PARK/ iyUw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-75760-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-75760-ouuuleilei=gmail.com@vger.kernel.org" Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id s9-20020a6550c9000000b005cee03a1bf9si9166277pgp.448.2024.02.21.17.16.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 17:16:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-75760-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-75760-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-75760-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id C349B28239A for ; Thu, 22 Feb 2024 01:16:41 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5E01F12E42; Thu, 22 Feb 2024 01:16:30 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC7B98F45 for ; Thu, 22 Feb 2024 01:16:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708564589; cv=none; b=jHfyNI8XoYqxRk6bRqfq95PgB4QMlYaQ42xWz2f85XNnNpKFxaJaDgS5dMShDQ2cpKCkZpU/M6x1oHSTugc99YZNzOJBKXURSCTKHXnDDs+BfBfrBtHbfkkLIrP+lbMEaFcEm7J7/BRp2bIgZF50qgG0ANWujqi2bPARYr3WRZk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708564589; c=relaxed/simple; bh=5PcQB9L/FhYvOc8Hm0xI1evh+ow1XK07hQOhd9zsYEw=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=O5BeDLJOubWdn57XbdBwc2n9B9ZjaxxYibsvS2X/WF2DYL/sr5LH6jmLhuWgbr/rxXmN5CWRWDq3a/PoA9aUKxNVyfGr2Qn0ajFebtnzXooTO+hugEhdRY/WNr9oz7sxDyi10lDYHMjZrXBarlVH4Z1BEgrAFlF7rCANPByFkgM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE06CC433F1; Thu, 22 Feb 2024 01:16:27 +0000 (UTC) Date: Wed, 21 Feb 2024 20:18:16 -0500 From: Steven Rostedt To: Linus Torvalds Cc: LKML , Masami Hiramatsu , Mathieu Desnoyers Subject: [GIT PULL] tracing: Add ring buffer sub-buffer size check Message-ID: <20240221201816.0d1e7829@gandalf.local.home> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791559836441944849 X-GMAIL-MSGID: 1791559836441944849 Linus, Tracing fix for v6.8: - While working on the ring buffer I noticed that the counter used for knowing where the end of the data is on a sub-buffer was not a full "int" but just 20 bits. It was masked out to 0xfffff. With the new code that allows the user to change the size of the sub-buffer, it is theoretically possible to ask for a size bigger than 2^20. If that happens, unexpected results may occur as there's no code checking if the counter overflowed the 20 bits of the write mask. There are other checks to make sure events fit in the sub-buffer, but if the sub-buffer itself is too big, that is not checked. Add a check in the resize of the sub-buffer to make sure that it never goes beyond the size of the counter that holds how much data is on it. Please pull the latest trace-v6.8-rc5 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git trace-v6.8-rc5 Tag SHA1: 2ff328f136698ef4a0b8660ed372017d338f9435 Head SHA1: e78fb4eac817308027da88d02e5d0213462a7562 Steven Rostedt (Google) (1): ring-buffer: Do not let subbuf be bigger than write mask ---- kernel/trace/ring_buffer.c | 4 ++++ 1 file changed, 4 insertions(+) --------------------------- commit e78fb4eac817308027da88d02e5d0213462a7562 Author: Steven Rostedt (Google) Date: Tue Feb 20 09:51:12 2024 -0500 ring-buffer: Do not let subbuf be bigger than write mask The data on the subbuffer is measured by a write variable that also contains status flags. The counter is just 20 bits in length. If the subbuffer is bigger than then counter, it will fail. Make sure that the subbuffer can not be set to greater than the counter that keeps track of the data on the subbuffer. Link: https://lore.kernel.org/linux-trace-kernel/20240220095112.77e9cb81@gandalf.local.home Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Fixes: 2808e31ec12e5 ("ring-buffer: Add interface for configuring trace sub buffer size") Signed-off-by: Steven Rostedt (Google) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index fd4bfe3ecf01..0699027b4f4c 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -5877,6 +5877,10 @@ int ring_buffer_subbuf_order_set(struct trace_buffer *buffer, int order) if (psize <= BUF_PAGE_HDR_SIZE) return -EINVAL; + /* Size of a subbuf cannot be greater than the write counter */ + if (psize > RB_WRITE_MASK + 1) + return -EINVAL; + old_order = buffer->subbuf_order; old_size = buffer->subbuf_size;