linux-kernel - Re: [PATCH 04/44] io_uring/net: Change some dubious min

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] [day] [month] [year] [list]

Message-ID: <20251122113139.2462035d@pumpkin>
Date: Sat, 22 Nov 2025 11:31:39 +0000
From: David Laight <david.laight.linux@...il.com>
To: Jens Axboe <axboe@...nel.dk>
Cc: linux-kernel@...r.kernel.org, io-uring@...r.kernel.org
Subject: Re: [PATCH 04/44] io_uring/net: Change some dubious min_t()

On Thu, 20 Nov 2025 08:53:56 -0700
Jens Axboe <axboe@...nel.dk> wrote:

> On 11/20/25 8:48 AM, David Laight wrote:
> > On Thu, 20 Nov 2025 07:48:58 -0700
> > Jens Axboe <axboe@...nel.dk> wrote:
> >   
> >> On 11/19/25 3:41 PM, david.laight.linux@...il.com wrote:  
> >>> From: David Laight <david.laight.linux@...il.com>
> >>>
> >>> Since iov_len is 'unsigned long' it is possible that the cast
> >>> to 'int' will change the value of min_t(int, iov[nbufs].iov_len, ret).
> >>> Use a plain min() and change the loop bottom to while (ret > 0) so that
> >>> the compiler knows 'ret' is always positive.
> >>>
> >>> Also change min_t(int, sel->val, sr->mshot_total_len) to a simple min()
> >>> since sel->val is also long and subject to possible trunctation.
> >>>
> >>> It might be that other checks stop these being problems, but they are
> >>> picked up by some compile-time tests for min_t() truncating values.    
> >>
> >> Fails with clang-21:
> >>
> >> io_uring/net.c:855:26: error: call to '__compiletime_assert_2006' declared with 'error' attribute: min(sel->val, sr->mshot_total_len) signedness error
> >>   855 |                 sr->mshot_total_len -= min(sel->val, sr->mshot_total_len);  
> > 
> > I'll take a look, I normally use gcc but there must be something
> > subtle going on. Actually which architecture? I only tested x86-64.  
> 
> This is x86-64.
> 

It is related to the test a few lines higher:
	if (sel->val > 0 && sr->flags & IORING_RECV_MSHOT_LIM) {
'sel->val' is ssize_t, gcc is tracking that test so statically_true(sel->val >= 0)
is 'true' and the signed variable can be compared against the 'unsigned'
'sr->mshot_total_len'.

It seems clang isn't as clever.
Perhaps it reloads sel->val from memory - so loses the result of the comparison.
Even swapping the order of the two tests might fix it.
As might caching sel->val in a local (even a signed one).

The comment in the header file for io_br_sel.val doesn't seem to include
the case where 'val' is a length!

The simple fix is to use umin() since all the values are clearly non-negative.

	David