From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7680C43381 for ; Thu, 21 Feb 2019 16:01:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 93D002083E for ; Thu, 21 Feb 2019 16:01:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="fk3VYFCq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728181AbfBUQBC (ORCPT ); Thu, 21 Feb 2019 11:01:02 -0500 Received: from mail-yw1-f68.google.com ([209.85.161.68]:39911 "EHLO mail-yw1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726525AbfBUQBB (ORCPT ); Thu, 21 Feb 2019 11:01:01 -0500 Received: by mail-yw1-f68.google.com with SMTP id f192so2080353ywh.6 for ; Thu, 21 Feb 2019 08:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RQaERAGY/l+exEw+yk/QM39K2fNmdrGpASoOHjuCuzo=; b=fk3VYFCqSKd6124hOVYbpjj3A6r6J609SQMOHsFSg48SyI+E2hyASXClPZVAwqhg2j Eoij8pGkaVgRlzVSvl3/aFC928GGD7iWXkE2YRiI/rkJ7rAXGJwTaVg8VphLfXNqO09Q rfj16+ykuGamLaVDK2USeXnAn2xQfIDL8QVpwvx5S8SZY3tiOKeCnweiiulDuGSRS+g4 A4cc84Boakv+UpVaYEy59TKWuivgaEfJPd5izqSQwvIH+3uzBVvJjQZgO8rF6Xt4CvE1 EZZ/GH58d0Zh+KkM9dnDaQwogsxuBndtFFv0911aIIMBgFtpEydIGZYl0rvxg6HNDZh4 cWxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RQaERAGY/l+exEw+yk/QM39K2fNmdrGpASoOHjuCuzo=; b=B9fTWSVai4A5+WTsZq0vrXhlCZQi1E+23Qqxt15g+NRqSjj4MF2nzOzmtlJ4AgR4aK KWpE1d1IWpZHZnykv/zVDkEmdSVDRzbajt6ZGuyCl7bqtIG1+fgwLkyrdynTM7A95Gh8 1nv0wOwm+9v3Txq/MfReP+tbMkR1PBL55cdwJe9EdogUmABg3BFkxF/5fnioFJuPQokv Kyk56L+tHyUkEbBU69JAtCFVESNVNqimnvQTx6+NPNnbqBROrj5jOuNuO6J7zfZvRLNY PZhuibDzWai7H+AZDD8u9xzfGjI3AMBD3IvNv67KSig7+L7Cue8xUhs551vMoBbUjcWR DU9w== X-Gm-Message-State: AHQUAubiiZhKc/v7eGay7lRcG9xtrd0beEUeheUYylfENL8YqAmJwIR7 S7ejBkxdtgV4U7SMcM+YRSbq5IdOS7BgveDOj1zzqw== X-Google-Smtp-Source: AHgI3IabNw6NPwTVZP4fZaDRHN+soAzgLVwDlKMm3IS+fYqpRCzgXA1tK+MhVwrYxlkPyicZgtvEytaKCdUY/6y3+PI= X-Received: by 2002:a25:3004:: with SMTP id w4mr33085613ybw.461.1550764860209; Thu, 21 Feb 2019 08:01:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Dumazet Date: Thu, 21 Feb 2019 08:00:47 -0800 Message-ID: Subject: Re: [PATCH] tcp: detect use sendpage for slab-based objects To: Vasily Averin Cc: netdev Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Feb 21, 2019 at 7:30 AM Vasily Averin wrote: > > There was few incidents when XFS over network block device generates > IO requests with slab-based metadata. If these requests are processed > via sendpage path tcp_sendpage() calls skb_can_coalesce() and merges > neighbour slab objects into one skb fragment. > > If receiving side is located on the same host tcp_recvmsg() can trigger > following BUG_ON > usercopy: kernel memory exposure attempt detected > from XXXXXX (kmalloc-512) (1024 bytes) > > This patch helps to detect the reason of similar incidents on sending side. > > Signed-off-by: Vasily Averin > --- > net/ipv4/tcp.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c > index 2079145a3b7c..cf9572f4fc0f 100644 > --- a/net/ipv4/tcp.c > +++ b/net/ipv4/tcp.c > @@ -996,6 +996,7 @@ ssize_t do_tcp_sendpages(struct sock *sk, struct page *page, int offset, > goto wait_for_memory; > > if (can_coalesce) { > + WARN_ON_ONCE(PageSlab(page)); Please use VM_WARN_ON_ONCE() to make this a nop for CONFIG_VM_DEBUG=n Also the whole tcp_sendpage() should be protected, not only the coalescing part. (The get_page() done few lines later should not be attempted either) > skb_frag_size_add(&skb_shinfo(skb)->frags[i - 1], copy); > } else { > get_page(page); > -- > 2.17.1 > It seems the bug has nothing to do with TCP, and belongs to the caller. Otherwise you need to add the check to all existing .sendpage() / .sendpage_locked() handler out there.