[v3] tracing: Fix infinite loop in tracing_read_pipe on overflowed print_trace_line
Message ID | 20221124125850.155449-1-yangjihong1@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp3383471wrr; Thu, 24 Nov 2022 05:04:40 -0800 (PST) X-Google-Smtp-Source: AA0mqf6kszCQYVNoPj5RjsjZJ0ZTEZtQD75NxmjWp86v0jFuPgzNeLTLJwdzvY94GeV/zid/0+Z5 X-Received: by 2002:a17:906:a209:b0:78e:ebf:2722 with SMTP id r9-20020a170906a20900b0078e0ebf2722mr26646052ejy.490.1669295080591; Thu, 24 Nov 2022 05:04:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669295080; cv=none; d=google.com; s=arc-20160816; b=F/tWlT1dm56yKWehSQTLFEmOMOPuc4kinOONjs8+FHk33k1I2roo66FzsmXeD9y7DD SevVqlbuKRjq0EQ7dAxtIcampfHzDcUG2x59auSsR5qrkNhHE/UYb6XvknR+d9SsgiDU fROUnV7QTjgVLUcC/fvAPxT+HPNiXX1o4QVCXeiOKwFW56N5vQgS2UlqiA+fNIX5ZtuD gZuuqOwOqnOwIMvt5R/IVPaK9RPrj+1rHXyZjoD1cvVExmt/zZtjNbzxwmo4u+jGmuu1 kKcn3ZJ8YzYgk/4Dsy9n7RGwptGvf61hQBiw3+K8pxy7xUz9Z+KM1p+no13SeP4Ra+Pd 9iRA== 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 :message-id:date:subject:cc:to:from; bh=0D1TPiCxTaSv3SU6QGs6g+5Uqo+KZY/keb0FKQzy3Cs=; b=0vkIM5ml3qsNcXV0XLlYK5IarfBkGmItx/6TsO3E/9voZkn4SuQ/S6FhDRzaf/W/71 bYqVqlsezjWOub848Yw0Ej3u4Muxc1o7wXyuwDphh7YVE4Xv9fJFWryvpPb+tAjzER9J TAt/FSNEqQLvg6znoTxTWSAe+xJwa8swZKOcJIe+fSrqSAUx8Dv45zNVBrs8eYskNuan acWnE7R0+3GOa/P4K2SULfovzt+xfe5KCGBWmD9vUqCoV76QQwR5HsnDvjbdcV0SCMrf aerUD0Mv3ziVRMHOdaRXJ00SdLpAaVMWCtI1P/xvqkXZXu5lntN7yd82xsp4LIUX3Dx5 P1LA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f19-20020a50a6d3000000b0046a223ca073si1031345edc.182.2022.11.24.05.04.13; Thu, 24 Nov 2022 05:04:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230034AbiKXNCZ (ORCPT <rfc822;fengqi706@gmail.com> + 99 others); Thu, 24 Nov 2022 08:02:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52014 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230218AbiKXNCB (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 24 Nov 2022 08:02:01 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 794058754A for <linux-kernel@vger.kernel.org>; Thu, 24 Nov 2022 05:02:00 -0800 (PST) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NHymc5ScCzHw3R; Thu, 24 Nov 2022 21:01:20 +0800 (CST) Received: from kwepemm600003.china.huawei.com (7.193.23.202) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 24 Nov 2022 21:01:52 +0800 Received: from ubuntu1804.huawei.com (10.67.174.61) by kwepemm600003.china.huawei.com (7.193.23.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 24 Nov 2022 21:01:52 +0800 From: Yang Jihong <yangjihong1@huawei.com> To: <rostedt@goodmis.org>, <mhiramat@kernel.org>, <linux-kernel@vger.kernel.org> CC: <yangjihong1@huawei.com> Subject: [PATCH v3] tracing: Fix infinite loop in tracing_read_pipe on overflowed print_trace_line Date: Thu, 24 Nov 2022 20:58:50 +0800 Message-ID: <20221124125850.155449-1-yangjihong1@huawei.com> X-Mailer: git-send-email 2.30.GIT MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.67.174.61] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemm600003.china.huawei.com (7.193.23.202) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750382758611688340?= X-GMAIL-MSGID: =?utf-8?q?1750382758611688340?= |
Series |
[v3] tracing: Fix infinite loop in tracing_read_pipe on overflowed print_trace_line
|
|
Commit Message
Yang Jihong
Nov. 24, 2022, 12:58 p.m. UTC
print_trace_line may overflow seq_file buffer. If the event is not
consumed, the while loop keeps peeking this event, causing a infinite loop.
Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
---
kernel/trace/trace.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
Comments
On Thu, 24 Nov 2022 20:58:50 +0800 Yang Jihong <yangjihong1@huawei.com> wrote: > print_trace_line may overflow seq_file buffer. If the event is not > consumed, the while loop keeps peeking this event, causing a infinite loop. > > Signed-off-by: Yang Jihong <yangjihong1@huawei.com> > --- > kernel/trace/trace.c | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index a7fe0e115272..55733224fa88 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -6787,7 +6787,27 @@ tracing_read_pipe(struct file *filp, char __user *ubuf, > > ret = print_trace_line(iter); > if (ret == TRACE_TYPE_PARTIAL_LINE) { > - /* don't print partial lines */ > + /* > + * If one trace_line of the tracer overflows seq_file > + * buffer, trace_seq_to_user returns -EBUSY. > + * In this case, we need to consume it, otherwise, > + * while loop will peek this event next time, > + * resulting in an infinite loop. > + */ > + if (trace_seq_has_overflowed(&iter->seq)) { The only way to get here is if the above is true, and that is not going to cause the infinite loop. What does is if save_len == 0. In fact, that's all you need to check for: if (save_len == 0) { Should do the trick. -- Steve > + /* > + * Here we only consider the case that one > + * print_trace_line() fills the entire trace_seq > + * in one shot, in that case, iter->seq.seq.len is zero, > + * we simply output a log of too long line to inform the user. > + */ > + iter->seq.full = 0; > + trace_seq_puts(&iter->seq, "[LINE TOO BIG]\n"); > + trace_consume(iter); > + break; > + } > + > + /* In other cases, don't print partial lines */ > iter->seq.seq.len = save_len; > break; > }
On 2022/11/29 0:46, Steven Rostedt wrote: > On Thu, 24 Nov 2022 20:58:50 +0800 > Yang Jihong <yangjihong1@huawei.com> wrote: > >> print_trace_line may overflow seq_file buffer. If the event is not >> consumed, the while loop keeps peeking this event, causing a infinite loop. >> >> Signed-off-by: Yang Jihong <yangjihong1@huawei.com> >> --- >> kernel/trace/trace.c | 22 +++++++++++++++++++++- >> 1 file changed, 21 insertions(+), 1 deletion(-) >> >> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c >> index a7fe0e115272..55733224fa88 100644 >> --- a/kernel/trace/trace.c >> +++ b/kernel/trace/trace.c >> @@ -6787,7 +6787,27 @@ tracing_read_pipe(struct file *filp, char __user *ubuf, >> >> ret = print_trace_line(iter); >> if (ret == TRACE_TYPE_PARTIAL_LINE) { >> - /* don't print partial lines */ >> + /* >> + * If one trace_line of the tracer overflows seq_file >> + * buffer, trace_seq_to_user returns -EBUSY. >> + * In this case, we need to consume it, otherwise, >> + * while loop will peek this event next time, >> + * resulting in an infinite loop. >> + */ >> + if (trace_seq_has_overflowed(&iter->seq)) { > > The only way to get here is if the above is true, and that is not going to > cause the infinite loop. What does is if save_len == 0. In fact, that's > all you need to check for: > > if (save_len == 0) { > > Should do the trick. Yes, Has been tested to be feasible, will change in next version. By the way, the problem mentioned in the v1 patch: "Anyway, what is triggering this?" The problem is caused by the print_line callback function (blk_tracer_print_line) of blktrace. The blktrace does not filter out the events whose type is !=TRACK_BLK. It parses and prints all trace events in the ring buffer as blktrace events. As a result, the seq_file buffer may overflow in the blk_log_dump_pdu function: static void blk_log_dump_pdu() { ... for (i = 0; i < pdu_len; i++) { // pdu_len may exceed the seq_file buffer size. trace_seq_printf(s, "%s%02x", i == 0 ? "" : " ", pdu_buf[i]); /* * stop when the rest is just zeros and indicate so * with a ".." appended */ if (i == end && end != pdu_len - 1) { trace_seq_puts(s, " ..) "); return; } } ... } The fixed patch has been sent: https://lore.kernel.org/lkml/20221122040410.85113-1-yangjihong1@huawei.com/T/ Thanks, Yang
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index a7fe0e115272..55733224fa88 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6787,7 +6787,27 @@ tracing_read_pipe(struct file *filp, char __user *ubuf, ret = print_trace_line(iter); if (ret == TRACE_TYPE_PARTIAL_LINE) { - /* don't print partial lines */ + /* + * If one trace_line of the tracer overflows seq_file + * buffer, trace_seq_to_user returns -EBUSY. + * In this case, we need to consume it, otherwise, + * while loop will peek this event next time, + * resulting in an infinite loop. + */ + if (trace_seq_has_overflowed(&iter->seq)) { + /* + * Here we only consider the case that one + * print_trace_line() fills the entire trace_seq + * in one shot, in that case, iter->seq.seq.len is zero, + * we simply output a log of too long line to inform the user. + */ + iter->seq.full = 0; + trace_seq_puts(&iter->seq, "[LINE TOO BIG]\n"); + trace_consume(iter); + break; + } + + /* In other cases, don't print partial lines */ iter->seq.seq.len = save_len; break; }