From mboxrd@z Thu Jan 1 00:00:00 1970 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=-11.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 A8CFDC4727C for ; Tue, 29 Sep 2020 11:51:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5B8E92065C for ; Tue, 29 Sep 2020 11:51:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="RWzdT8Ho" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730639AbgI2LvO (ORCPT ); Tue, 29 Sep 2020 07:51:14 -0400 Received: from mx2.suse.de ([195.135.220.15]:39912 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730256AbgI2LvK (ORCPT ); Tue, 29 Sep 2020 07:51:10 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1601380268; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kqP+VKUP21zbmiPlzTiabxKdYjDjr6MWefWBXor11nI=; b=RWzdT8HozkPtvNJIlHGAXaiiHv9RQOYyI2BSxbDTTODQn+7Bn/STSdQTiDrHOxUV488Iwa pD/M93H81moz7S098/N8BeYKhHAayxocOVNWuCItftyESbmgBGoJnCtUoEEN5zb7K98K+2 taXW2fweQO8UWjGsTSq2kMl3xvqo2xo= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 4E921ACB8; Tue, 29 Sep 2020 11:51:08 +0000 (UTC) Date: Tue, 29 Sep 2020 13:51:07 +0200 From: Petr Mladek To: John Ogness Cc: Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , Linus Torvalds , Greg Kroah-Hartman , Thomas Gleixner , Marek Szyprowski , linux-kernel@vger.kernel.org Subject: Re: [PATCH next 1/2] printk: avoid and/or handle record truncation Message-ID: <20200929115107.GO6442@alley> References: <20200926015526.8921-1-john.ogness@linutronix.de> <20200926015526.8921-2-john.ogness@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200926015526.8921-2-john.ogness@linutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat 2020-09-26 04:01:25, John Ogness wrote: > If a reader provides a buffer that is smaller than the message text, > the @text_len field of @info will have a value larger than the buffer > size. If readers blindly read @text_len bytes of data without > checking the size, they will read beyond their buffer. Great catch! > Add this check to record_print_text() to properly recognize when such > truncation needs to occur. > > Add a maximum size argument to the ringbuffer function to extend > records so that records can not be created that are larger than the > buffer size of readers. > > When extending records (LOG_CONT), do not extend records beyond > LOG_LINE_MAX since that is the maximum size available in the buffers > used by consoles and syslog. > > Fixes: f5f022e53b87 ("printk: reimplement log_cont using record extension") > Signed-off-by: John Ogness > Reported-by: Marek Szyprowski > --- > kernel/printk/printk.c | 7 ++++++- > kernel/printk/printk_ringbuffer.c | 12 ++++++++++-- > kernel/printk/printk_ringbuffer.h | 2 +- > 3 files changed, 17 insertions(+), 4 deletions(-) > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index 78f68b4830dc..270f19b60e6f 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -1357,6 +1357,11 @@ static size_t record_print_text(struct printk_record *r, bool syslog, > size_t len = 0; > char *next; > > + if (text_len > buf_size) { > + text_len = buf_size; > + truncated = true; @truncate must not be set here. Otherwise, the prefix would not be added when there no '\n' in the entire string. It would call: /* Drop truncated line(s). */ if (truncated) break; before copying the prefix. It is enough to remove the line. It will be set in the very first cycle anyway. We need to add one prefix at all. It would require to truncate even more bytes. Otherwise, the patch looks good to me. Best Regards, Petr