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"? Thanks, Andrea
