netdev - Re: SECURITY PROBLEM: Any user can crash the kernel with TCP ZEROCOPY

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: <CANn89iKbyTRvWEE-3TyVVwTa=N2KsiV73-__2ASktt2hrauQ0g@mail.gmail.com>
Date: Wed, 24 Jan 2024 11:11:47 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: "zhangpeng (AS)" <zhangpeng362@...wei.com>
Cc: Matthew Wilcox <willy@...radead.org>, linux-mm@...ck.org, linux-fsdevel@...r.kernel.org, 
	netdev@...r.kernel.org, akpm@...ux-foundation.org, davem@...emloft.net, 
	dsahern@...nel.org, kuba@...nel.org, pabeni@...hat.com, arjunroy@...gle.com, 
	wangkefeng.wang@...wei.com
Subject: Re: SECURITY PROBLEM: Any user can crash the kernel with TCP ZEROCOPY

On Wed, Jan 24, 2024 at 10:30 AM zhangpeng (AS) <zhangpeng362@...wei.com> wrote:
>
>
> By using git-bisect, the patch that introduces this issue is 05255b823a617
> ("tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive."). v4.18-rc1.
>
> Currently, there are no other repro or c reproduction programs can reproduce
> the issue. The syz log used to reproduce the issue is as follows:
>
> r3 = socket$inet_tcp(0x2, 0x1, 0x0)
> mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)
> r4 = socket$inet_tcp(0x2, 0x1, 0x0)
> bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)
> connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)
> r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
> 0x181e42, 0x0)
> fallocate(r5, 0x0, 0x0, 0x85b8818)
> sendfile(r4, r5, 0x0, 0x3000)
> getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,
> &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0,
> 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x10)
> r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
> 0x181e42, 0x0)
>

Could you try the following fix then ?

(We also could remove the !skb_frag_off(frag) condition, as the
!PageCompound() is necessary it seems :/)

Thanks a lot !

diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 1baa484d21902d2492fc2830d960100dc09683bf..ee954ae7778a651a9da4de057e3bafe35a6e10d6
100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1785,7 +1785,9 @@ static skb_frag_t *skb_advance_to_frag(struct
sk_buff *skb, u32 offset_skb,

 static bool can_map_frag(const skb_frag_t *frag)
 {
-       return skb_frag_size(frag) == PAGE_SIZE && !skb_frag_off(frag);
+       return skb_frag_size(frag) == PAGE_SIZE &&
+              !skb_frag_off(frag) &&
+              !PageCompound(skb_frag_page(frag));
 }

 static int find_next_mappable_frag(const skb_frag_t *frag,