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 08BDE43E4A0 for ; Fri, 27 Feb 2026 20:55:05 +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=1772225706; cv=none; b=kYveC/VeqF4m+z8mpY/NJ/ohCpGGQOK+E4tRlp8jOqehg/mrZXGNU+WkGHFohnssXQrRkMl15ZZ8NyKu29mX0XSj0u4vhTFBxPjwySmRDyZwM8YgLUhdb0ohaGBKCiXihm0IHXxDBHR7SSiDWtP5Y4ELeCru40dH17loabVzrEY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772225706; c=relaxed/simple; bh=kOsxhCKBFM0oK4kirFlaQc2LHYutBKI/m+s19lRmEIk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SzYO087Gl5hq0qtpuCvaKHqgviLqQ91/ytaCouENR6J4nJEQd9kwdBQjOyjGFM5mPAVM9jIopwkdF6YawdQVrT/iKEg4h0IOWGRZidaRs9XYFO8Hu0qg7je1wLkV9De9aeof7p0FJ4h7kv9nOKPNhsYVAn92W1t9d0bTbUqRFbM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=KjbZz4Oc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="KjbZz4Oc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 480C8C116C6; Fri, 27 Feb 2026 20:55:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1772225705; bh=kOsxhCKBFM0oK4kirFlaQc2LHYutBKI/m+s19lRmEIk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KjbZz4OcBu5ZeTE00qYj+aEJD7jmyVN9qZ3RZxw8gKDPA/bb7j/cs3le6oG7s+Zcb teEejvl/zKo3Pugohyn9Wt6PNv7mLiBoYqb2EzgZA2lRCVWlTbjfw3OGhfNX0m8deZ EzCqfF+GA9kOBiwz2xD3tA9vJy8K2kWW/VmfCZII= Date: Fri, 27 Feb 2026 15:54:54 -0500 From: "gregkh@linuxfoundation.org" To: Dev Doshi Cc: "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] misc: altera-stapl: fix format string vulnerability in OP_PRNT handler Message-ID: <2026022714-object-magnesium-3da9@gregkh> References: Precedence: bulk X-Mailing-List: linux-kernel@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: On Fri, Feb 27, 2026 at 02:30:46PM +0000, Dev Doshi wrote: > The OP_PRNT opcode handler in the STAPL bytecode interpreter passes > msg_buff directly as the format string argument to printk(): > > printk(msg_buff, "\n"); > > msg_buff is constructed from STAPL bytecode execution through the > OP_PINT, OP_PCHR, and OP_PSTR opcodes, which append integers, > characters, and strings from the bytecode's string table. If the > STAPL/JAM file contains format specifiers (e.g. %p, %x, %n) in its > string data, these will be interpreted by printk(), potentially > leaking kernel stack memory or causing undefined behavior. > > The second argument "\n" was clearly intended to append a newline > after the message, not to serve as a format argument. The programmer > intended the equivalent of printf("%s\n", msg_buff). > > Fix by using a proper format string with pr_info(). > > Assisted-by: GitHub Copilot (Claude claude-4-opus) > Signed-off-by: Dev Doshi > > --- > drivers/misc/altera-stapl/altera.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/misc/altera-stapl/altera.c b/drivers/misc/altera-stapl/altera.c > index 4fa6c9062..b9a5a3ea7 100644 > --- a/drivers/misc/altera-stapl/altera.c > +++ b/drivers/misc/altera-stapl/altera.c > @@ -700,7 +700,7 @@ static int altera_execute(struct altera_state *astate, > case OP_PRNT: > /* PRINT finish */ > if (debug) > - printk(msg_buff, "\n"); > + pr_info("%s\n", msg_buff); Close, but not quite :) pr_info() has a different output format than printk() does. Or it can, depending on the calling file. Do you have this hardware to test that this really looks the same? And this data is coming from hardware, not userspace, right? I think that should be written as: case OP_PRNG: /* PRINT finish */ dprintk("%s\n", msg_buff); making it one less line overall, and "fixing" the potential issue at the same time, a win for everyone :) This whole file is really crazy, and given the amount of noise is is printing out to the kernel log, I can't imagine anyone is actually using it in this manner as it's just a lot of fpga junk. thanks, greg k-h