From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B839C0044D for ; Wed, 11 Mar 2020 19:59:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9BAEF20739 for ; Wed, 11 Mar 2020 19:59:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387456AbgCKT7g (ORCPT ); Wed, 11 Mar 2020 15:59:36 -0400 Received: from mx2.suse.de ([195.135.220.15]:36402 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387433AbgCKT7g (ORCPT ); Wed, 11 Mar 2020 15:59:36 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id BF015AEC5; Wed, 11 Mar 2020 19:59:34 +0000 (UTC) Date: Wed, 11 Mar 2020 20:59:34 +0100 Message-ID: From: Takashi Iwai To: dsterba@suse.cz Cc: Chris Mason , Josef Bacik , David Sterba , linux-btrfs@vger.kernel.org Subject: Re: [PATCH] btrfs: sysfs: Use scnprintf() for avoiding potential buffer overflow In-Reply-To: <20200311191023.GH12659@twin.jikos.cz> References: <20200311093323.24955-1-tiwai@suse.de> <20200311191023.GH12659@twin.jikos.cz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Wed, 11 Mar 2020 20:10:23 +0100, David Sterba wrote: > > On Wed, Mar 11, 2020 at 10:33:23AM +0100, Takashi Iwai wrote: > > Since snprintf() returns the would-be-output size instead of the > > actual output size, the succeeding calls may go beyond the given > > buffer limit. Fix it by replacing with scnprintf(). > > Is this a mechanical conversion or is there actually a potential > overflow in the code? It's rather a result of pattern matching. > > Signed-off-by: Takashi Iwai > > --- > > fs/btrfs/sysfs.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c > > index 93cf76118a04..d3dc069789a5 100644 > > --- a/fs/btrfs/sysfs.c > > +++ b/fs/btrfs/sysfs.c > > @@ -310,12 +310,12 @@ static ssize_t supported_checksums_show(struct kobject *kobj, > > * This "trick" only works as long as 'enum btrfs_csum_type' has > > * no holes in it > > */ > > - ret += snprintf(buf + ret, PAGE_SIZE - ret, "%s%s", > > + ret += scnprintf(buf + ret, PAGE_SIZE - ret, "%s%s", > > (i == 0 ? "" : " "), btrfs_super_csum_name(i)); > > Loop count is a constant, each iteration filling with two %s of constant > length, buffer size is PAGE_SIZE. Yes, it's likely OK with the current code, but then snprintf() usage is utterly bogus. > > } > > > > - ret += snprintf(buf + ret, PAGE_SIZE - ret, "\n"); > > + ret += scnprintf(buf + ret, PAGE_SIZE - ret, "\n"); > > return ret; > > } > > BTRFS_ATTR(static_feature, supported_checksums, supported_checksums_show); > > @@ -992,7 +992,7 @@ char *btrfs_printable_features(enum btrfs_feature_set set, u64 flags) > > continue; > > > > name = btrfs_feature_attrs[set][i].kobj_attr.attr.name; > > - len += snprintf(str + len, bufsize - len, "%s%s", > > + len += scnprintf(str + len, bufsize - len, "%s%s", > > len ? "," : "", name); > > Similar, compile-time constant for number of loops, filling with strings > of bounded length. > > If the patch is a precaution, then ok, but I don't see what it's trying > to fix. Take it rather a precaution, yes. The problem is that the usage like pos += snprintf(buf + pos, len - pos, ...); to append strings is already wrong per design unless it has a return value check right after each call. It might work if the string really doesn't go over the limit; but then it makes no sense to use snprintf(), you can use the plain sprintf(). thanks, Takashi