All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, Jan Engelhardt <jengelh@inai.de>,
	linux-man@vger.kernel.org
Subject: Re: Undefined Behavior in rw_verify_area() (was: sendfile(2) erroneously yields EINVAL on too large counts)
Date: Mon, 4 Mar 2024 16:31:05 +0100	[thread overview]
Message-ID: <ZeXpOVxPFIcVGapD@debian> (raw)
In-Reply-To: <ZeXnMO0DcZH63B_d@casper.infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

Hi Matthew!

On Mon, Mar 04, 2024 at 03:22:24PM +0000, Matthew Wilcox wrote:
> On Mon, Mar 04, 2024 at 04:09:26PM +0100, Alejandro Colomar wrote:
> > Depending on the width of those types, the sum may be performed as
> > 'loff_t' if `sizeof(loff_t) > sizeof(size_t)`, or as 'size_t' if
> > `sizeof(loff_t) <= sizeof(size_t)`.  Since 'loff_t' is a 64-bit type,
> > but 'size_t' can be either 32-bit or 64-bit, the former is possible.
> > 
> > In those platforms in which loff_t is wider, the addends are promoted to
> > 'loff_t' before the sum.  And a sum of positive signed values can never
> > be negative.  If the sum overflows (and the program above triggers
> > such an overflow), the behavior is undefined.
> 
> Linux is compiled with -fwrapv so it is defined.

Hmmm; thanks!  Still, I'm guessing that's used as a caution to avoid
opening Hell's doors, rather than a declaration that the kernel doesn't
care about signed-integer overflow bugs.  Otherwise, all the macros in
<linux/kernel/overflow.h> wouldn't make much sense, right?

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-03-04 15:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 13:49 sendfile(2) erroneously yields EINVAL on too large counts Jan Engelhardt
2024-03-04 13:52 ` Alejandro Colomar
2024-03-04 15:09   ` Undefined Behavior in rw_verify_area() (was: sendfile(2) erroneously yields EINVAL on too large counts) Alejandro Colomar
2024-03-04 15:22     ` Matthew Wilcox
2024-03-04 15:31       ` Alejandro Colomar [this message]
2024-03-10 18:35   ` sendfile(2) erroneously yields EINVAL on too large counts Jan Engelhardt
2024-03-10 18:53     ` Alejandro Colomar

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=ZeXpOVxPFIcVGapD@debian \
    --to=alx@kernel.org \
    --cc=jengelh@inai.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    /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.