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: <2627957.1751985886@warthog.procyon.org.uk>
Date: Tue, 08 Jul 2025 15:44:46 +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:

> Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow.
> 
> When we send data, if an skb exists at the tail of the write queue, the
> kernel will attempt to append the new data to that skb. However, the code
> that checks for available space in the skb is flawed:
> '''
> copy = size_goal - skb->len
> '''
> 
> 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.
> 
> Assume we are sending 2GB of data and size_goal has been adjusted to a
> value smaller than skb->len. The subtraction will result in copy holding a
> very large positive integer. In the subsequent logic, this large value is
> used to update sk->sk_forward_alloc, which can easily cause it to overflow.
> 
> The syzkaller reproducer uses TCP_REPAIR to reliably create this
> condition. However, this can also occur in real-world scenarios. The
> tcp_bound_to_half_wnd() function can also reduce size_goal to a small
> value. This would cause the subsequent tcp_wmem_schedule() to set
> sk->sk_forward_alloc to a value close to INT_MAX. Further memory
> allocation requests would then cause sk_forward_alloc to wrap around and
> become negative.
> 
> [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47
> 
> Reported-by: syzbot+de6565462ab540f50e47@...kaller.appspotmail.com
> Fixes: 270a1c3de47e ("tcp: Support MSG_SPLICE_PAGES")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@...ux.dev>

Reviewed-by: David Howells <dhowells@...hat.com>