Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp724771pxj; Thu, 13 May 2021 15:37:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyMMjcz97tcn/E1psjjwDhm6Y2EphgcYDa9D+Nt1NqOMtmkATHKW05KIH7oZ1nVRD+sKb2Q X-Received: by 2002:a17:906:74c6:: with SMTP id z6mr46416146ejl.13.1620945428524; Thu, 13 May 2021 15:37:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620945428; cv=none; d=google.com; s=arc-20160816; b=SzZSevUCuk6ttuDDwezP7f2HnK+CaGnOGsjND5lou6pxfLD35Ge8mGlfNn5efo+LIg ebYSPGVZ7As5wl8/05tQaT/ew+/zNRe4R/ezmi0KM/Lz/27AqagWhG5UJDCsqlCk9U9n gkj4gmQAZu1QH2dCdF8LpfPrX5BFjyWdre17hbrH5WmebHosCowxmEaXyL3lBnwYyxFc lAD8+jVGeWKuC2zBu7Y0s4VzmOQ5Qe03DEya69qbhD7JS4aycFwM9ICEvyIlxyvJ/a5+ Si/ZojC/cDy8xzX6rbbKd+jw2/Kr3vdrO21rrxPONtzRh9ZnmzXfSPAJTdcMAaK7x9uU Rwuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject:dkim-signature; bh=CpBtM9FtVod+gxuw6KNEPrQb2ZhUJeUilXqd0/IO794=; b=zxpZCGJwUUOdkGyzpiKZLAz9yXBGmBdigMJPhOlikVMRil+6aj+7ixnxpfxOisyGcP +dVNBZB1wU3RUaez13/OZAWFrlYztt/JHY31JEw0ISIr3y+YAlJB2JbWRpd1soTvS/XE nrAXNdfARLye5dMAkVscbEOigTyzf5YDrrhag9GJeBNDHwKcI8WLr1wlQ6z/eS6iMXi9 F12q5MtPPU45XrBEHqgj4UPkFUJAWkhOrnmo0Oi2qorf5GIgSm/WSYG5xE7zvUjOz2xD EG+smo7LcAxSUWEMZ9gpo9uAh+LDj6X0uB6wStzrpUzV7Q+EvfJoThRpVlF94aSvgBkY EGLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=DN5jcTcL; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w13si4355006ejo.365.2021.05.13.15.36.45; Thu, 13 May 2021 15:37:08 -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=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=DN5jcTcL; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235064AbhEMQQx (ORCPT + 99 others); Thu, 13 May 2021 12:16:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39012 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235063AbhEMQQv (ORCPT ); Thu, 13 May 2021 12:16:51 -0400 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42464C06174A for ; Thu, 13 May 2021 09:15:38 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id 5so10062900qvk.0 for ; Thu, 13 May 2021 09:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CpBtM9FtVod+gxuw6KNEPrQb2ZhUJeUilXqd0/IO794=; b=DN5jcTcLpBHfkTzhvP2qoL4+j/duZboAI+AhIqXz9rIzbb88ZYycKnHkU0kuBuqXet az4OM1BI9TOBhEjJAWL1oC8m8bW7bOMXFivKDZU4MUjryJl9uI9HwJwQd4sPSQ41J3+k iPlIXalLS3sxhGUneTjqGGkBVO988Ct/AJxmm2h5fHv9X+cuy3gKxzied/lA5LWm1KO8 8doAgeX0r+zTSE83qwhfAxg3P3KRMjwJuT4cA2YkTp8vcLXpC8egM2smWSHABaJb/Jy+ U8e0daOmJZroEgrlejKt+Gmd0Rtu3uBWr1g16cEUPeUfm/DSCL2VuHjqcICKkO0azTo2 uUZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CpBtM9FtVod+gxuw6KNEPrQb2ZhUJeUilXqd0/IO794=; b=KYgId6MdkmMiiUIWrLuW96Y7jh56fX3eoFTsYcfX/HT7aAhJX4zrknNQiHJFv/ss2H 4t3l1H/qR1mggD7EabeKKzuGXa04UJDNmOxg/ViiZABwVcZDaeP12YTtYu5mWtY4AGRn QLpf3/maRKSZ+34xQ3qq/QsBpPAcx3dNhlUzrro6+61dkRlmlZx+oW1qP1t1vPD27cdQ Kgwdkm2fA4xbcoz3tLtsAaFnsmuBhwj+au7lSsnX43NmcDRkiSn/e7g1ter7psNdLYAi WMqufP1fYy3kpQ/gIjpTEyObR0+DYgMTezMme66iVP/mYJGDRr4/oJlFc4AQwVUPHLXh /mIw== X-Gm-Message-State: AOAM5336ZtyLZnBgIGE13mxUVgS9aw6S8I9jFUCn96J5ewxZwKxXAx0V hXxvWYhDsUs67VsJbouxnqpxw5lqTWFwxQ== X-Received: by 2002:a05:6214:964:: with SMTP id do4mr42076512qvb.36.1620922537453; Thu, 13 May 2021 09:15:37 -0700 (PDT) Received: from ?IPv6:2620:10d:c0a8:11d1::1214? ([2620:10d:c091:480::1:7c1f]) by smtp.gmail.com with ESMTPSA id h12sm2764158qkj.52.2021.05.13.09.15.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 May 2021 09:15:36 -0700 (PDT) Subject: Re: [PATCH] sysctl: Limit the size of I/Os to PAGE_SIZE From: Josef Bacik To: "Matthew Wilcox (Oracle)" , linux-kernel@vger.kernel.org, Christoph Hellwig , Al Viro , Kees Cook Cc: linux-abi@vger.kernel.org, linux-fsdevel@vger.kernel.org, Alexey Dobriyan References: <20210513160649.2280429-1-willy@infradead.org> <47a34aa5-ad1a-6259-d9cb-f85f314f9ffb@toxicpanda.com> Message-ID: Date: Thu, 13 May 2021 12:15:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <47a34aa5-ad1a-6259-d9cb-f85f314f9ffb@toxicpanda.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/13/21 12:12 PM, Josef Bacik wrote: > On 5/13/21 12:06 PM, Matthew Wilcox (Oracle) wrote: >> We currently allow a read or a write that is up to KMALLOC_MAX_SIZE. >> This has caused problems when cat decides to do a 64kB read and >> so we allocate a 64kB buffer for the sysctl handler to store into. >> The immediate problem was fixed by switching to kvmalloc(), but it's >> ridiculous to allocate so much memory to read what is likely to be a >> few bytes. >> >> sysfs limits reads and writes to PAGE_SIZE, and I feel we should do the >> same for sysctl.  The largest sysctl anyone's been able to come up with >> is 433 bytes for /proc/sys/dev/cdrom/info >> >> This will allow simplifying the BPF sysctl code later, but I'll leave >> that for someone who understands it better. >> >> Signed-off-by: Matthew Wilcox (Oracle) >> --- >>   fs/proc/proc_sysctl.c | 15 +++++++++------ >>   1 file changed, 9 insertions(+), 6 deletions(-) >> >> diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c >> index dea0f5ee540c..a97a8a4ff270 100644 >> --- a/fs/proc/proc_sysctl.c >> +++ b/fs/proc/proc_sysctl.c >> @@ -562,11 +562,14 @@ static ssize_t proc_sys_call_handler(struct kiocb *iocb, >> struct iov_iter *iter, >>       if (!table->proc_handler) >>           goto out; >> -    /* don't even try if the size is too large */ >> +    /* reads may return short values; large writes must fail now */ >> +    if (count >= PAGE_SIZE) { >> +        if (write) >> +            goto out; >> +        count = PAGE_SIZE; >> +    } >>       error = -ENOMEM; >> -    if (count >= KMALLOC_MAX_SIZE) >> -        goto out; >> -    kbuf = kvzalloc(count + 1, GFP_KERNEL); >> +    kbuf = kmalloc(PAGE_SIZE, GFP_KERNEL); >>       if (!kbuf) >>           goto out; > > Below here we have > > kbuf[count] = '\0'; > Nevermind I just re-read it and it's if (write) kbuf[count] = '\0'; I'm stupid, you can add Reviewed-by: Josef Bacik Thanks, Josef