On Wed, Feb 24, 2021 at 02:30:52PM +0100, Andrea Parri wrote:
On Wed, Feb 24, 2021 at 02:16:00PM +0100, Andrea Parri wrote:
On Wed, Feb 24, 2021 at 07:50:08AM -0500, Sasha Levin wrote:
From: "Andrea Parri (Microsoft)" parri.andrea@gmail.com
[ Upstream commit e99c4afbee07e9323e9191a20b24d74dbf815bdf ]
__vmbus_open() and vmbus_teardown_gpadl() do not inizialite the memory for the vmbus_channel_open_channel and the vmbus_channel_gpadl_teardown objects they allocate respectively. These objects contain padding bytes and fields that are left uninitialized and that are later sent to the host, potentially leaking guest data. Zero initialize such fields to avoid leaking sensitive information to the host.
Reported-by: Juan Vazquez juvazq@microsoft.com Signed-off-by: Andrea Parri (Microsoft) parri.andrea@gmail.com Reviewed-by: Michael Kelley mikelley@microsoft.com Link: https://lore.kernel.org/r/20201209070827.29335-2-parri.andrea@gmail.com Signed-off-by: Wei Liu wei.liu@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
Sasha - This patch is one of a group of patches where a Linux guest running on Hyper-V will start assuming that hypervisor behavior might be malicious, and guards against such behavior. Because this is a new assumption, these patches are more properly treated as new functionality rather than as bug fixes. So I would propose that we *not* bring such patches back to stable branches.
For future/similar cases: I'm wondering, is there some way to annotate a patch with "please do not bring it back"?
There's nothing explicit for the AUTOSEL stuff. A note in the changelog could work.