Received: by 10.223.185.116 with SMTP id b49csp5295643wrg; Wed, 7 Mar 2018 09:22:15 -0800 (PST) X-Google-Smtp-Source: AG47ELseF6p0IHi1FKnakvlF4YU5BhqkXQlbwDDTAaKNZ684bzd2gas3vpdgH4PynkntTIQUfjHI X-Received: by 10.101.101.10 with SMTP id x10mr19004686pgv.223.1520443335383; Wed, 07 Mar 2018 09:22:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520443335; cv=none; d=google.com; s=arc-20160816; b=GKTXChXZOYSdgcHMqGh/phl3Fh6APLCw7L5uE29ahe+7BEe/Ra04/WB1DvsRz1nl2i lDnB/yKT72+B/HqHdbrAoi46GH6ZM3ytdTvQX0XYhCk5XzkjLJy8zXeIlnn/TeKc9lyX UaTJOCbBUYeCakXP5sEe7krqEzxXdcDRjhMDD/Czhu62gFXJzdeLd5pp7gY/v72xmaCZ SULrXv3rrhQFA9Mj8ZNhKXMtxTbEZy2Wo/9ADk55C0+YZ1oeZkOhscjiA+ID0Fq2V6en Mzs7fGLGJTdZwlBUnVIlJdaX0EnuLFbJexUemFaK5NloF1cSSaQwU7sXfM65iyKzu5wV ne5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=kTcbpa1psGzMK5u1jk6brG33xsIaF0G/G+nSwQ/hU3U=; b=hZy6dreQVft3M6ILygGSpFt8r/+YoM9c4OoXvG8/2MvcknJNdNaDD1lC3ppJM4WwAo MbTU0YtwMrJfY4RsB77A49P0woR7pWzhwuEqd+EsIlcsiPVg7/lcRqOburuU49SVreXx Qrg8Gl7RK137ACzXmLj2Jz85yIAjWBZYXhVSzIvR6yJCWYz4qjXF15URZ06DGAcJdcP7 YxDCVBGjUNP/JOrQWZb8COZTjhZAsKNsQPkZ2z0X7RdDci8G/YlPBkn+MaGJ9rN7K958 2R+/8SkBT6hAe/sg8gfe5KoafMnRJcBfhwEiX9PXnsm8BioStvlRFSpb6OD1yTiQVXWq ZEKg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=XmGK4pQ4; dkim=fail header.i=@chromium.org header.s=google header.b=esDeVges; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f23-v6si13439778plk.810.2018.03.07.09.21.59; Wed, 07 Mar 2018 09:22:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=XmGK4pQ4; dkim=fail header.i=@chromium.org header.s=google header.b=esDeVges; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754558AbeCGRUf (ORCPT + 99 others); Wed, 7 Mar 2018 12:20:35 -0500 Received: from mail-ua0-f196.google.com ([209.85.217.196]:33800 "EHLO mail-ua0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751220AbeCGRUd (ORCPT ); Wed, 7 Mar 2018 12:20:33 -0500 Received: by mail-ua0-f196.google.com with SMTP id m43so1933037uah.1 for ; Wed, 07 Mar 2018 09:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kTcbpa1psGzMK5u1jk6brG33xsIaF0G/G+nSwQ/hU3U=; b=XmGK4pQ4ZkA2M6m66Dj8VBObu8sL2nyLIMQ+CwmlxW8z1TeWGJYFhm7QfVYcDtJxiO 7hDATkUQR3LWwe5QEjke7E967OuwtFwPktQ74KRjXoaynr5oDbZ+4NlObMLMl213IEYh WBXkoUq8ALEI95Z0+VY4hbf+T01X6U4y8W09G29qWBpRvsKy4ffvTQt+WRguRLwWtBQe hifbCOe6OYxmxvsE06RGPqRY0DIrhqc62Zq7EiWFx4QqqrPIEpCrZD97vWt4x+NZ2eza RXxU7Sitizsm6Saw8vQEQpX5htRvQQACapdKbcTIW7ziV7msbwQtp9hmjVtuuPPMaBo3 Wkig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kTcbpa1psGzMK5u1jk6brG33xsIaF0G/G+nSwQ/hU3U=; b=esDeVges2q8ykE9fbakOkfNtJ2bY2ipT+9BEWWvGs8RUM1Yvf5SwwnDOwFW0duPMRv 6Whd/VTdr09wTvX5zLXNCJ/aUyVL/P6xQ+xEZw/LImvMDKzDZ3fzI9aZBPqiWOxEzJjr vVi8mifSCUTjA8kz892n3mQoxeSXoQSW7NqFs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kTcbpa1psGzMK5u1jk6brG33xsIaF0G/G+nSwQ/hU3U=; b=KD1vQkRFmFTKDIS0e8AjPQGLwFswwKsZC8JL1Gn2w/iRLdlmPRKcy31BPZg63T4w4R N/ZvPtnMGuPrqb9WtwvJfMSy0MHNiw2eT2ZuJawseN57EJoyUDJgdvltD8xo7PoM6OXw ACYcHPvsnsqqQXhQiKCKxqmN7HJmrb4Xcx5yUeMjhkhiyipfGKsdt100VfLSx3+YLbie leQd6vD9FSE30wa47k7WbfUI4iKtlKL/K6RJ3jetlRLzAzrukJVsO1p090v8rwoFAxfj ydXcETbggz3zqYvzaPKjBPhP3hPLBRWSyht4JiJl6oH4H+RybrHiIrd/JAv0WYubi1mi 39YA== X-Gm-Message-State: AElRT7H1PjfSLpR4P8cfPcD4ADloGfej6NuL/uJ+ZvH7EkE0pHpllAUh rxXSon7NagLOxaXNvY/+AyP3tC0dRSb3exsCrbLPg+iB X-Received: by 10.176.48.231 with SMTP id d7mr5511187uam.0.1520443232012; Wed, 07 Mar 2018 09:20:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.242.140 with HTTP; Wed, 7 Mar 2018 09:20:31 -0800 (PST) In-Reply-To: References: <20180307054608.GA9300@beast> From: Kees Cook Date: Wed, 7 Mar 2018 09:20:31 -0800 X-Google-Sender-Auth: d1LCYAsV7ZqQx-5-nsStnbT0xj4 Message-ID: Subject: Re: [PATCH] staging: lustre: Remove VLA usage To: Rasmus Villemoes Cc: Greg Kroah-Hartman , LKML , "Tobin C. Harding" , Tycho Andersen , Oleg Drokin , Andreas Dilger , James Simmons , Dmitry Eremin , Gargi Sharma , Lustre Development List , devel@driverdev.osuosl.org, Kernel Hardening Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 7, 2018 at 5:10 AM, Rasmus Villemoes wrote: > On 2018-03-07 06:46, Kees Cook wrote: >> The kernel would like to remove all VLA usage. This switches to a >> simple kasprintf() instead. >> >> Signed-off-by: Kees Cook >> --- >> drivers/staging/lustre/lustre/llite/xattr.c | 19 +++++++++++++------ >> 1 file changed, 13 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/staging/lustre/lustre/llite/xattr.c b/drivers/staging/lustre/lustre/llite/xattr.c >> index 532384c91447..aab4eab64289 100644 >> --- a/drivers/staging/lustre/lustre/llite/xattr.c >> +++ b/drivers/staging/lustre/lustre/llite/xattr.c >> @@ -87,7 +87,7 @@ ll_xattr_set_common(const struct xattr_handler *handler, >> const char *name, const void *value, size_t size, >> int flags) >> { >> - char fullname[strlen(handler->prefix) + strlen(name) + 1]; >> + char *fullname; >> struct ll_sb_info *sbi = ll_i2sbi(inode); >> struct ptlrpc_request *req = NULL; >> const char *pv = value; >> @@ -141,10 +141,13 @@ ll_xattr_set_common(const struct xattr_handler *handler, >> return -EPERM; >> } >> >> - sprintf(fullname, "%s%s\n", handler->prefix, name); > > It's probably worth pointing out that this actually fixes an > unconditional buffer overflow: fullname only has room for the two > strings and the '\n', but vsnprintf() is told that the buffer has > infinite size (well, INT_MAX), so there should be plenty of room to > append the '\0' after the '\n'. > >> + fullname = kasprintf(GFP_KERNEL, "%s%s\n", handler->prefix, name); >> + if (!fullname) >> + return -ENOMEM; >> rc = md_setxattr(sbi->ll_md_exp, ll_inode2fid(inode), >> valid, fullname, pv, size, 0, flags, >> ll_i2suppgid(inode), &req); >> + kfree(fullname); >> if (rc) { >> if (rc == -EOPNOTSUPP && handler->flags == XATTR_USER_T) { >> LCONSOLE_INFO("Disabling user_xattr feature because it is not supported on the server\n"); >> @@ -364,7 +367,7 @@ static int ll_xattr_get_common(const struct xattr_handler *handler, >> struct dentry *dentry, struct inode *inode, >> const char *name, void *buffer, size_t size) >> { >> - char fullname[strlen(handler->prefix) + strlen(name) + 1]; >> + char *fullname; >> struct ll_sb_info *sbi = ll_i2sbi(inode); >> #ifdef CONFIG_FS_POSIX_ACL >> struct ll_inode_info *lli = ll_i2info(inode); >> @@ -411,9 +414,13 @@ static int ll_xattr_get_common(const struct xattr_handler *handler, >> if (handler->flags == XATTR_ACL_DEFAULT_T && !S_ISDIR(inode->i_mode)) >> return -ENODATA; >> #endif >> - sprintf(fullname, "%s%s\n", handler->prefix, name); > > Same here. > > I'm a little surprised this hasn't been caugt by static analysis, I > thought gcc/coverity/smatch/whatnot had gotten pretty good at computing > the size of the output generated by a given format string with "known" > arguments and comparing to the size of the output buffer. Though of > course it does require the tool to be able to do symbolic manipulations, > in this case realizing that > > outsize == strlen(x)+strlen(y)+1+1 > bufsize == strlen(x)+strlen(y)+1 > > Rasmus Oh yes, hah. I didn't even see the \n in the string. :P So, both a VLA fix and a buffer over-run fix. Can I add your "Reviewed-by"? :) -Kees -- Kees Cook Pixel Security