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=-3.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 6BB72C433ED for ; Fri, 23 Apr 2021 19:27:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 97C086134F for ; Fri, 23 Apr 2021 19:27:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 97C086134F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=paul-moore.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B024C6B0036; Fri, 23 Apr 2021 15:27:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD9C86B006C; Fri, 23 Apr 2021 15:27:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A1126B006E; Fri, 23 Apr 2021 15:27:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0214.hostedemail.com [216.40.44.214]) by kanga.kvack.org (Postfix) with ESMTP id 77BD56B0036 for ; Fri, 23 Apr 2021 15:27:49 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2CB378248D7C for ; Fri, 23 Apr 2021 19:27:49 +0000 (UTC) X-FDA: 78064616658.24.887DD49 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf07.hostedemail.com (Postfix) with ESMTP id 24C77A0003A6 for ; Fri, 23 Apr 2021 19:27:48 +0000 (UTC) Received: by mail-ej1-f48.google.com with SMTP id v6so74101224ejo.6 for ; Fri, 23 Apr 2021 12:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GGmswUWs0RhjLm11KvpLJnLg6G3DSRO1QkIM1fXbk7s=; b=02tLZjLeYkxGPB2kXMhpJATnGAtGmYPsmzTboVgl/LmG2WbReuSJpJrPlxJd90ALKR 97sPdAcYuV4/oaDQXmOwIgdjD3nkc+vwW8/gPUaZkaeqTEC94+s9E0R4OCZ0ig8W1+nl nqyN38L7dwd2RMuWYF5cioO9XPfvVR8M4cdSiNRh2SX+d3OdOTrXdAsX8ksUKHDvZ72w waDXwP7pSE48qNSKfm0IAeh4BaI4PqR+hSTGCwLYYApnxxeImRsdoFWDHwFXJVBi+Q3C zRKDs+BLZ0nrlPvvpF+sufIB8MBeGS7GtuL2Al6hW3uvcCJLJ1xC0gcUtMBvVM0hyzO2 HqhA== 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:content-transfer-encoding; bh=GGmswUWs0RhjLm11KvpLJnLg6G3DSRO1QkIM1fXbk7s=; b=SN0cn59N0ypykYUah/0n3gpBVSifSykB0wwF3osXKxDQ4YR0uMGa3AoPRTWdpYVwok JdnYn8nmWYJ+h8A3rKX+J87qCStXxmWGbvTee8osQAYPPLbBREqOUHQCAvNTD9nzVsMj Ra79zbRTrf7np/V1e+wScOaQyZmxs0+fJPtnBqnEI6aN+6TBrbnuvd4BvZmqyUat5R8k ZLoOw8VFtrNP5QlwRRPJ+UAdEyulRTITxdru47C/opwRuzyceHrEwRzQFMjb8JpH4YWI DAooUWHLZvwOaQI4M+FbZlCkVI/pr8pz0YNNXrAAv2t0Pp+Y9+yiQ91doSjtbydsT37f +w9w== X-Gm-Message-State: AOAM531aPsXeULkr2tp0sipgCnBNEVsyB2iQlAdIbBsHy8MWRE5w37Yl gOU7ENV2+wGrImvAWacGlil+xmcHHzZloMP/d8m+ X-Google-Smtp-Source: ABdhPJxFunO8u/UyY8hB3Vbeq+g3Smp6PbgP4kttDr+81dktNKM4DKLyCDErbfUfCB/j8VqV43lTQ0UFMkx/w+QTI+E= X-Received: by 2002:a17:906:f283:: with SMTP id gu3mr5825341ejb.91.1619206066758; Fri, 23 Apr 2021 12:27:46 -0700 (PDT) MIME-Version: 1.0 References: <000000000000307cc205bbbf31d3@google.com> <29f03460-c0ba-07a0-ef98-9597ef157797@oracle.com> In-Reply-To: <29f03460-c0ba-07a0-ef98-9597ef157797@oracle.com> From: Paul Moore Date: Fri, 23 Apr 2021 15:27:35 -0400 Message-ID: Subject: Re: WARNING in netlbl_cipsov4_add To: Vegard Nossum Cc: syzbot , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 24C77A0003A6 X-Stat-Signature: uiuidyh1bxrna1q4hn4moxd3hrhjiw6b Received-SPF: none (paul-moore.com>: No applicable sender policy available) receiver=imf07; identity=mailfrom; envelope-from=""; helo=mail-ej1-f48.google.com; client-ip=209.85.218.48 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619206068-341470 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Apr 23, 2021 at 6:47 AM Vegard Nossum wr= ote: > Hi Paul, > > This syzbot report reproduces in mainline for me and it looks like > you're the author/maintainer of this code, so I'm just adding some info > to hopefully aid the preparation of a fix: Hi Vegard, Yes, you've come to the right place, thank you for your help in tracking this down. Some comments and initial thoughts below ... > On 2021-02-20 08:05, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: ... > Running strace on the reproducer says: > > socket(PF_NETLINK, SOCK_RAW, NETLINK_GENERIC) =3D 3 > socket(PF_NETLINK, SOCK_RAW, NETLINK_GENERIC) =3D 4 > sendto(4, > "(\0\0\0\20\0\5\0\0\0\0\0\0\0\0\0\3\0\0\0\21\0\2\0NLBL_CIPSOv4\0\0\0\0", > 40, 0, {sa_family=3DAF_NETLINK, pid=3D0, groups=3D00000000}, 12) =3D 40 > recvfrom(4, > "\234\0\0\0\20\0\0\0\0\0\0\0\f\r\0\0\1\2\0\0\21\0\2\0NLBL_CIPSOv4\0\0\0\0= \6\0\1\0\24\0\0\0\10\0\3\0\3\0\0\0\10\0\4\0\0\0\0\0\10\0\5\0\f\0\0\0T\0\6\0= \24\0\1\0\10\0\1\0\1\0\0\0\10\0\2\0\v\0\0\0\24\0\2\0\10\0\1\0\2\0\0\0\10\0\= 2\0\v\0\0\0\24\0\3\0\10\0\1\0\3\0\0\0\10\0\2\0\n\0\0\0\24\0\4\0\10\0\1\0\4\= 0\0\0\10\0\2\0\f\0\0\0", > 4096, 0, NULL, NULL) =3D 156 > recvfrom(4, > "$\0\0\0\2\0\0\0\0\0\0\0\f\r\0\0\0\0\0\0(\0\0\0\20\0\5\0\0\0\0\0\0\0\0\0"= , > 4096, 0, NULL, NULL) =3D 36 > sendmsg(3, {msg_name(0)=3DNULL, > msg_iov(1)=3D[{"T\0\0\0\24\0\1\0\0\0\0\0\0\0\0\0\1\0\0\0,\0\10\200\34\0\7= \200\10\0\5\0\3608) > \10\0\6\0\0\0\0\0\10\0\6\0\0\0\0\0\f\0\7\200\10\0\5\0\0\0\0\0\4\0\4\200\1= 0\0\1\0\0\0\0\0\10\0\2\0\1\0\0\0", > 84}], msg_controllen=3D0, msg_flags=3D0}, 0) =3D 84 > > We're ending up in netlbl_cipsov4_add() with CIPSO_V4_MAP_TRANS, so it > calls netlbl_cipsov4_add_std() where this is the problematic allocation: > > doi_def->map.std->lvl.local =3D kcalloc(doi_def->map.std->lvl.local_size, > sizeof(u32), > GFP_KERNEL); > > It looks like there is already a check on the max size: > > if (nla_get_u32(nla_b) > > CIPSO_V4_MAX_LOC_LVLS) > goto add_std_failure; > if (nla_get_u32(nla_b) >=3D > doi_def->map.std->lvl.local_size) > doi_def->map.std->lvl.local_size =3D > nla_get_u32(nla_b) + 1; > > However, the limit is quite generous: > > #define CIPSO_V4_INV_LVL 0x80000000 > #define CIPSO_V4_MAX_LOC_LVLS (CIPSO_V4_INV_LVL - 1) > > so maybe a fix would just lower this to something that agrees with the > page allocator? Hmm, I agree that from a practical point of view the limit does seem high. The issue is that I'm not sure we have an easy way to determine an appropriate local limit considering that it is determined by the LSM and in some cases it is determined by the LSM's loaded policy. On the plus side you need privilege to get this far in the code so the impact is minimized, although we still should look into catching this prior to the WARN_ON_ONCE() in __alloc_pages_nodemask(). If nothing else it allows the fuzzers to keep making progress and not die here. We could drop CIPSO_V4_MAX_LOC_LVLS to an arbitrary value, or better yet make it a sysctl (or similar), but that doesn't feel right and I'd prefer to not create another runtime config knob if we don't have to do so. Is there a safe/stable way to ask the allocator what size is *too* big? That might be a better solution as we could catch it in the CIPSO code and return an error before calling kmalloc. I'm not a mm expert, but looking through include/linux/slab.h I wonder if we could just compare the allocation size with KMALLOC_SHIFT_MAX? Or is that still too big? > At first glance it may appear like there is a similar issue with > doi_def->map.std->lvl.cipso_size, but that one looks restricted to a > saner limit of CIPSO_V4_MAX_REM_LVLS =3D=3D 255. It's probably better to > double check both in case I read this wrong. This one is a bit easier, that limit is defined by the CIPSO protocol and we really shouldn't change that. FWIW, I would expect that we would have a similar issue with the CIPSO_V4_MAX_LOC_CATS check in the same function. My initial thinking is that we can solve it in the same manner as the CIPSO_V4_MAX_LOC_LVLS fix. --=20 paul moore www.paul-moore.com