netdev - Re: [PATCH RFC] net: rework recvmsg handler msg_name and msg

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20131119.154058.2058377571860676832.davem@davemloft.net>
Date:	Tue, 19 Nov 2013 15:40:58 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	hannes@...essinduktion.org
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH RFC] net: rework recvmsg handler msg_name and
 msg_namelen logic

From: Hannes Frederic Sowa <hannes@...essinduktion.org>
Date: Tue, 19 Nov 2013 06:27:59 +0100

> This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
> set msg_namelen to the proper size <= sizeof(struct sockaddr_storage)
> to return msg_name to the user.
> 
> This prevents numerous uninitialized memory leaks we had in the
> recvmsg handlers and makes it harder for new code to accidentally leak
> uninitialized memory.
> 
> Optimize for the case recvfrom is called with NULL as address. We don't
> need to copy the address at all, so set it to NULL before invoking the
> recvmsg handler. We can do so, because all the recvmsg handlers must
> cope with the case a plain read() is called on them. read() also sets
> msg_name to NULL.
> 
> Also document these changes in include/linux/net.h as suggested by David
> Miller.
> 
> Signed-off-by: Hannes Frederic Sowa <hannes@...essinduktion.org>

Looks good to me.

The only other invoker of ->recvmsg is vhost.c but it sets msg_name to NULL
and msg_namelen to 0 so should be fine.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html