Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1062160pxf; Thu, 1 Apr 2021 23:34:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPBwTVnwtitPXTIQaJX0s+7fZjGirCy9oFg3ijSYx/X5kpfIbyUha47k6m0yAEBZpDa7W4 X-Received: by 2002:a17:906:9714:: with SMTP id k20mr12524711ejx.519.1617345244966; Thu, 01 Apr 2021 23:34:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617345244; cv=none; d=google.com; s=arc-20160816; b=0No4xOBSRuLUuwqOs/AdLyyhN1+HuYF8o02URGFr6fNtQrkJ/Og+iviY7tyAfg2CdL SfG7Eog64+4pxsSqGqIMLJtB9w80mxUJ1EYW0S+5uE1cjIRA+DKJosl1VGl0KiD/eBXe XIQZQjqGrOFRnlMruwL8rvGNz1FVlMHGLM9ybzvq/BqIuvdpAMGg/Ry474y6JOY1SHJL zsb/xdw/ncLnVxsdIpXqJ3U8uha50G0qkRrVw5W9o6zZ4khguEmlvJ69LdM8+EYUkuEd 2dIPNm3TaL8rU7kmFv1+K5QuTCubQZ2kdiqCPXnEkkFb1EHgz0g3x9J/HfxgH40kGPmA hYjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=G/vpzlyyM2rPbrSDkAuLYhmEHk5mVC6tRg7O69Zv9j0=; b=PNEvcX7NalGWAqch87eg1KKru1/2RWc5ipwVUOGdgYlXgNCuRCaiXO7trxWSMF0/kf rT47bKQUMQLi7cihJbXJQpQNurLc0fVqzqH+USuWrA/rUob6NoEWaga9/Lv0pOOo+7vm xqzBIdoR0bVwV40y1Lc8pNdCDEKHH29CbJ5NRfxpMGLNKoXqm9NZbMqEHaqwjUYsdVOM 7CFjzIyumi0ThDXNrHfDMNY++DwR/fJvmWMLn8/A2kSF64sdQTtqjHTdEuOH9ktDeoN8 tdAsxn7DdtG5JrAX6JmWA2E2w1drDt/qrP5q4qBwPXmp37F+5kph7BlFBWH1UhssEaFs uMmA== ARC-Authentication-Results: i=1; mx.google.com; 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 lg14si5973216ejb.6.2021.04.01.23.33.30; Thu, 01 Apr 2021 23:34:04 -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; 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 S230183AbhDBGc3 (ORCPT + 99 others); Fri, 2 Apr 2021 02:32:29 -0400 Received: from verein.lst.de ([213.95.11.211]:42642 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbhDBGc0 (ORCPT ); Fri, 2 Apr 2021 02:32:26 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id C98B968BFE; Fri, 2 Apr 2021 08:32:21 +0200 (CEST) Date: Fri, 2 Apr 2021 08:32:21 +0200 From: Christoph Hellwig To: Kees Cook Cc: Greg Kroah-Hartman , Christoph Hellwig , Nathan Chancellor , Arnd Bergmann , Tejun Heo , Alexander Viro , "Rafael J. Wysocki" , Shuah Khan , Nathan Chancellor , Nick Desaulniers , Andrew Morton , Kefeng Wang , "Matthew Wilcox (Oracle)" , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, clang-built-linux@googlegroups.com, Michal Hocko , Alexey Dobriyan , Lee Duncan , Chris Leech , Adam Nichols , linux-hardening@vger.kernel.org Subject: Re: [PATCH v4 3/3] sysfs: Unconditionally use vmalloc for buffer Message-ID: <20210402063221.GA5260@lst.de> References: <20210401221320.2717732-1-keescook@chromium.org> <20210401221320.2717732-4-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210401221320.2717732-4-keescook@chromium.org> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 01, 2021 at 03:13:20PM -0700, Kees Cook wrote: > The sysfs interface to seq_file continues to be rather fragile > (seq_get_buf() should not be used outside of seq_file), as seen with > some recent exploits[1]. Move the seq_file buffer to the vmap area > (while retaining the accounting flag), since it has guard pages that will > catch and stop linear overflows. This seems justified given that sysfs's > use of seq_file almost always already uses PAGE_SIZE allocations, has > normally short-lived allocations, and is not normally on a performance > critical path. This looks completely weird to me. In the end sysfs uses nothing of the seq_file infrastructure, so why do we even pretend to use it? Just switch sysfs_file_kfops_ro and sysfs_file_kfops_rw from using ->seq_show to ->read and do the vmalloc there instead of pretending this is a seq_file. > Once seq_get_buf() has been removed (and all sysfs callbacks using > seq_file directly), this change can also be removed. And with sysfs out of the way I think kiling off the other few users should be pretty easy as well.