Message ID | 20231130105459.3208986-4-lee@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp295881vqy; Thu, 30 Nov 2023 02:55:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IGcCzWZ5vMhe97Y35O1r/hIOPzxCS9qHowhHg27tEH2v+0t4QRt4zIUUDlNr9mSrcHkLKz7 X-Received: by 2002:a05:6871:878a:b0:1fa:bd0d:34a9 with SMTP id td10-20020a056871878a00b001fabd0d34a9mr2820301oab.44.1701341731811; Thu, 30 Nov 2023 02:55:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701341731; cv=none; d=google.com; s=arc-20160816; b=Dd7qrfn2M0Nn/jrvtZp7kCfqlyoh2PrTQfQANNJwo9Fz6qu0+2Ekz0kyMABfHGQQMO 654/RbnMZBJXKukOET0TXpLplrbETfVXGXauylG6GznPzX5ZFz4WUpPgkZayWHlQFbHf knGtQJZNW/WlyZzzo9SBEi2kaAxvnPzH9oGfiXou5I3t8y+G53Q6VQqKGbMO5miHhStB MNojZuGIgYRBLPig8g23oOy6m7gYJOT/wo5cR/ACk/FlA1i/17vBLuskOL1yLO/OhADe Fp9l58WUBJ8m40wuxAUgsOBiaLj6+wkQIDLZuitublIOWU6g6X11yHkD0QFx6r3o2FIE 5Y4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=erMdf6qSi/CsbMklKmqwkvI8eHPHmzna5cn0APZzXfU=; fh=2PoOdWNVrOZRRAvHRfhr0U8Dj+yqCU2JYFKzeVg1R0Q=; b=b2KqWm6/rS5sRbk8OPkwqr+ZAlpFGi5HgGrhwZJJEM5zuBJd19xkP7Hg2EfQvsKS0F WK4EamFO15QWfLfhbVDBRwru/YS8R4rqFbXPVDlf/q9IPD2kl2cwVpzXiek0to/BsBq6 oKJGSml/aoxjMEFzoXioUpOftPDRBW4ms3e5jdpqwixHkuuMR8zTwIFUldGw0R8GOfQK O6vgN3fcviv4r1NFN1Li81cSwyXigYCUL8mry+HA2rlkwzHCGcRNTysm4Mu9C14fPywK Uw6Tu6MV5BSu2DzEzCedvfHdRimFXAAr7LXCo0DvBz7/6A7G1uXvkhe6pBkIi9AtHoAY ZzMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ODfZqyvs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id y21-20020a656c15000000b005c278e32054si1110803pgu.677.2023.11.30.02.55.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Nov 2023 02:55:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ODfZqyvs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id C1C5F8039ED4; Thu, 30 Nov 2023 02:55:28 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345129AbjK3KzQ (ORCPT <rfc822;ruipengqi7@gmail.com> + 99 others); Thu, 30 Nov 2023 05:55:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345051AbjK3KzL (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 30 Nov 2023 05:55:11 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8DB8910DB for <linux-kernel@vger.kernel.org>; Thu, 30 Nov 2023 02:55:17 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83373C433C8; Thu, 30 Nov 2023 10:55:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701341717; bh=I6SFA46IuAEaiFe3yLVvcqPKp8gUZZ0H2L9FiYb6dRg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ODfZqyvsllTcjm4eCiviYTFS9NmmCY4xpKqBkTrGWQ11pzC3k/u7EJKu7gnow+HLD W85Lbo+2NpiarQYU15HIEFe4/VpooV82LNHT4T9ODoCqfOttbCST6L/OSP16CMi47P D+sk//y9F+L+Inr5RB/ovdaJyIlJfU5yN6DUOz88/QUD3IIxNIhG/5yX88mlmgIjOg I2myg9l9zz2tuaunyntzJ4TYi8zqlQxUW13hi8gVKk1P49u90TmebAhmgDvRiKKX4l +1tDauDAmREIua845WZ7QZYEAtWrm39g+qxKLVH9XDYZyfhYX7641iMDAl8yFp4ky6 bMvVtb+cWhNlA== From: Lee Jones <lee@kernel.org> To: lee@kernel.org Cc: linux-kernel@vger.kernel.org, Linus Walleij <linus.walleij@linaro.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Yuan-Hsin Chen <yhchen@faraday-tech.com>, Feng-Hsin Chiang <john453@faraday-tech.com>, Po-Yu Chuang <ratbert.chuang@gmail.com>, linux-usb@vger.kernel.org Subject: [PATCH 3/5] usb: fotg210-hcd: Replace snprintf() with the safer scnprintf() variant Date: Thu, 30 Nov 2023 10:54:37 +0000 Message-ID: <20231130105459.3208986-4-lee@kernel.org> X-Mailer: git-send-email 2.43.0.rc1.413.gea7ed67945-goog In-Reply-To: <20231130105459.3208986-1-lee@kernel.org> References: <20231130105459.3208986-1-lee@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Thu, 30 Nov 2023 02:55:29 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783986107455085894 X-GMAIL-MSGID: 1783986107455085894 |
Series |
usb: Replace {v}snprintf() variants with safer alternatives
|
|
Commit Message
Lee Jones
Nov. 30, 2023, 10:54 a.m. UTC
There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array. However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it. This misunderstanding has led to buffer-overruns
in the past. It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases). So let's
do that.
The uses in this file both seem to assume that data *has been* written!
Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Yuan-Hsin Chen <yhchen@faraday-tech.com>
Cc: Feng-Hsin Chiang <john453@faraday-tech.com>
Cc: Po-Yu Chuang <ratbert.chuang@gmail.com>
Cc: linux-usb@vger.kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/usb/fotg210/fotg210-hcd.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
Comments
From: Lee Jones > Sent: 30 November 2023 10:55 > > There is a general misunderstanding amongst engineers that {v}snprintf() > returns the length of the data *actually* encoded into the destination > array. However, as per the C99 standard {v}snprintf() really returns > the length of the data that *would have been* written if there were > enough space for it. This misunderstanding has led to buffer-overruns > in the past. It's generally considered safer to use the {v}scnprintf() > variants in their place (or even sprintf() in simple cases). So let's > do that. > > The uses in this file both seem to assume that data *has been* written! ... > - temp = snprintf(next, size, > - "\n\t%p%c%s len=%d %08x urb %p", > - td, mark, ({ char *tmp; ... > - if (size < temp) > - temp = size; That is actually a bug - even though it is trying to be correct. The trailing '\0' that snprintf() adds (unless you are using the M$ one) will end up in the buffer. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Thu, Nov 30, 2023 at 11:55 AM Lee Jones <lee@kernel.org> wrote: > There is a general misunderstanding amongst engineers that {v}snprintf() > returns the length of the data *actually* encoded into the destination > array. However, as per the C99 standard {v}snprintf() really returns > the length of the data that *would have been* written if there were > enough space for it. This misunderstanding has led to buffer-overruns > in the past. It's generally considered safer to use the {v}scnprintf() > variants in their place (or even sprintf() in simple cases). So let's > do that. > > The uses in this file both seem to assume that data *has been* written! > > Link: https://lwn.net/Articles/69419/ > Link: https://github.com/KSPP/linux/issues/105 > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Yuan-Hsin Chen <yhchen@faraday-tech.com> > Cc: Feng-Hsin Chiang <john453@faraday-tech.com> > Cc: Po-Yu Chuang <ratbert.chuang@gmail.com> > Cc: linux-usb@vger.kernel.org > Signed-off-by: Lee Jones <lee@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Thanks for doing this Lee! And as David points out it is even a bug fix at the same time. Yours, Linus Walleij
diff --git a/drivers/usb/fotg210/fotg210-hcd.c b/drivers/usb/fotg210/fotg210-hcd.c index 929106c16b29b..b2f8b53cc8ef5 100644 --- a/drivers/usb/fotg210/fotg210-hcd.c +++ b/drivers/usb/fotg210/fotg210-hcd.c @@ -404,9 +404,9 @@ static void qh_lines(struct fotg210_hcd *fotg210, struct fotg210_qh *qh, else if (td->hw_alt_next != list_end) mark = '/'; } - temp = snprintf(next, size, - "\n\t%p%c%s len=%d %08x urb %p", - td, mark, ({ char *tmp; + temp = scnprintf(next, size, + "\n\t%p%c%s len=%d %08x urb %p", + td, mark, ({ char *tmp; switch ((scratch>>8)&0x03) { case 0: tmp = "out"; @@ -424,17 +424,13 @@ static void qh_lines(struct fotg210_hcd *fotg210, struct fotg210_qh *qh, (scratch >> 16) & 0x7fff, scratch, td->urb); - if (size < temp) - temp = size; size -= temp; next += temp; if (temp == size) goto done; } - temp = snprintf(next, size, "\n"); - if (size < temp) - temp = size; + temp = scnprintf(next, size, "\n"); size -= temp; next += temp;