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.3 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 8B102C4727D for ; Sat, 26 Sep 2020 01:55:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1945D2054F for ; Sat, 26 Sep 2020 01:55:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="x2meIfRH"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="mgVGX0ls" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729836AbgIZBz2 (ORCPT ); Fri, 25 Sep 2020 21:55:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729008AbgIZBz2 (ORCPT ); Fri, 25 Sep 2020 21:55:28 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A90FC0613CE for ; Fri, 25 Sep 2020 18:55:28 -0700 (PDT) From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1601085326; 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=ebjds/y6Ik+WNL7AzXFOt7nkRoMOnpMzIAggoQnKroA=; b=x2meIfRHNDw+/kckISTk7U/A8YOX0VzzDVpWpTl3gUO8lkg3Azm/wBPL1G1q5XJVu+Pwpa 3D5YsGWQOrCmSsvGrLBNveYg/oIfxAjm2WRaw1yzKnhXAo+XyiQVOt7gvFMv2y2Mi/BT4S 7Pq39BDBzeXQChgnR4gX3cpoMjVM9qEs5r8mfD3ZFl8QdGt1Ws3wRoU+7EJn/MlG+LcddV OBCurhw2HoXxzhmHVfdiMPvyJE53CxEYjIuWseqMmGoY6h48Sw55gUNmW1T2v7/iiSSJQz 5YW0drg7bNwBQMJxvQOsIo6cyd45P3Iq39Qmh0OH+yV8RoIuHPRKz5SuW4E0BA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1601085326; 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=ebjds/y6Ik+WNL7AzXFOt7nkRoMOnpMzIAggoQnKroA=; b=mgVGX0lsSO7osOM1MIKxUKCX3IQACLSQqLfrkPI41clKQ3taH4ifjpYm/Po+RAScw3EUfN 45qOUVd7QmDWJ0DQ== 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 0/2] printk: fix reading beyond buffer Date: Sat, 26 Sep 2020 04:01:24 +0206 Message-Id: <20200926015526.8921-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 | 9 +++++++-- kernel/printk/printk_ringbuffer.c | 12 ++++++++++-- kernel/printk/printk_ringbuffer.h | 2 +- 3 files changed, 18 insertions(+), 5 deletions(-) -- 2.20.1