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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 29 Oct 2022 15:25:48 +0800 From: "Ziyang Xuan (William)" <william.xuanziyang@...wei.com> To: Eric Dumazet <edumazet@...gle.com> CC: <davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>, <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <peterpenkov96@...il.com>, <maheshb@...gle.com>, <ast@...nel.org>, <daniel@...earbox.net>, <hawk@...nel.org>, <john.fastabend@...il.com> Subject: Re: [PATCH net] net: tun: fix bugs for oversize packet when napi frags enabled > On Fri, Oct 28, 2022 at 8:32 PM Ziyang Xuan > <william.xuanziyang@...wei.com> wrote: >> >> Recently, we got two syzkaller problems because of oversize packet >> when napi frags enabled. >> >> One of the problems is because the first seg size of the iov_iter >> from user space is very big, it is 2147479538 which is bigger than >> the threshold value for bail out early in __alloc_pages(). And >> skb->pfmemalloc is true, __kmalloc_reserve() would use pfmemalloc >> reserves without __GFP_NOWARN flag. Thus we got a warning as following: >> >> ======================================================== >> > >> Restrict the packet size less than ETH_MAX_MTU to fix the problems. >> Add len check in tun_napi_alloc_frags() simply. Athough that makes >> some kinds of packets payload size slightly smaller than the length >> allowed by the protocol, for example, ETH_HLEN + sizeof(struct ipv6hdr) >> smaller when the tun device type is IFF_TAP and the packet is IPv6. But >> I think that the effect is small and can be ignored. > > I am not sure about ETH_MAX_MTU being completely safe. > > napi_get_frags() / napi_alloc_skb() is reserving NET_SKB_PAD + > NET_IP_ALIGN bytes. > > transport_header being an offset from skb->head, > we probably want to use (ETH_MAX_MTU - NET_SKB_PAD - NET_IP_ALIGN) Hi Eric, Thank you for your review. I did not notice the reserved skb space. I will fix it in v2 patch. Thanks. > > My objection to your initial patch was that you were using PAGE_SIZE, > while Ethernet MTU can easily be ~9000 > > But 0xFFFF is a bit too much/risky. > > Thanks. > >> >> Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver") >> Signed-off-by: Ziyang Xuan <william.xuanziyang@...wei.com> >> --- >> drivers/net/tun.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/net/tun.c b/drivers/net/tun.c >> index 27c6d235cbda..98d3160fcae2 100644 >> --- a/drivers/net/tun.c >> +++ b/drivers/net/tun.c >> @@ -1459,7 +1459,7 @@ static struct sk_buff *tun_napi_alloc_frags(struct tun_file *tfile, >> int err; >> int i; >> >> - if (it->nr_segs > MAX_SKB_FRAGS + 1) >> + if (it->nr_segs > MAX_SKB_FRAGS + 1 || len > ETH_MAX_MTU) >> return ERR_PTR(-EMSGSIZE); >> >> local_bh_disable(); >> -- >> 2.25.1 >> > . >
Powered by blists - more mailing lists