netdev - Re: [PATCH net] rds: Fix endian annotations across various assignments

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: <398e53d8-906d-43c9-9395-f6115dcb945b@lunn.ch>
Date: Sun, 10 Aug 2025 20:41:49 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Ujwal Kundur <ujwal.kundur@...il.com>, allison.henderson@...cle.com,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, horms@...nel.org, netdev@...r.kernel.org,
	linux-rdma@...r.kernel.org, rds-devel@....oracle.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] rds: Fix endian annotations across various
 assignments

On Sun, Aug 10, 2025 at 07:25:06PM +0100, Al Viro wrote:
> On Sun, Aug 10, 2025 at 06:47:05PM +0100, Al Viro wrote:
> 
> > >  		switch (type) {
> > >  		case RDS_EXTHDR_NPATHS:
> > >  			conn->c_npaths = min_t(int, RDS_MPATH_WORKERS,
> > > -					       be16_to_cpu(buffer.rds_npaths));
> > > +					      (__force __u16)buffer.rds_npaths);
> > 
> > No.  It will break on little-endian.  That's over-the-wire data you are
> > dealing with; it's *NOT* going to be host-endian.  Fix the buggered
> > annotations instead.
> 
> PS: be16_to_cpu() is not the same thing as a cast.  On a big-endian box,
> a 16bit number 1000 (0x3e8) is stored as {3, 0xe8}; on a little-endian it's
> {3, 0xe8} instead; {0xe8, 3} means 59395 there (0xe8 * 256 + 3).

Hi Al

This smells of an LLM generated patch. So i think you are somewhat
wasting your time explaining in detail why this is wrong. Well, maybe
in a few generations of LLM it might learn from what you said, but
that does not address the immediate problem.

We need developers using LLM to accept they have often wrong, and you
need to spend time and effort:

1) Proving it got is wrong.
2) That after a lot of effort, failing to prove it wrong, accept it might be right.
3) Proving it actually got it right.

It took me about 60 seconds to prove the POLLERR change was wrong, and
i know nothing about this code base. So it is in fact not a lot of
effort.

	Andrew