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=-3.5 required=3.0 tests=BAYES_00, BUG6152_INVALID_DATE_TZ_ABSURD,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS,INVALID_DATE_TZ_ABSURD,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 9DD46C4727F for ; Wed, 30 Sep 2020 09:01:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3AA49207F7 for ; Wed, 30 Sep 2020 09:01:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="nmnjyMrR"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="+p4InHoV" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728725AbgI3JBh (ORCPT ); Wed, 30 Sep 2020 05:01:37 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:54938 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725836AbgI3JBh (ORCPT ); Wed, 30 Sep 2020 05:01:37 -0400 From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1601456495; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=tlqOr9t8cKfu5RTznS8M2rCZNaJHuFCY6fFem8EcYU4=; b=nmnjyMrR6VUF65lUCLTNmG21JkKmR2N79F0LPhV2YtQdb7x2bpCzLCcEKA8HzaZhATiAWo paVHA5pnRE29kb9yWueKUvjL2IAfF5nx+EgAlKF+wCdGiLU6nHm0FO0AqB9xb7LrwU4xd6 KbiNaJuZMHkcsIoHHCUnealJkXHJTuPlyWVrZtXnxOufAlvUFH0Fzi4W0MXsLTpJHXEV+a n8pZtLy0FdksF1eFAverarOFxiQBeiAlY9QK/gv/o40ovmSr8g3rj1HgYe86rhiZNkWGzR o8xkdPKhC/eazNPCK+ARxMTvoRMHpe3G+0BMTeIkTGSYebuDiU3/PgerD7P91w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1601456495; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=tlqOr9t8cKfu5RTznS8M2rCZNaJHuFCY6fFem8EcYU4=; b=+p4InHoV9G4n3eNwKbHsl0uDqfvocBAfD/g5fJjeDmydyYwmZSnAF+TiErDeUUV+9e0NdC SiGXL/aY1CG1vLCw== To: Petr Mladek Cc: Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , Linus Torvalds , Greg Kroah-Hartman , Thomas Gleixner , Marek Szyprowski , linux-kernel@vger.kernel.org Subject: [PATCH next v2 0/2] printk: fix reading beyond buffer Date: Wed, 30 Sep 2020 11:07:32 +0206 Message-Id: <20200930090134.8723-1-john.ogness@linutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Marek Szyprowski reported [0] a problem with a particular printk usage. This particular usage performs thousands of LOG_CONT calls. The printk.c implementation was only limiting the growing record by the maximum size available in the ringbuffer, thus creating a record that was several kilobytes in size. This in and of itself is not a problem. However, the various readers used buffers that were about 1KB in size. The ringbuffer would only fill the reader's 1KB buffer, but the meta data stated that the message was actually much larger. The reader code was not checking this and assumed its buffer contained the full message. I have solved this problem by adding the necessary check to the functions where the situation can occur and also adding an argument when extending records so that a maximum size is specified. This will prevent the records from growing beyond the size that we know our readers are using. I did not add the check where it is certain that the reader's buffer is large enough to contain the largest possible message. The 2nd patch in this series reduces the size of the initial setup buffer. I noticed it was too big while verifying all the sizes for this series. John Ogness [0] https://lkml.kernel.org/r/f1651593-3579-5820-6863-5f4973d2bfdc@samsung.com John Ogness (2): printk: avoid and/or handle record truncation printk: reduce setup_text_buf size to LOG_LINE_MAX kernel/printk/printk.c | 11 +++++++++-- kernel/printk/printk_ringbuffer.c | 12 ++++++++++-- kernel/printk/printk_ringbuffer.h | 2 +- 3 files changed, 20 insertions(+), 5 deletions(-) -- 2.20.1