netdev - Re: [PATCH] net: Save and restore msg_namelen in sock

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]

Date: Tue, 02 Jan 2024 20:38:56 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Marc Dionne <marc.dionne@...istor.com>, 
 netdev@...r.kernel.org, 
 Jordan Rife <jrife@...gle.com>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Paolo Abeni <pabeni@...hat.com>, 
 Eric Dumazet <edumazet@...gle.com>, 
 "David S. Miller" <davem@...emloft.net>
Cc: Willem de Bruijn <willemb@...gle.com>, 
 Simon Horman <horms@...nel.org>, 
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: Save and restore msg_namelen in sock_sendmsg

Marc Dionne wrote:
> Commit 86a7e0b69bd5 ("net: prevent rewrite of msg_name in
> sock_sendmsg()") made sock_sendmsg save the incoming msg_name pointer
> and restore it before returning, to insulate the caller against
> msg_name being changed by the called code.  If the address length
> was also changed however, we may return with an inconsistent structure
> where the length doesn't match the address, and attempts to reuse it may
> lead to lost packets.
> 
> For example, a kernel that doesn't have commit 1c5950fc6fe9 ("udp6: fix
> potential access to stale information") will replace a v4 mapped address
> with its ipv4 equivalent, and shorten namelen accordingly from 28 to 16.
> If the caller attempts to reuse the resulting msg structure, it will have
> the original ipv6 (v4 mapped) address but an incorrect v4 length.
> 
> Fixes: 86a7e0b69bd5 ("net: prevent rewrite of msg_name in sock_sendmsg()")
> Signed-off-by: Marc Dionne <marc.dionne@...istor.com>

Reviewed-by: Willem de Bruijn <willemb@...gle.com>