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@xxxxxxxxx>
>
> [ 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@xxxxxxxxxxxxx>
> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@xxxxxxxxx>
> Reviewed-by: Michael Kelley <mikelley@xxxxxxxxxxxxx>
> Link: https://lore.kernel.org/r/20201209070827.29335-2-parri.andrea@xxxxxxxxx
> Signed-off-by: Wei Liu <wei.liu@xxxxxxxxxx>
> Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
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.
--
Thanks,
Sasha
