Hello Greg,
On 10/9/24 21:33, Greg KH wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Wed, Oct 09, 2024 at 04:16:26PM +0800, Xiangyu Chen wrote:
From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
In CoCo VMs it is possible for the untrusted host to cause
set_memory_encrypted() or set_memory_decrypted() to fail such that an
error is returned and the resulting memory is shared. Callers need to
take care to handle these errors to avoid returning decrypted (shared)
memory to the page allocator, which could lead to functional or security
issues.
VMBus code could free decrypted pages if set_memory_encrypted()/decrypted()
fails. Leak the pages if this happens.
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
Signed-off-by: Michael Kelley <mhklinux@xxxxxxxxxxx>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx>
Acked-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>
Link: https://lore.kernel.org/r/20240311161558.1310-2-mhklinux@xxxxxxxxxxx
Signed-off-by: Wei Liu <wei.liu@xxxxxxxxxx>
Message-ID: <20240311161558.1310-2-mhklinux@xxxxxxxxxxx>
[Xiangyu: Modified to apply on 6.1.y]
Signed-off-by: Xiangyu Chen <xiangyu.chen@xxxxxxxxxxxxx>
---
drivers/hv/connection.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
Are you sure? This is _VERY_ different from what you suggested for
5.15.y and what is in mainline. Also, you didn't show the git id for
the upstream commit.
This commit is a fix for CVE-2024-36913, currently, if we fully apply
the commit, we have to backport the
following commits from upstream:
a5ddb745 : Drivers: hv: vmbus: Remove second mapping of VMBus monitor pages
d786e00d : drivers: hv, hyperv_fb: Untangle and refactor Hyper-V panic
notifiers
9c318a1d : Drivers: hv: move panic report code from vmbus to hv early
init code
a6fe0438 : Drivers: hv: Change hv_free_hyperv_page() to take void * argument
03f5a999 : Drivers: hv: vmbus: Leak pages if set_memory_encrypted() fails
Some of them are features, it might not be merged to current stable
branch, so another solution
is modify the connect.c by manual.
From the upstream commit 03f5a999(Drivers: hv: vmbus: Leak pages if
set_memory_encrypted() fails) we can see that
the commit aim to check set_memory_decrypted() result, if fails, the
encryption of memory state is unknown, so leak the
memory.
The commit modified 2 functions, vmbus_connect() and vmbus_disconnect().
In vmbus_connect(), when set_memory_decrypted() fails, marking
vmbus_connection.monitor_pages[0]/[1] to NULL.
In vmbus_disconnect(), checking the monitor_pages[0]/[1] is valid, and
checking set_memory_encrypted() status, if fails, free and
leak it.
On current v6.1 branch, vmbus_disconnect() will free those memory
whatever set_memory_encrypted() is success or fails, so we can just
add a monitor_pages valid checking in it.
Could you please give a suggestion that which solution is following the
stable-branch rule, I will resend a V2 patch, thanks.
Br,
Xiangyu
Please work to figure this out and resend working versions for ALL
affected branches as new patches.
thanks,
greg k-h
