Received: by 10.223.176.5 with SMTP id f5csp327564wra; Tue, 30 Jan 2018 12:10:16 -0800 (PST) X-Google-Smtp-Source: AH8x226DsN39ArIwfrhUoCWi0f1m2I2aje7c6UTcH08yjsb5lp+6R78uEl5Bb/953LyxTfAEMb71 X-Received: by 2002:a17:902:1a4:: with SMTP id b33-v6mr25951535plb.58.1517343016264; Tue, 30 Jan 2018 12:10:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517343016; cv=none; d=google.com; s=arc-20160816; b=OjkWlivdFx1x0kQWYs/185TEnexfm/8VVX+h8QuSM0Z3F0IwfIjIk+UOd/6BCQEfOK thmMu4YwGt43LSDy+cdngX1xh7xhmeiloTwKb4vscJS7niFF3qn7sqNqt57J+aetBrzl VYCSXyQDCShUV/ANefsg4SDUzYCTgerW8Aq+c5X/6SUfM/o2LwGVd/TNW6tq15p0ocrI GqexL22wlJxFNM+iUcKH9UnCUPQc9j2Iv+YmAatvvKWV4r6cyNf9jwV8Ay6fEH5ohwC2 zI8QS9o6ZTXWS24Yb3gATNJ4v9XDvxe5Q36vYF3Ji77hE5qH9NPugQmaSRSl0N6E2dxM lHNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=WK9H0FCKCfoTtxD/qOB5QaGAL5XK0EufcpkTM2+w64Q=; b=L0NgYDDk3ifUxN8j/QaxsofjwIGwKCmtHxu5KbCMdLU4v7EsEmY6WZV6QFvZA40snK yQdPzte+sDCHGOqxOzdvEbQQGVHo4b5SDGO/8psbvQJKlptRncpeZMvgzdG+X9cYgwIT dkxPaETuBp0+Aezbo8q1D33MODgM9F+05jN246fjLqpoVtfr8FIojw2ccyoX5JW36nr5 9VtAuJyXegJYRoDrsLwdjhxRIXV/JQf/sxoZFFGvIUACGfA6gKQuV/pdGVl+2jn4fxe2 mGkF0hdioUf/sHoil7FwcBjTpG62XH1beFFA+iVnDZ752T1w3mtiDlpxr7VmbwNYdp4G WcbQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d16-v6si2934031pli.182.2018.01.30.12.10.01; Tue, 30 Jan 2018 12:10:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753764AbeA3T1v (ORCPT + 99 others); Tue, 30 Jan 2018 14:27:51 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:51568 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753742AbeA3T1s (ORCPT ); Tue, 30 Jan 2018 14:27:48 -0500 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.92]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 17B7DDD1; Tue, 30 Jan 2018 19:27:47 +0000 (UTC) Date: Tue, 30 Jan 2018 11:27:45 -0800 From: Andrew Morton To: Michal Hocko Cc: Dmitry Vyukov , "Kirill A. Shutemov" , Florian Westphal , Tetsuo Handa , David Miller , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev , Andrea Arcangeli , Yang Shi , syzkaller-bugs@googlegroups.com, LKML , Ingo Molnar , Linux-MM , David Rientjes , guro@fb.com, "Kirill A. Shutemov" Subject: Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2) Message-Id: <20180130112745.934883e37e696ab7f875a385@linux-foundation.org> In-Reply-To: <20180130140104.GE21609@dhcp22.suse.cz> References: <20180129072357.GD5906@breakpoint.cc> <20180129082649.sysf57wlp7i7ltb2@node.shutemov.name> <20180129165722.GF5906@breakpoint.cc> <20180129182811.fze4vrb5zd5cojmr@node.shutemov.name> <20180129223522.GG5906@breakpoint.cc> <20180130075226.GL21609@dhcp22.suse.cz> <20180130081127.GH5906@breakpoint.cc> <20180130082817.cbax5qj4mxancx4b@node.shutemov.name> <20180130095739.GV21609@dhcp22.suse.cz> <20180130140104.GE21609@dhcp22.suse.cz> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 30 Jan 2018 15:01:04 +0100 Michal Hocko wrote: > > Well, this is not about syzkaller, it merely pointed out a potential > > DoS... And that has to be addressed somehow. > > So how about this? > --- argh ;) > >From d48e950f1b04f234b57b9e34c363bdcfec10aeee Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Tue, 30 Jan 2018 14:51:07 +0100 > Subject: [PATCH] net/netfilter/x_tables.c: make allocation less aggressive > > syzbot has noticed that xt_alloc_table_info can allocate a lot of > memory. This is an admin only interface but an admin in a namespace > is sufficient as well. eacd86ca3b03 ("net/netfilter/x_tables.c: use > kvmalloc() in xt_alloc_table_info()") has changed the opencoded > kmalloc->vmalloc fallback into kvmalloc. It has dropped __GFP_NORETRY on > the way because vmalloc has simply never fully supported __GFP_NORETRY > semantic. This is still the case because e.g. page tables backing the > vmalloc area are hardcoded GFP_KERNEL. > > Revert back to __GFP_NORETRY as a poors man defence against excessively > large allocation request here. We will not rule out the OOM killer > completely but __GFP_NORETRY should at least stop the large request > in most cases. > > Fixes: eacd86ca3b03 ("net/netfilter/x_tables.c: use kvmalloc() in xt_alloc_table_info()") > Signed-off-by: Michal Hocko > --- > net/netfilter/x_tables.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c > index d8571f414208..a5f5c29bcbdc 100644 > --- a/net/netfilter/x_tables.c > +++ b/net/netfilter/x_tables.c > @@ -1003,7 +1003,13 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size) > if ((SMP_ALIGN(size) >> PAGE_SHIFT) + 2 > totalram_pages) > return NULL; offtopic: preceding comment here is "prevent them from hitting BUG() in vmalloc.c". I suspect this is ancient code and vmalloc sure as heck shouldn't go BUG with this input. And it should be using `sz' ;) So I suspect and hope that this code can be removed. If not, let's fix vmalloc! > - info = kvmalloc(sz, GFP_KERNEL); > + /* > + * __GFP_NORETRY is not fully supported by kvmalloc but it should > + * work reasonably well if sz is too large and bail out rather > + * than shoot all processes down before realizing there is nothing > + * more to reclaim. > + */ > + info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY); > if (!info) > return NULL; checkpatch sayeth networking block comments don't use an empty /* line, use /* Comment... So I'll do that and shall scoot the patch Davewards.