Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp4558344ybg; Mon, 8 Jun 2020 10:50:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyj3uyNPGIq+c+N8tb9+4gy1BT9YErOMSUXnh7LfcAXgV196Yz5bqGnp8ahEsAhnY+7LmU7 X-Received: by 2002:a17:906:9243:: with SMTP id c3mr21878907ejx.400.1591638617083; Mon, 08 Jun 2020 10:50:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591638617; cv=none; d=google.com; s=arc-20160816; b=pSSdueEhZGqNziJKawyQnYPgl3rcU01dAFs46jPe+RFhojZCCE7XVfNMx1+Y5V/pTV vWzapRm+5hQVG3HffJ6TN5M2shI2+mrQe+qUZdnRgwCh8akfP7H/k96R4fmCDdku/hCQ TFmh9HC2dW2Um/VLe50AabZx93GmxM9d/Zc+Sq9iTz6op+Kf2Hgcte2ZitX7ARTAP0bg LatO8aiKlkAetcIjA7ZiX/lZAGCldH2/3VPNvuhtWRQTgM95lH8e/o3AoxfVaoKu/yFI GQ+gzgYCAvPvvdYPCtXZDWZpFun0+fVvja9xiG+P6gZ3BFGmOrf2w3CEue6qEP423jDa MypA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:from:subject:references :mime-version:message-id:in-reply-to:date:dkim-signature; bh=4cSXd/WEBOMmjBzHT5V64B0CdBFXvfK/YmpOS865C/E=; b=Ud+NGxYpTta9ihNBpIVTohyDNGOr5M+591tuhmz2/bcXv7vqPDbRfZIIzLE9CFIaBH UGg5pWbFOBW83BSLsljOm3DPYPfxVQGnj25vMGnM1/nKOTXkDwoRGmq4bVHhtaqRAbso 8wXjnwELhqtuzDus7SHS1FZNd1Epp7lGys5IadZegbXGoFJTJb0KZj5sxhXOR79cH438 fwdJrIdCppy0kx7D80npSI3cEzTO5UNX2cPGt7/ESYYWG3ZAIOfc4FE4xEJOLZzuMEJx TFcz7ccMa1S83a8wO0JGxvyL71YNN74a6omn507YpRiAuoBo8IAV+avmR6r3i+fo8nI3 2Uwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=U3EfLuu7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y8si7150700edr.179.2020.06.08.10.49.54; Mon, 08 Jun 2020 10:50:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=U3EfLuu7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387459AbgFHQtS (ORCPT + 99 others); Mon, 8 Jun 2020 12:49:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387453AbgFHQtR (ORCPT ); Mon, 8 Jun 2020 12:49:17 -0400 Received: from mail-qt1-x84a.google.com (mail-qt1-x84a.google.com [IPv6:2607:f8b0:4864:20::84a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01A0DC08C5C3 for ; Mon, 8 Jun 2020 09:49:15 -0700 (PDT) Received: by mail-qt1-x84a.google.com with SMTP id y5so16057644qtd.0 for ; Mon, 08 Jun 2020 09:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=4cSXd/WEBOMmjBzHT5V64B0CdBFXvfK/YmpOS865C/E=; b=U3EfLuu7JaLkGMY8hL5QIb1XxjOTvGLy8smtkMre6qK5eYxBLb2UL/zFO2wglyhsMu UvezhXn9mhrv0A7/FhCf8JnkEJTlV1VLNsipBdO/UsRGBq7OU4cvXBok03qi61RIPwYY cPFbpx7piIlTZzGtkW8/4i7sum2DbqS2EbzkDwEB3fJwkusvralu/xdeCEm1jeCCTR5I hgQLAlzmiNsYiwK8xuG6S/FSqj9OtLCIfPL3Ux2nlm4a+ru9sgaOfJjtOfYfH4CFwTEx mqp0KagzuygvTokeurbn2I3y+aupyDOmqHa0WNO3I2RH1aXp9uX80NDRvqN3aNVp0vHm OWaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=4cSXd/WEBOMmjBzHT5V64B0CdBFXvfK/YmpOS865C/E=; b=tr+VB8ryNYPmZO7YDof6hOV0N010/o1UksQx3JS8snWE7jCnyqE/iUpfEuX0t0dQOU 3ATgJUow6dNF1xpMaNBb24EEZ4CBgtTmTiXmsZWMnJPKCtKghHJR9fCPk6d8e9mbZR1R nN1LOL4KEzSrivLcQHZ17uoymR0bD6n947oZKVw2GOR3hfqB7IJldPiV4QJNEN9orNoV Ef18b9zP0gSrjmrRGKALKcJ7slVgP6J6sV2RlYEOZ2nS9hl+Wa6LjgJrdIudkJ9bOOAw 7BPOpkU9qlLVd79XfPNdpXDACcYC600cSxMUJsg+hA7offC9CQPmH5O3cInv1+LKHNnV HTpQ== X-Gm-Message-State: AOAM5333p7FbRBzxzn4uHGlrZjxRhT52gRymsOFTgy4We5uVLYqr9Hey 6VSoKsTBWLZiIHlysZGlOQ5oMms= X-Received: by 2002:a0c:f991:: with SMTP id t17mr23459051qvn.123.1591634954981; Mon, 08 Jun 2020 09:49:14 -0700 (PDT) Date: Mon, 8 Jun 2020 09:49:13 -0700 In-Reply-To: Message-Id: <20200608164913.GA142074@google.com> Mime-Version: 1.0 References: <20200424064338.538313-1-hch@lst.de> <20200424064338.538313-6-hch@lst.de> <1fc7ce08-26a7-59ff-e580-4e6c22554752@oracle.com> <20200608065120.GA17859@lst.de> <20200608130503.GA22898@lst.de> Subject: Re: WARNING: CPU: 1 PID: 52 at mm/page_alloc.c:4826 __alloc_pages_nodemask (Re: [PATCH 5/5] sysctl: pass kernel pointers to ->proc_handler) From: sdf@google.com To: Alexei Starovoitov Cc: Christoph Hellwig , Vegard Nossum , Kees Cook , Iurii Zaikin , Alexei Starovoitov , Daniel Borkmann , LKML , Al Viro , bpf , Andrey Ignatov Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/08, Alexei Starovoitov wrote: > On Mon, Jun 8, 2020 at 6:05 AM Christoph Hellwig wrote: > > > > On Mon, Jun 08, 2020 at 09:45:49AM +0200, Vegard Nossum wrote: > > > Just a test case. > > > > > > Allowing the kernel to allocate an unbounded amount of memory on > behalf > > > of userspace is an easy DOS. > > > > > > All the length checks were already in there, e.g. > > > > > > static int cmm_timeout_handler(struct ctl_table *ctl, int write, > > > void __user *buffer, size_t *lenp, > loff_t > > > *ppos) > > > { > > > char buf[64], *p; > > > [...] > > > len = min(*lenp, sizeof(buf)); > > > if (copy_from_user(buf, buffer, len)) > > > return -EFAULT; > > > > Doesn't help if we don't know the exact limit yet. But we can put > > some arbitrary but reasonable limit like KMALLOC_MAX_SIZE on the > > sysctls and see if this sticks. > adding Stanislav. I think he's looking into this already. Yeah, I'm looking at it from the get/setsockopt point of view. I'm currently trying to bypass allocating a buffer if it's greater than PAGE_SIZE. I suppose for sysctls we should try to do something similar?