Hello, Linux kernel built with the networking support(CONFIG_NET) is vulnerable to an information leakage flaw in the socket layer. It could occur while doing recvmsg(2), recvfrom(2) socket calls. It occurs due to improperly initialised msg_name & msg_namelen message header parameters. A user/program could use this flaw to leak information from kernel memory bytes. Upstream fix: ------------- -> https://git.kernel.org/linus/f3d3342602f8bcbf37d7c46641cb9bca7618eb1c Reference: ---------- -> https://bugzilla.redhat.com/show_bug.cgi?id=1039845 --------------------- 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. Changes since RFC: Set msg->msg_name = NULL if user specified a NULL in msg_name but had a non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't affect sendto as it would bail out earlier while trying to copy-in the address. It also more naturally reflects the logic by the callers of verify_iovec. With this change in place I could remove " if (!uaddr || msg_sys->msg_namelen == 0) msg->msg_name = NULL ". This change does not alter the user visible error logic as we ignore msg_namelen as long as msg_name is NULL. Also remove two unnecessary curly brackets in ___sys_recvmsg and change comments to netdev style. See: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f3d3342602f8bcbf37d7c46641cb9bca7618eb1c