Received-SPF: pass (google.com: domain of linux-kernel+bounces-93277-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Content-Type: text/plain; charset="utf-8"
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH v3] sock: Use unsafe_memcpy() for sock_copy()
From: patchwork-bot+netdevbpf@kernel.org
Message-Id: 
 <170969462846.24513.2351243182107643239.git-patchwork-notify@kernel.org>
Date: Wed, 06 Mar 2024 03:10:28 +0000
References: <20240304212928.make.772-kees@kernel.org>
In-Reply-To: <20240304212928.make.772-kees@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: kuba@kernel.org, davem@davemloft.net, edumazet@google.com,
 pabeni@redhat.com, netdev@vger.kernel.org, dsahern@kernel.org,
 kuniyu@amazon.com, wuyun.abel@bytedance.com, leitao@debian.org,
 alexander@mihalicyn.com, dhowells@redhat.com, linux-kernel@vger.kernel.org,
 linux-hardening@vger.kernel.org

Hello:

This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Mon,  4 Mar 2024 13:29:31 -0800 you wrote:
> While testing for places where zero-sized destinations were still showing
> up in the kernel, sock_copy() and inet_reqsk_clone() were found, which
> are using very specific memcpy() offsets for both avoiding a portion of
> struct sock, and copying beyond the end of it (since struct sock is really
> just a common header before the protocol-specific allocation). Instead
> of trying to unravel this historical lack of container_of(), just switch
> to unsafe_memcpy(), since that's effectively what was happening already
> (memcpy() wasn't checking 0-sized destinations while the code base was
> being converted away from fake flexible arrays).
> 
> [...]

Here is the summary with links:
  - [v3] sock: Use unsafe_memcpy() for sock_copy()
    https://git.kernel.org/netdev/net-next/c/ff73f8344e58

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html