linux-kernel - Re: [PATCH net-next v4] tcp: Correct signedness in skb remaining space calculation

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: <2554853.1751980274@warthog.procyon.org.uk>
Date: Tue, 08 Jul 2025 14:11:14 +0100
From: David Howells <dhowells@...hat.com>
To: Jiayuan Chen <jiayuan.chen@...ux.dev>
Cc: dhowells@...hat.com, netdev@...r.kernel.org, mrpre@....com,
    syzbot+de6565462ab540f50e47@...kaller.appspotmail.com,
    Eric Dumazet <edumazet@...gle.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

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?

David