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: <CANn89iJm718SNK5kyEZYKioJmNnn4yFxg+t7=ph_GYXfd98C0w@mail.gmail.com>
Date: Tue, 8 Jul 2025 06:14:41 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: David Howells <dhowells@...hat.com>
Cc: Jiayuan Chen <jiayuan.chen@...ux.dev>, netdev@...r.kernel.org, mrpre@....com, 
	syzbot+de6565462ab540f50e47@...kaller.appspotmail.com, 
	Neal Cardwell <ncardwell@...gle.com>, Kuniyuki Iwashima <kuniyu@...gle.com>, 
	"David S. Miller" <davem@...emloft.net>, David Ahern <dsahern@...nel.org>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v4] tcp: Correct signedness in skb remaining
 space calculation

On Tue, Jul 8, 2025 at 6:11 AM David Howells <dhowells@...hat.com> wrote:
>
> Jiayuan Chen <jiayuan.chen@...ux.dev> wrote:
>
> > The types of the variables involved are:
> > '''
> > copy: ssize_t (s64 on 64-bit systems)
> > size_goal: int
> > skb->len: unsigned int
> > '''
> >
> > Due to C's type promotion rules, the signed size_goal is converted to an
> > unsigned int to match skb->len before the subtraction. The result is an
> > unsigned int.
> >
> > When this unsigned int result is then assigned to the s64 copy variable,
> > it is zero-extended, preserving its non-negative value. Consequently, copy
> > is always >= 0.
>
> Ewww.
>
> Would it be better to explicitly force the subtraction to be signed, e.g.:
>
>                 skb = tcp_write_queue_tail(sk);
>                 if (skb)
>                         copy = size_goal - (ssize_t)skb->len;
>
> rather than relying on getting it right with an implicit conversion to a
> signed int of the same size?
>
> If not, is it worth sticking in a comment to note the potential issue?

I prefer the old construct, without a cast. TCP has a lot of 32bit
operations, stcking casts or comments is not helping.

Note how throwing a 'bigger type just in case' was broken...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ