From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 29C5319E819; Sun, 26 Apr 2026 08:46:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777193206; cv=none; b=RXdxXmkQlesL23PRTJy7oPak+S5WhqfOU+2P6d+1o7sgQUsPvXr31wbArvBz5nYr4y8mWFJYbe05fLVPp4juwTEark+L6sf1S9qfE6RyRWw042UQZlOmv8lCRmz7DVC7Xu7lluQqxREPd3ibkseq/p2BNA/XRTVChVOi23kyqBM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777193206; c=relaxed/simple; bh=7Xam0TgLCaVeJI5K19pRX9TessTTUSIm68O5xYtzmW8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ox7wHOJPMgXanL7YpZlMnaLBLW3qeJrre8j2lf4Zg4k9MGEdvMnTx+HyxIkkvsLEElp9JAweUGGRrStVknV+L4jwho4dcrzr+/nMnZZhhvP3dQRiDQQ+xNLkRjikWgA/ZXXA4CcTB2jY/X5bnC8Wqyz3OTQCj2vlzU9T7Ao+9wM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a/iwhKZF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a/iwhKZF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E97BC2BCAF; Sun, 26 Apr 2026 08:46:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777193205; bh=7Xam0TgLCaVeJI5K19pRX9TessTTUSIm68O5xYtzmW8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=a/iwhKZF+IiRBtgzrm1kBwmA2q+eMMYyib2dF2RQeDPWEzxZiYl4b6BA3u4SO1NtZ rAplh9dTlswNesN6XmJMV7NL0yvmX15cBpwbO3XJC9i3YFOYcGXyY+0a2+i7KPzxVH khOSDUzt3syoq+X6RphKFDbd3k99nhin07WM9ytBvp3tzw5NzDpZSTkD7SIb6yQ8GL Lwmy4J8uOi3LSuFMf1pmHm3OWGNcugJUHCEJ7ZoC+Rx6GRe39Wm8jNlbwN+ZyM0IW+ R9pngtAzx0MJ2xJy+zz6Zyt0bBCvhP3b1mXNyOwbPQck0fwUtstLJdj+C+8qycYpDa 4fBlFhLaRhYYw== Date: Sun, 26 Apr 2026 09:46:40 +0100 From: Simon Horman To: Breno Leitao Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Keiichi Kii , Satyam Sharma , Andrew Morton , Matthew Wood , asantostc@gmail.com, gustavold@gmail.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH net 1/3] netconsole: return count instead of strnlen(buf, count) from store callbacks Message-ID: <20260426084640.GN900403@horms.kernel.org> References: <20260423-netconsole_ai_fixes-v1-0-92b8b7de9a2c@debian.org> <20260423-netconsole_ai_fixes-v1-1-92b8b7de9a2c@debian.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260423-netconsole_ai_fixes-v1-1-92b8b7de9a2c@debian.org> On Thu, Apr 23, 2026 at 02:41:15AM -0700, Breno Leitao wrote: > Several configfs store callbacks in netconsole end with: > > ret = strnlen(buf, count); > > This under-reports the number of bytes consumed when the input > contains an embedded NUL within count, telling the VFS that fewer > bytes were written than userspace actually handed in. A conformant > partial-write loop would then retry the trailing bytes against a > callback that has already accepted them. > > Every other configfs driver in the tree returns count directly from > its store callbacks once parsing has succeeded, including > drivers/nvme/target/configfs.c, drivers/gpio/gpio-sim.c, > drivers/most/configfs.c, drivers/block/null_blk/main.c, > drivers/pci/endpoint/pci-ep-cfs.c, and the rest of the configfs > users. netconsole was the outlier (along with > drivers/infiniband/core/cma_configfs.c, which has the same latent > issue). > > Align netconsole with the rest of the configfs ecosystem: return > count once the parser/validator has accepted the input. The numeric > and boolean parsers (kstrtobool, kstrtou16, mac_pton, > netpoll_parse_ip_addr) have already validated the meaningful prefix; > any trailing bytes are padding and should simply be reported as > consumed. > > Fixes: 0bcc1816188e ("[NET] netconsole: Support dynamic reconfiguration using configfs") > Signed-off-by: Breno Leitao Reviewed-by: Simon Horman FTR: Sashiko has provided an AI generated review of this patch. Like it's review of patch 3/3 - which I forwarded separately - it flags that trim_newline() may perform an OOB access if passed an empty string. But this is not correct because trim_newline() correctly handles this case.