linux-kernel - Re: [PATCH 1/2] tools/nolibc: Add fread() to stdio.h

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <9c043cdd-499c-48ae-8b1c-e49d541a8b2b@t-8ch.de>
Date: Tue, 6 Jan 2026 12:02:18 +0100
From: Thomas Weißschuh <linux@...ssschuh.net>
To: David Laight <david.laight.linux@...il.com>
Cc: Daniel Palmer <daniel@...ngy.jp>, w@....eu, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] tools/nolibc: Add fread() to stdio.h

On 2026-01-05 11:01:42+0000, David Laight wrote:
> On Mon, 5 Jan 2026 18:43:03 +0900
> Daniel Palmer <daniel@...ngy.jp> wrote:
> > On Mon, 5 Jan 2026 at 18:27, David Laight <david.laight.linux@...il.com> wrote:
> > > But you've deleted the partial bytes from the input.
> > > I'm sure that isn't right.
> > > Normally a FILE is buffered and the bytes are saved for the next read.
> > > Remember you can be reading from a pipe that is being written using
> > > 'block buffering' - so it is valid for only a partial 'item' be read.
> > > (I'm sure non-blocking IO is also valid...)  
> > 
> > I see now. If a partial read happens, the next call to fread() will
> > read from after the end of the partial read that happened and it'll be
> > broken.
> > Since in nolibc the FILE pointer that gets used isn't really a pointer
> > but the file descriptor I'm not sure where we'd stash the partial part
> > so we need to avoid doing the partial read entirely.
> 
> Except you can't really avoid the partial read.
> Doing multiple read() system calls doesn't help.
> The situation where it can happen probably doesn't happen for nolibc.

> Is there support for ferror() and/or feof() ?
> (a global 'u8 fstate[64]' indexed by fd number would probably suffice.)
> If so you could set the 'error' bit and then error any further fread()s.

No, neither of them is currently supported.
Given that the support for 'FILE *' is obviously somewhat limited in
general and the existing fwrite() shares the same issues, I am leaning
towards picking up these patches. We can then find a proper solution.

Users trying to use these APIs really correctly will quite fast find out
that ferror() and feof() are missing.

The only real solution for partial writes that I see with the current
architecture is to limit the 'size' argument to '1'.
Maybe even with a static assertion. But there still won't be any way to
properly signal the issue to the caller. Not that ferror() could
distinguish the types of error in any case...


Thomas