From patchwork Sat Jun 26 03:21:55 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yun Zhou X-Patchwork-Id: 12346103 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83A1EC2B9F4 for ; Sat, 26 Jun 2021 03:33:00 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id AC9EA61949 for ; Sat, 26 Jun 2021 03:32:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC9EA61949 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=windriver.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-21325-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 20172 invoked by uid 550); 26 Jun 2021 03:32:51 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 20134 invoked from network); 26 Jun 2021 03:32:50 -0000 From: Yun Zhou To: CC: , , , Subject: [PATCH 1/2] seq_buf: fix overflow in seq_buf_putmem_hex() Date: Sat, 26 Jun 2021 11:21:55 +0800 Message-ID: <20210626032156.47889-1-yun.zhou@windriver.com> X-Mailer: git-send-email 2.26.1 MIME-Version: 1.0 There's two variables being increased in that loop (i and j), and i follows the raw data, and j follows what is being written into the buffer. We should compare 'i' to MAX_MEMHEX_BYTES or compare 'j' to HEX_CHARS. Otherwise, if 'j' goes bigger than HEX_CHARS, it will overflow the destination buffer. This bug exists in the original code (commit 5e3ca0ec76fce 'ftrace: introduce the "hex" output method'). Although its original design did not support more than 8 bytes, the only check on length seems to have mistaken the comparison object, 'len' should compare to 'HEX_CHARS/2'. BUG_ON(len >= HEX_CHARS); Signed-off-by: Yun Zhou --- lib/seq_buf.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/seq_buf.c b/lib/seq_buf.c index 6aabb609dd87..223fbc3bb958 100644 --- a/lib/seq_buf.c +++ b/lib/seq_buf.c @@ -228,8 +228,10 @@ int seq_buf_putmem_hex(struct seq_buf *s, const void *mem, WARN_ON(s->size == 0); + BUILD_BUG_ON(MAX_MEMHEX_BYTES * 2 >= HEX_CHARS); + while (len) { - start_len = min(len, HEX_CHARS - 1); + start_len = min(len, MAX_MEMHEX_BYTES); #ifdef __BIG_ENDIAN for (i = 0, j = 0; i < start_len; i++) { #else From patchwork Sat Jun 26 03:21:56 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yun Zhou X-Patchwork-Id: 12346105 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F019C2B9F4 for ; Sat, 26 Jun 2021 03:33:07 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id B221661949 for ; Sat, 26 Jun 2021 03:33:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B221661949 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=windriver.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-21326-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 20426 invoked by uid 550); 26 Jun 2021 03:32:53 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 20265 invoked from network); 26 Jun 2021 03:32:52 -0000 From: Yun Zhou To: CC: , , , Subject: [PATCH 2/2] seq_buf: Make trace_seq_putmem_hex() support data longer than 8 Date: Sat, 26 Jun 2021 11:21:56 +0800 Message-ID: <20210626032156.47889-2-yun.zhou@windriver.com> X-Mailer: git-send-email 2.26.1 In-Reply-To: <20210626032156.47889-1-yun.zhou@windriver.com> References: <20210626032156.47889-1-yun.zhou@windriver.com> MIME-Version: 1.0 Since the raw memory 'data' does not go forward, it will dump repeated data if the data length is more than 8. If we want to dump longer data blocks, we need to repeatedly call macro SEQ_PUT_HEX_FIELD. I think it is a bit redundant, and multiple function calls also affect the performance. This patch is to improve the commit 6d2289f3faa7 ("tracing: Make trace_seq_putmem_hex() more robust"). Signed-off-by: Yun Zhou --- lib/seq_buf.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/seq_buf.c b/lib/seq_buf.c index 223fbc3bb958..562e53c93b7b 100644 --- a/lib/seq_buf.c +++ b/lib/seq_buf.c @@ -244,12 +244,14 @@ int seq_buf_putmem_hex(struct seq_buf *s, const void *mem, break; /* j increments twice per loop */ - len -= j / 2; hex[j++] = ' '; seq_buf_putmem(s, hex, j); if (seq_buf_has_overflowed(s)) return -1; + + len -= start_len; + data += start_len; } return 0; }