linux-kernel - Re: [PATCH net-next v1] 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] [day] [month] [year] [list]

Message-ID: <CANn89iKxTj29DG-44d7SbhEh3_h4PG8009RK9+sAZJx_pg04kw@mail.gmail.com>
Date: Thu, 3 Jul 2025 05:33:16 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: Jiayuan Chen <jiayuan.chen@...ux.dev>
Cc: netdev@...r.kernel.org, mrpre@....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>, 
	David Howells <dhowells@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v1] tcp: Correct signedness in skb remaining
 space calculation

On Thu, Jul 3, 2025 at 5:03 AM Jiayuan Chen <jiayuan.chen@...ux.dev> wrote:

> Hi Eric,
>
> I'm working with a reproducer generated by syzkaller [1], and its core
> logic is roughly as follows:
>
> '''
> setsockopt(fd, TCP_REPAIR, 1)
> connect(fd);
> setsockopt(fd, TCP_REPAIR, -1)
>
> send(fd, small);
> sendmmsg(fd, buffer_2G);
> '''
>
> First, because TCP_REPAIR is enabled, the send() operation leaves the skb
> at the tail of the write_queue. Subsequently, sendmmsg is called to send
> 2GB of data.
>
> Due to TCP_REPAIR, the size_goal is reduced, which can cause the copy
> variable to become negative. However, because of integer promotion bug
> mentioned in the previous email, this negative value is misinterpreted as
> a large positive number. Ultimately, copy becomes a huge value, approaching
> the int32 limit. This, in turn, causes sk->sk_forward_alloc to overflow,
> which is the exact issue reported by syzkaller.
>
> On a related note, even without using TCP_REPAIR, the tcp_bound_to_half_wnd()
> function can also reduce size_goal on its own. Therefore, my understanding is
> that under extreme conditions, we might still encounter an overflow in
> sk->sk_forward_alloc.
>
> So, I think we have good reason to change copy to an int.

Ok, I wish you had stated you were working on a syzbot report from the
very beginning.

Why hiding ?

Please send a V2 of the patch.