Received: by 2002:a05:7412:798b:b0:fc:a2b0:25d7 with SMTP id fb11csp59676rdb; Wed, 21 Feb 2024 17:16:35 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXnnQ+tObLzmxBzCWF+x8z6GockCIQmH9RvOuNXEkIwKdULldy32WykGC0RlEnoFJJ4j2lu9F6LfPP5rNARYKo5k2aOf7vpeJGvHldacA== X-Google-Smtp-Source: AGHT+IFFWXgYWSLr5EavC5GHCRh5vRFbFSju04j/9xBnJk5Tp/QpsFG0TtRRDzenVZd3f/tzfO43 X-Received: by 2002:a17:90b:805:b0:299:765e:1756 with SMTP id bk5-20020a17090b080500b00299765e1756mr10105132pjb.30.1708564594962; Wed, 21 Feb 2024 17:16:34 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708564594; cv=pass; d=google.com; s=arc-20160816; b=e9yY0Zi7D/cwp5R48Damnp3Yb7LLa1EUipZg7g/BJmSg2BUIYJzyqFjh+i7JYHZAoo MVEJ76Wk4lx3mU683VP3USBPVe0p5mPoPjzYL5c+PyCX8WhGK4LVIJr6aIcRCp+/jzmv CYCPM3DxaVftmyex/pb87OUuRIa5VHlbt4Upi7Eq8H7XFux8Hf8D0Tp1qmForbUoAK0U FidGARI2ETkTfT098QahTtGWFm9MR6kf0K+xsoT03nS0RXQAVRrGVeDrfy0YpBOzMcTw 1T8BsSBWQOVZMjeeXr7YIyjO+Q/FqHeoy8rg+gG2xEJqDqorsU7lZC5E8Vd/OKKa46Iw XamA== 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-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-75760-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id x6-20020a17090a1f8600b00299303a935fsi2469014pja.42.2024.02.21.17.16.34 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 17:16:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-75760-linux.lists.archive=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-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-75760-linux.lists.archive=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 A6C322828D7 for ; Thu, 22 Feb 2024 01:16:34 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6C12711C92; Thu, 22 Feb 2024 01:16:29 +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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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;