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: <20240802094219.GB2503418@kernel.org>
Date: Fri, 2 Aug 2024 10:42:19 +0100
From: Simon Horman <horms@...nel.org>
To: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Cc: Jon Maloy <jmaloy@...hat.com>, Ying Xue <ying.xue@...driver.com>,
	Per Liden <per.liden@...pam.ericsson.com>, netdev@...r.kernel.org,
	tipc-discussion@...ts.sourceforge.net
Subject: Re: [PATCH net-next v2] tipc: guard against string buffer overrun

On Thu, Aug 01, 2024 at 07:35:37PM +0100, Simon Horman wrote:
> Smatch reports that copying media_name and if_name to name_parts may
> overwrite the destination.
> 
>  .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16)
>  .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16)
> 
> This does seem to be the case so guard against this possibility by using
> strscpy() and failing if truncation occurs.
> 
> Introduced by commit b97bf3fd8f6a ("[TIPC] Initial merge")
> 
> Compile tested only.
> 
> Reviewed-by: Jakub Kicinski <kuba@...nel.org>
> Signed-off-by: Simon Horman <horms@...nel.org>
> ---
> I am not marking this as a fix for net as I am not aware of this
> actually breaking anything in practice. Thus, at this point I consider
> it more of a clean-up than a bug fix.
> ---
> Changes in v2:
> - Correct formatting and typo in subject (Thanks Jakub)
>   + The formatting problem was caused by tooling (b4)
>     so I reworded the subject as a work-around

Just to clarify. The formatting issue I was referring, is a double space
in the subject [1], which seems to of occurred due to the subject being
linewrapped and then unlinewrapped. However, in the light of a new day,
it is not at all clear to me that b4 is the cause of the problem.
So sorry for pointing my finger at it.

[1] https://lore.kernel.org/netdev/20240731182356.01a4c2b8@kernel.org/

> - Added Acked-by tag from Jakub
> - Link to v1: https://lore.kernel.org/r/20240731-tipic-overrun-v1-1-32ce5098c3e9@kernel.org

...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ