From nobody Mon Apr 6 10:37:48 2026 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5236036215D for ; Thu, 19 Mar 2026 13:49:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773928200; cv=none; b=MiI+pxUvBFCJTCqtJhz57qA2AVQp42ZMLrTw9IJ3hTVeog9NkmjT6Qqt0nNIGhG+J8RJLHsEZqTNEieJ0inMPQJ4DMI/14VNNgXHYMl/2/T3CvDgpl30c4jTGrsZvQfVYM+IwRMJLmt59fmIyg8q9H19OxIAUfylcXN3OpX2N78= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773928200; c=relaxed/simple; bh=AOAQEaPucycfIiuU6Mw+ywpMjznNhNG2tZqrQLyN/OI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=BYZCVJnu2MiIn+iUcFyMxx7eD8u1rB9Ufq4dkPmU0OtYbrUQpSU2kgbG/xYheoV+3uRFciGQfqu+pHkHtKH1Nd4ul017IxGdJ6E97UUReSNjK2iTRvyBD+aYwzrlqZ5xr9+qD1LZxlchqRCwWZhDzEuSruRqCaqXm4ID3sVulVo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=Cu+mtji8; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=6jRW5PHv; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="Cu+mtji8"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="6jRW5PHv" From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1773928196; 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=XPwBmdWCKDhe/VadyrC9lfZC2xxnlUMVmVXkeM6kYDk=; b=Cu+mtji8GbaYME24g58U27lTMNxFJrgxHG8C4LvuVE3cgSL3j42cjdu1KRvAA/gZ+8x4k3 hPFALWjVM1HC8nouZv+cP+sRBSwCiguPOGqrmEDRfyrixKGJL2eOE6Jr6owlVB8NPO9xsH PUrCgUR/QV5+Rwo6+srUXOWAGvafzVw/FK+4nvN+yZZkAQpPl+mBj14aE/u7eq1Queh5ms fQMCziTeEeZENRpI5kLV7r8pcNibr3j7E514DSks4AzZ4gwdFcQ5i/k2GyviguL81dIPQq nEWYtNrI/tQKGMv0HsH7xFSR1paCEXjMDar5pExsEVm+sSgzwP0Te+hqMKyWLg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1773928196; 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=XPwBmdWCKDhe/VadyrC9lfZC2xxnlUMVmVXkeM6kYDk=; b=6jRW5PHvM+rvB2y6s5uG24NvaeX8KEZK5RRCsoP1OF6fznSzEDaccO0S0PR3fiDYuSZA3Y WjMLH3JCJfUJvjAw== To: Petr Mladek Cc: Sergey Senozhatsky , Steven Rostedt , linux-kernel@vger.kernel.org Subject: [PATCH printk] printk_ringbuffer: Fix get_data() size sanity check Date: Thu, 19 Mar 2026 14:55:39 +0106 Message-ID: <20260319134955.185123-1-john.ogness@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit cc3bad11de6e ("printk_ringbuffer: Fix check of valid data size when blk_lpos overflows") added sanity checking to get_data() to avoid returning data of illegal sizes (too large or too small). It uses the helper function data_check_size() for the check. However, data_check_size() expects the size of the data, not the size of the data block. get_data() is providing the size of the data block. This means that if the data size (text_buf_size) is the maximum legal size: sizeof(prb_data_block) + text_buf_size =3D=3D DATA_SIZE(data_ring) / 2 data_check_size() will report failure because it adds sizeof(prb_data_block) to the provided size. The sanity check in get_data() is counting the data block header twice. The result is that the reader fails to read the legal record. Since get_data() subtracts the data block header size before returning, move the sanity check to after the subtraction. Luckily printk() is not vulnerable to this problem because truncate_msg() limits printk-messages to 1/4 of the ringbuffer. Indeed, by adjusting the printk_ringbuffer KUnit test, which does not use printk() and its truncate_msg() check, it is easy to see that the reader fails and the WARN_ON is triggered. Fixes: cc3bad11de6e ("printk_ringbuffer: Fix check of valid data size when = blk_lpos overflows") Signed-off-by: John Ogness --- kernel/printk/printk_ringbuffer.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringb= uffer.c index 56c8e3d031f49..613a6524cdd81 100644 --- a/kernel/printk/printk_ringbuffer.c +++ b/kernel/printk/printk_ringbuffer.c @@ -1302,10 +1302,6 @@ static const char *get_data(struct prb_data_ring *da= ta_ring, return NULL; } =20 - /* Sanity check. Data-less blocks were handled earlier. */ - if (WARN_ON_ONCE(!data_check_size(data_ring, *data_size) || !*data_size)) - return NULL; - /* A valid data block will always be aligned to the ID size. */ if (WARN_ON_ONCE(blk_lpos->begin !=3D ALIGN(blk_lpos->begin, sizeof(db->i= d))) || WARN_ON_ONCE(blk_lpos->next !=3D ALIGN(blk_lpos->next, sizeof(db->id)= ))) { @@ -1319,6 +1315,10 @@ static const char *get_data(struct prb_data_ring *da= ta_ring, /* Subtract block ID space from size to reflect data size. */ *data_size -=3D sizeof(db->id); =20 + /* Sanity check. Data-less blocks were handled earlier. */ + if (WARN_ON_ONCE(!data_check_size(data_ring, *data_size) || !*data_size)) + return NULL; + return &db->data[0]; } =20 base-commit: 9095f233c0258e9a05e958c7d822eb38681e7a5a --=20 2.47.3