Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp724613pxj; Thu, 13 May 2021 15:36:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzeoLo+aVQTIsZwg/2OpfNI5OAGldFFm355VuRNZ7z3PJooJxSV7dTPh04fAcVI/CosqQ5z X-Received: by 2002:a50:fc87:: with SMTP id f7mr52010547edq.215.1620945414809; Thu, 13 May 2021 15:36:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620945414; cv=none; d=google.com; s=arc-20160816; b=hTe2ObZlmmY66M0UXrGP7Grcov6Abv9KgMMV3Gs00LsW5y0ZBWvyyUMfBuVg/N/QK2 d7JNkwBHajHFM8XPrPcAISVaui0TULq6Ewn8cHobnxj1LVlacfhmr2x2UTKhzsNaWGbl LV7/Q2HzZ/NKOrQZW968GElIuTIyN3fafXyhWWg+XNJWg2ExYKYTQbnB/qRk0dmzUKHg qm0wUO2ioGbMazlJY3Qr66a5BtgatvUC4Yoi73UBNiDRW4hKGpsnA37lQuZdWmc3M3y2 fLTIV/rXr2OjSXHgTGLSVIL3I5xuL5O7mhvTeyGFP7L91GDuTRMfYWJ0jqc7RCe9TBKB XnRQ== 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:from:references :cc:to:subject:dkim-signature; bh=c3FwvvgxpK8Jgr/cfoaMZxB/tNnCRMPVSiFd4uKGvlQ=; b=WSQCu+4QcTIfA7Iydzr44Nnt39GW3Cpzjk0ikU1BpigHXp33UmZVcckMWBf4mI7m/k DRDj/TUjqm96DhhzFqfxc9GqcMsS/0Y2HnQepCpgzpWlBD6+DFIRM7KSd6k6LTO9q52Y upfCFvqlh7TgSB7LKGjKUpm6EyGUX3pf7v+rBoWdnjTXwXga+wPnoozGyk0SRYP7sPPN CbniKZw9v+BNfDwdBa+GtZXP2Una27tu+Onzv7bbvaQ35KXie2WI+CPCEiSVdHUaJGy5 HccPKBFy03wbPUG0XSBOerJTaFUirhpmSxx/3Lvm6Ln6zyOgYyvQk+EcvsmuQOVzG+pu luUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=MADfEPYf; 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 h22si4158350ejt.62.2021.05.13.15.36.30; Thu, 13 May 2021 15:36:54 -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=MADfEPYf; 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 S234935AbhEMQOW (ORCPT + 99 others); Thu, 13 May 2021 12:14:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234993AbhEMQOJ (ORCPT ); Thu, 13 May 2021 12:14:09 -0400 Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 673AFC061574 for ; Thu, 13 May 2021 09:12:58 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id m13so4878846qtk.13 for ; Thu, 13 May 2021 09:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=c3FwvvgxpK8Jgr/cfoaMZxB/tNnCRMPVSiFd4uKGvlQ=; b=MADfEPYf8G6gf9l1Gqm6w23OgPrQuI2bxxipGlcCPSPd44+7+DzuPS1pzH2iWgT+zn g0l0Kujhrg6t/Ex9b5j3Bj2W31aY5m/cGA22wYeq4g4Fs+5tr51eUzo8GE32RKHy3tqs ZUR2lUlGtt2nb1daWEbmScvkyl8W0QLZHqCf+7VI4FqhJ8ysakKTz3uwUKW84pK2Es+Y PhjNqocQaILOqO3NUastr7Mjdg9lJyWJ0bTmmM5DB+fua4qZxA7yuFnJblH6b56j19YG C0B7Jg1jnHZHxF6pjL3qHU3Qlum0+j2AIhktMMsVfmuDFDeZLU2YGUNbGiSN/Uozgvsz l+dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=c3FwvvgxpK8Jgr/cfoaMZxB/tNnCRMPVSiFd4uKGvlQ=; b=J7wfnsyx2KAFezdhR+jr3M0p2JrmRax0n1lIWhmWj6T83oKAXNpLvHCREnmdO0iUU1 V2OjgC7lQE+8a8abdaHpaxCn4D65Qz6aw0eD7G3FBLCezbLhHQScHTzZ1ty17hYYxSj+ OmlUPHjKKCZlP53XC4kfLzYcQ4i7Dl2bBo2ZQVjh72r/MwKbCApSmcZdglnU2b6m5ZpE i3Y8cT+wwWzABljcGv60J/ziCQqDbqaIb8zI1qTYwCyL8Dx2zER3FktXFfINndkjPilH YraS0AIHuH2qVFzVDzPPErvcVTQQ4DIPGjmXsuBdwPcM30+w21qU7WdQV9wOTAnVG0ct 6AxQ== X-Gm-Message-State: AOAM5331Xe8sn+zvSvhkuY9m552XJScbP8ILbr2MvtufroKhkttA1NMV wGqbOUF7xJXWx6czHNAZuLlzTQ== X-Received: by 2002:ac8:5691:: with SMTP id h17mr39092410qta.185.1620922377413; Thu, 13 May 2021 09:12:57 -0700 (PDT) Received: from ?IPv6:2620:10d:c0a8:11d1::1214? ([2620:10d:c091:480::1:7c1f]) by smtp.gmail.com with ESMTPSA id h7sm2557702qtj.35.2021.05.13.09.12.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 May 2021 09:12:56 -0700 (PDT) Subject: Re: [PATCH] sysctl: Limit the size of I/Os to PAGE_SIZE 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> From: Josef Bacik Message-ID: <47a34aa5-ad1a-6259-d9cb-f85f314f9ffb@toxicpanda.com> Date: Thu, 13 May 2021 12:12:54 -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: <20210513160649.2280429-1-willy@infradead.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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'; with will overflow with this patch. So maybe instead we do if (count >= PAGE_SIZE) count = PAGE_SIZE - 1; kbuf = kmalloc(count); and that solves your problem and keeps us from overflowing. Thanks, Josef