All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: David Laight <David.Laight@aculab.com>
Cc: 'Kees Cook' <keescook@chromium.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	John Ogness <john.ogness@linutronix.de>,
	Vijay Balakrishna <vijayb@linux.microsoft.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-hardening@vger.kernel.org"
	<linux-hardening@vger.kernel.org>
Subject: Re: [PATCH] printk: ringbuffer: Fix truncating buffer size min_t cast
Date: Mon, 14 Aug 2023 14:56:10 +0200	[thread overview]
Message-ID: <ZNokaoSFTXeB_LP4@alley> (raw)
In-Reply-To: <42a1e2099fe141c3a57e808cbf06d8a0@AcuMS.aculab.com>

On Mon 2023-08-14 10:42:26, David Laight wrote:
> From: Kees Cook
> > Sent: 11 August 2023 06:46
> > 
> > If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in
> > copy_data() was causing writes to truncate. This manifested as output
> > bytes being skipped, seen as %NUL bytes in pstore dumps when the available
> > record size was larger than 65536. Fix the cast to no longer truncate
> > the calculation.
> > 
> ...
> > diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringbuffer.c
> > index 2dc4d5a1f1ff..fde338606ce8 100644
> > --- a/kernel/printk/printk_ringbuffer.c
> > +++ b/kernel/printk/printk_ringbuffer.c
> > @@ -1735,7 +1735,7 @@ static bool copy_data(struct prb_data_ring *data_ring,
> >  	if (!buf || !buf_size)
> >  		return true;
> > 
> > -	data_size = min_t(u16, buf_size, len);
> > +	data_size = min_t(unsigned int, buf_size, len);
> 
> I'd noticed that during one of my test compiles while looking
> at making min() less fussy.
> 
> A better fix would be:
> 	data_size = min(buf_size + 0u, len);

This looks like a magic to me. The types are:

	unsigned int data_size;
	unsigned int buf_size;
	u16 len

I would naively expect that

	data_size = min(buf_size, len);

would do the right job and expand @len to "unsigned int".

I do not remember why "min_t" was used. Was it an optimization?
Did we miss the problem with casting "u32" down to "u16"?

I tried to read the discussion at
https://lore.kernel.org/lkml/b6a49ed73aba427ca8bb433763fa94e9@AcuMS.aculab.com/
but it is more about "signed" vs. "unsigned" problem. Maybe
it is more complicated that I expected.

> Or put an ack on my patch 3/5 to minmax.h and then min(buf_size, len)
> will be fine (because both arguments are unsigned).

Do you mean
https://lore.kernel.org/lkml/6dc20ac7cb6f4570a0160f076e8362e3@AcuMS.aculab.com/ ?
It seems to be just indentation cleanup.

Best Regards,
Petr

PS: I have already pushed the patch because it looked reasonable and
    got testing. I have to admit that I am probably in a pre-vacation
    hurry mode.

  reply	other threads:[~2023-08-14 12:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-11  5:45 [PATCH] printk: ringbuffer: Fix truncating buffer size min_t cast Kees Cook
2023-08-11  6:16 ` Vijay Balakrishna
2023-08-11 13:29 ` Guilherme G. Piccoli
2023-08-11 16:53 ` Tyler Hicks
2023-08-14  6:20 ` John Ogness
2023-08-14  7:40 ` Sergey Senozhatsky
2023-08-14 10:42 ` David Laight
2023-08-14 12:56   ` Petr Mladek [this message]
2023-08-14 13:33     ` David Laight
2023-08-14 11:40 ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZNokaoSFTXeB_LP4@alley \
    --to=pmladek@suse.com \
    --cc=David.Laight@aculab.com \
    --cc=gpiccoli@igalia.com \
    --cc=john.ogness@linutronix.de \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=stable@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=vijayb@linux.microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.