KVM_SEV_SEND_UPDATE_DATA and KVM_SEV_RECEIVE_UPDATE_DATA have an integer
overflow issue. Params.guest_len and offset are both 32bite wide, with a
large params.guest_len the check to confirm a page boundary is not
crossed can falsely pass:
/* Check if we are crossing the page boundary *
offset = params.guest_uaddr & (PAGE_SIZE - 1);
if ((params.guest_len + offset > PAGE_SIZE))
Add an additional check to this conditional to confirm that
params.guest_len itself is not greater than PAGE_SIZE.
The current code is can only overflow with a params.guest_len of greater
than 0xfffff000. And the FW spec says these commands fail with lengths
greater than 16KB. So this issue should not be a security concern
Fixes: 15fb7de1a7f5 ("KVM: SVM: Add KVM_SEV_RECEIVE_UPDATE_DATA command")
Fixes: d3d1af85e2c7 ("KVM: SVM: Add KVM_SEND_UPDATE_DATA command")
Reported-by: Andy Nguyen <theflow(a)google.com>
Suggested-by: Thomas Lendacky <thomas.lendacky(a)amd.com>
Signed-off-by: Peter Gonda <pgonda(a)google.com>
Cc: David Rientjes <rientjes(a)google.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Sean Christopherson <seanjc(a)google.com>
Cc: kvm(a)vger.kernel.org
Cc: stable(a)vger.kernel.org
Cc: linux-kernel(a)vger.kernel.org
---
arch/x86/kvm/svm/sev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 273cba809328..9451de72f917 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -1294,7 +1294,7 @@ static int sev_send_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
/* Check if we are crossing the page boundary */
offset = params.guest_uaddr & (PAGE_SIZE - 1);
- if ((params.guest_len + offset > PAGE_SIZE))
+ if (params.guest_len > PAGE_SIZE || (params.guest_len + offset > PAGE_SIZE))
return -EINVAL;
/* Pin guest memory */
@@ -1474,7 +1474,7 @@ static int sev_receive_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
/* Check if we are crossing the page boundary */
offset = params.guest_uaddr & (PAGE_SIZE - 1);
- if ((params.guest_len + offset > PAGE_SIZE))
+ if (params.guest_len > PAGE_SIZE || (params.guest_len + offset > PAGE_SIZE))
return -EINVAL;
hdr = psp_copy_user_blob(params.hdr_uaddr, params.hdr_len);
--
2.39.0.314.g84b9a713c41-goog
From: "Tyler Hicks" <code(a)tyhicks.com>
When attempting to build kselftests with a separate output directory, a
number of the tests fail to build.
For example,
$ rm -rf build && \
make INSTALL_HDR_PATH=build/usr headers_install > /dev/null && \
make O=build FORCE_TARGETS=1 TARGETS=breakpoints -C tools/testing/selftests > /dev/null
/usr/bin/ld: cannot open output file
build/kselftest/breakpoints/step_after_suspend_test: No such file or directory
collect2: error: ld returned 1 exit status
make[1]: *** [../lib.mk:146: build/kselftest/breakpoints/step_after_suspend_test] Error 1
make: *** [Makefile:163: all] Error 2
This has already been addressed upstream with v5.18 commit 5ad51ab618de
("selftests: set the BUILD variable to absolute path"). It is a clean
cherry pick to the linux-5.15.y and linux-5.10.y branches.
Tyler
Muhammad Usama Anjum (1):
selftests: set the BUILD variable to absolute path
tools/testing/selftests/Makefile | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
--
2.34.1
Please apply commit 105c78e12468 ("ext4: don't allow journal inode to have
encrypt flag") to the 5.15, 5.10, 5.4, and 4.19 LTS kernels, where it applies
cleanly.
It didn't get applied automatically because for the Fixes tag, I used a commit
in 5.18. However, that was the commit that exposed the problem, not the root
cause. IMO it makes sense to apply this to earlier kernels too, especially
because some people have backported the 5.18 commit.
- Eric
Greg -
Here are backports of two MPTCP patches that recently failed to apply to
the 5.15 stable tree. Two prerequisite patches are already queued in
5.15.87-rc1:
mptcp: mark ops structures as ro_after_init
mptcp: remove MPTCP 'ifdef' in TCP SYN cookies
These patches prevent IPv6 memory leaks with MPTCP.
Thanks!
Matthieu Baerts (2):
mptcp: dedicated request sock for subflow in v6
mptcp: use proper req destructor for IPv6
net/mptcp/subflow.c | 53 +++++++++++++++++++++++++++++++++++----------
1 file changed, 42 insertions(+), 11 deletions(-)
--
2.39.0
A number of AMD based Rembrandt laptops are not working properly in
suspend/resume. This has been root caused to be from the BIOS
implementation not populating code for the AMD GUID in uPEP, but
instead only the Microsoft one.
In later kernels this has been fixed by using the Microsoft GUID
instead.
The following series of patches has fixed it in newer kernels:
commit ed470febf837 ("ACPI: PM: s2idle: Add support for upcoming AMD uPEP
HID AMDI008")
commit 1a2dcab517cb ("ACPI: PM: s2idle: Use LPS0 idle if
ACPI_FADT_LOW_POWER_S0 is unset")
commit 100a57379380 ("ACPI: x86: s2idle: Move _HID handling for AMD
systems into structures")
commit fd894f05cf30 ("ACPI: x86: s2idle: If a new AMD _HID is missing
assume Rembrandt")
commit a0bc002393d4 ("ACPI: x86: s2idle: Add module parameter to prefer
Microsoft GUID")
commit d0f61e89f08d ("ACPI: x86: s2idle: Add a quirk for ASUS TUF Gaming
A17 FA707RE")
commit ddeea2c3cb88 ("ACPI: x86: s2idle: Add a quirk for ASUS ROG
Zephyrus G14")
commit 888ca9c7955e ("ACPI: x86: s2idle: Add a quirk for Lenovo Slim 7
Pro 14ARH7")
commit 631b54519e8e ("ACPI: x86: s2idle: Add a quirk for ASUSTeK
COMPUTER INC. ROG Flow X13")
commit 39f81776c680 ("ACPI: x86: s2idle: Fix a NULL pointer dereference")
commit 54bd1e548701 ("ACPI: x86: s2idle: Add another ID to
s2idle_dmi_table")
commit 577821f756cf ("ACPI: x86: s2idle: Force AMD GUID/_REV 2 on HP
Elitebook 865")
commit e6d180a35bc0 ("ACPI: x86: s2idle: Stop using AMD specific codepath
for Rembrandt+")
This is needlessly complex for 5.15.y though. To accomplish the same
effective result revert commit f0c6225531e4 ("ACPI: PM: Add support for
upcoming AMD uPEP HID AMDI007") instead.
Link: https://lore.kernel.org/stable/MN0PR12MB61015DB3D6EDBFD841157918E2F59@MN0PR…
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
---
drivers/acpi/x86/s2idle.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index e0185e841b2a..2af1ae172102 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -378,16 +378,13 @@ static int lps0_device_attach(struct acpi_device *adev,
* AMDI0006:
* - should use rev_id 0x0
* - function mask = 0x3: Should use Microsoft method
- * AMDI0007:
- * - Should use rev_id 0x2
- * - Should only use AMD method
*/
const char *hid = acpi_device_hid(adev);
- rev_id = strcmp(hid, "AMDI0007") ? 0 : 2;
+ rev_id = 0;
lps0_dsm_func_mask = validate_dsm(adev->handle,
ACPI_LPS0_DSM_UUID_AMD, rev_id, &lps0_dsm_guid);
lps0_dsm_func_mask_microsoft = validate_dsm(adev->handle,
- ACPI_LPS0_DSM_UUID_MICROSOFT, 0,
+ ACPI_LPS0_DSM_UUID_MICROSOFT, rev_id,
&lps0_dsm_guid_microsoft);
if (lps0_dsm_func_mask > 0x3 && (!strcmp(hid, "AMD0004") ||
!strcmp(hid, "AMD0005") ||
@@ -395,9 +392,6 @@ static int lps0_device_attach(struct acpi_device *adev,
lps0_dsm_func_mask = (lps0_dsm_func_mask << 1) | 0x1;
acpi_handle_debug(adev->handle, "_DSM UUID %s: Adjusted function mask: 0x%x\n",
ACPI_LPS0_DSM_UUID_AMD, lps0_dsm_func_mask);
- } else if (lps0_dsm_func_mask_microsoft > 0 && !strcmp(hid, "AMDI0007")) {
- lps0_dsm_func_mask_microsoft = -EINVAL;
- acpi_handle_debug(adev->handle, "_DSM Using AMD method\n");
}
} else {
rev_id = 1;
--
2.34.1