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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4D2FCCF8854 for ; Fri, 4 Oct 2024 18:47:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=IrTg0kaopkLeKlPu7sTXTEx4d7ujCV3P+a2ZN/l+SlA=; b=Wxc9PJdUQ9Rt1a2aob/RrnJSPP 71wip5ULdcU4J2SwhUz3v9MJHmqR6MOgRMOwVoERMPItzNRCiNROF/u0y3uG7x83xSkN5hrYIWewB aCq37JzbikeYmGt4Q7dNZLxLoYtjxIYN07C+qPp5C88nBHQ8Y0VNjWQ96ApCbyUvJSxv6XW+ftNr4 sqhMBI/gYQtmrzN8xAqHJ4/8is9SpDblOxsrbEKxN/XfIJyqc0MDVhKvEA/6XrwCSn04E4DlI/km9 TgZj4IYRYUf9r6SjsgwrPvw3QzYEB5GfO7Tzu66vWlOPgIAV1D/MjqAj7T6Ne1RdIWpuDAZKmj8ep LihKM+Cg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1swnKw-0000000DlN9-3Z9O; Fri, 04 Oct 2024 18:47:34 +0000 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1swnJf-0000000DlAc-2GOJ for linux-arm-kernel@lists.infradead.org; Fri, 04 Oct 2024 18:46:16 +0000 Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-2e078d28fe9so1807344a91.2 for ; Fri, 04 Oct 2024 11:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728067574; x=1728672374; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=IrTg0kaopkLeKlPu7sTXTEx4d7ujCV3P+a2ZN/l+SlA=; b=k7WxEavE0qwDva8p0j2uHQcWZXoSGCNRosrnO8nIMhpvtyf7qONaMmP+3GcJgeXLQ1 iIOim6s502GxJPSsLH31nbtrBqOgcJmBKsYVAY4OAi4ysUReEjpCaiG5kP+rIeWbAIOJ aenj2ARBlkM0Ea52WwqEUVNGtsiMFrKqsV1kFn1gnGLXq6/favl4I43YhFGbr3g3tvEz j4zj7ZE2m2ObtsFkGIP7ihGDyUY7IZwaIyW8thU9B6d5VaL1AFkdKyN6RHE9S7scKisY +IpaarRjDRIbDRBIZtWQACwulUjSiDXbjlUuAYa/1nAhHHRSsmOw7G9Ar1zY/ViBqhuT 0/Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728067574; x=1728672374; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IrTg0kaopkLeKlPu7sTXTEx4d7ujCV3P+a2ZN/l+SlA=; b=uomxz2ylb07Gg/o1FxfN1AiJHc1mn8AXE9RGk/NN6Dx+9DiWmtOOG/JSeyAaShxFcR R0rs3Bs1A9wpVGeTPcWXJMMUJxivenZ3m7pK13zIBy9dCf0B4UYdtLgb7goAC2dvlCcQ skKDp9EOt18iPyAYMo1zHwzLvTCztu1fFh7HeF5BKe4EoTfAmya/8NN8Evg1i+MbtHIa Q/HTzozPTg28DVYS6xLB8jj0+XKnx7Sc17q4U6azxMidnOWCNt8Zy8km6Ux9mNcZapOD ooQqDvymUw52IXx4geSMJQEa8jowYzzstyv7Yu1h/I5qaqznqHLBwzRCcrA3RXWVc+tG YfMA== X-Gm-Message-State: AOJu0YzjluF7P6PAPDcXyLEldkVW78uD9pIbR6U7L9QLkY0L5DIMLzog gFTKfm9r9OZGSYwuYosaDh8B54X6Gj1ASqnThj0n1IxPHh0t1BrP5027rg== X-Google-Smtp-Source: AGHT+IHVr5A5Oa1U5sfqmIduA2f6Mb43CYYv1LjnCC6EfjKhOV38SAV9u4aOc+k7yBHEeaIqQFUr4Q== X-Received: by 2002:a17:90b:80e:b0:2c9:5c67:dd9e with SMTP id 98e67ed59e1d1-2e1e626dc29mr4752757a91.19.1728067574318; Fri, 04 Oct 2024 11:46:14 -0700 (PDT) Received: from mail.google.com (125-239-144-11-fibre.sparkbb.co.nz. [125.239.144.11]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2e1e83ca28fsm2007631a91.7.2024.10.04.11.46.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Oct 2024 11:46:13 -0700 (PDT) Date: Sat, 5 Oct 2024 07:46:08 +1300 From: Paulo Miguel Almeida To: "Russell King (Oracle)" Cc: linux-arm-kernel@lists.infradead.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] [next] ARM: Replace snprintf() with the safer scnprintf() variant Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241004_114615_598525_DFE143F8 X-CRM114-Status: GOOD ( 19.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 04, 2024 at 10:09:50AM +0100, Russell King (Oracle) wrote: > On Fri, Oct 04, 2024 at 03:59:30PM +1300, Paulo Miguel Almeida 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, basically, it's unsafe to use the result of (v)snprintf(). So why > do we need to change locations that do not use the result? > > This patch is mere noise. Sorry, I won't be applying it. > Thanks for taking the time to review this patch. My take on this is that it boils down to nipping it in the bud proactively, so if the result starts being used, no one has to remember to change from scprint() to scnprint(), which can be easy to miss. There have been other instances where the result wasn't being used, yet the patch was still accepted [1] — should that help sway your opinion. :) I understand that each maintainer has different approaches to what they deem trivial patches, but I hope you reconsider accepting this one. That said, if there is no utilization of snprint(), we could eventually deprecate or remove the function altogether. [1] https://lore.kernel.org/lkml/20231213164246.1021885-11-lee@kernel.org/ Paulo A.