netdev - Re: [PATCH net-next] octeontx2-pf: Treat truncation of IRQ name as an error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240501203311.GA2821784@kernel.org>
Date: Wed, 1 May 2024 21:33:11 +0100
From: Simon Horman <horms@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Sunil Goutham <sgoutham@...vell.com>,
	Geethasowjanya Akula <gakula@...vell.com>,
	Subbaraya Sundeep <sbhatta@...vell.com>,
	Hariprasad Kelam <hkelam@...vell.com>,
	Dan Carpenter <dan.carpenter@...aro.org>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] octeontx2-pf: Treat truncation of IRQ name as
 an error

On Wed, May 01, 2024 at 10:21:30PM +0200, Andrew Lunn wrote:
> On Wed, May 01, 2024 at 09:11:46PM +0100, Simon Horman wrote:
> > On Wed, May 01, 2024 at 09:46:15PM +0200, Andrew Lunn wrote:
> > > On Wed, May 01, 2024 at 07:27:09PM +0100, Simon Horman wrote:
> > > > According to GCC, the constriction of irq_name in otx2_open()
> > > > may, theoretically, be truncated.
> > > > 
> > > > This patch takes the approach of treating such a situation as an error
> > > > which it detects by making use of the return value of snprintf, which is
> > > > the total number of bytes, including the trailing '\0', that would have
> > > > been written.
> > > > +		name_len = snprintf(irq_name, NAME_SIZE, "%s-rxtx-%d",
> > > > +				    pf->netdev->name, qidx);
> > > > +		if (name_len >= NAME_SIZE) {
> > > 
> > > You say name_len includes the trailing \0. So you should be able to
> > > get NAME_SIZE bytes into an NAME_SIZE length array? So i think this
> > > can be >, not >= ?
> > 
> > Sorry, I misspoke.
> > name_len excludes the trailing \0.
> 
> The man page say:
> 
>        Upon successful return, these functions return the number of characters
>        printed (excluding the null byte used to end output to strings).
> 
>        The  functions  snprintf()  and vsnprintf() do not write more than size
>        bytes (including the terminating null byte ('\0')).  If the output  was
>        truncated  due  to  this  limit, then the return value is the number of
>        characters (excluding the terminating null byte) which would have  been
>        written  to the final string if enough space had been available.  Thus,
>        a return value of size or more means that  the  output  was  truncated.
>        (See also below under NOTES.)
> 
> Assuming the kernel snprintf() follows this, your condition is
> correct. So once the commit message is corrected, please add:
> 
> Reviewed-by: Andrew Lunn <andrew@...n.ch>

Thanks Andrew,

According to the documentation, the Kernel implementation
it matches the return value scheme described above.
For the record, the text in lib/vsprintf.c says:

 * The return value is the number of characters which would be
 * generated for the given input, excluding the trailing null,
 * as per ISO C99.  If the return is greater than or equal to
 * @size, the resulting string is truncated.

So I think the code is correct but my patch description text was wrong.
As you suggest, I'll fix that in v2.