Re: [PATCH v3] seq_buf: Mark a seq_buf overflowed when terminating it loses a byte

[Alejandro Colomar <alx+linux-hardening@kernel.org>]

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

Hi Kees,

> Date: 2026-11-10 14:06:07-0800
> From: Kees Cook <kees@kernel.org>
>
> On Wed, Nov 04, 2026 at 12:17:00PM +0100, Alejandro Colomar wrote:
> > > No current caller checks for overflow after terminating a seq_buf that
> > > can be left exactly full, so none of them behaves differently.
> >
> > Okay for this patch, but still some question:
> >
> > Since data truncation is almost always wrong, is it a bug that those
> > users are not verifying that no overflow happened?  Or do they have a
> > good reason to not verify?
> 
> Right, this would need a case-by-case analysis. Some expect it and some
> don't. This change to the API is to make it defensive in the general
> case without making existing truncation worse.

Agree.  In shadow-utils we have the same approach.  We're first
hardening the writes to avoid overflows, and are leaving the truncations
unreported as they were before, since that needs a case-by-case
analysis.

I won't give my reviewed-by, since I fundamentally think this is
building on the mistake of having sizes and lengths instead of pointers.
But I _think_ this patch is good, FWIW.


Have a lovely night!
Alex

> 
> -Kees
> 
> -- 
> Kees Cook

-- 
<https://www.alejandro-colomar.es>

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