linux-kernel - Re: [PATCH v1 0/3] Add ENDOF(), and use it to fix off-by-one bugs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <nqhz5vtobixqzgqfei3qgrcpyvjur6onhfeezidta7mgfmg5gx@qwzw3bw3lwr4>
Date: Fri, 26 Sep 2025 15:07:37 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Kees Cook <kees@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Christopher Bazley <chris.bazley.wg14@...il.com>, Rasmus Villemoes <linux@...musvillemoes.dk>, 
	Marco Elver <elver@...gle.com>, Michal Hocko <mhocko@...e.com>, 
	Al Viro <viro@...iv.linux.org.uk>, Alexander Potapenko <glider@...gle.com>, 
	Dmitry Vyukov <dvyukov@...gle.com>, Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH v1 0/3] Add ENDOF(), and use it to fix off-by-one bugs

Hi Kees,

On Thu, Sep 25, 2025 at 08:37:49PM -0700, Kees Cook wrote:
> On Thu, Sep 25, 2025 at 07:36:13PM -0700, Linus Torvalds wrote:
> > The thing is, the "start+len" model is actually *safer* than the
> > "start+len-1" model.
> 
> Sure. But start + len is a vector: "start" is a pointer, and "len" is a
> size. No problems at all.
> 
> > Obviously you cannot dereference a zero-sized object, but zero-sized
> > objects aren't "wrong" per se.
> 
> Right, totally agreed. I'm a big fan of zero-sized objects which are
> useful in all kinds of situations (e.g. empty flexible arrays). And
> as you're saying, a zero-sized object shares the same representation:
> start + len where len is 0.
> 
> What I dislike is having this vector collapsed into a pointer because
> it loses its explicit start/len information, and becomes ambiguous. And
> worse we have nothing that says "this pointer isn't safe to dereference".

The word END should be understood as "this isn't safe to dereference".

I'm not inventing anything new; it's something standard in a way, as
C++'s std::end is precisely that (and no, I don't like C++, but this
name is quite consistent everywhere, including the kernel itself).

> All the bounds safety work we've been doing lately is mostly centered
> around finding ways to retain the "len" part of dynamically sized object
> pointers so we can reconstruct the vector unambiguously.

END is useful in cases where you don't care about the begining.  It's
useful as a way to know where an array ends, regardless of how much
we've advanced in its contents.


Have a lovely day!
Alex

P.S.:  Please let me know if this patch set is suitable for applying, or
if I need to provide a better cover letter, or if I need to do anything
else.

> 
> Anyway, yay for vectors. :)
> 
> -Kees
> 
> -- 
> Kees Cook

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)