This is a note to let you know that I've just added the patch titled
KVM: s390: prevent buffer overrun on memory hotplug during migration
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-s390-prevent-buffer-overrun-on-memory-hotplug-during-migration.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c2cf265d860882b51a200e4a7553c17827f2b730 Mon Sep 17 00:00:00 2001
From: Christian Borntraeger <borntraeger(a)de.ibm.com>
Date: Thu, 21 Dec 2017 09:18:22 +0100
Subject: KVM: s390: prevent buffer overrun on memory hotplug during migration
From: Christian Borntraeger <borntraeger(a)de.ibm.com>
commit c2cf265d860882b51a200e4a7553c17827f2b730 upstream.
We must not go beyond the pre-allocated buffer. This can happen when
a new memory slot is added during migration.
Reported-by: David Hildenbrand <david(a)redhat.com>
Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com>
Fixes: 190df4a212a7 (KVM: s390: CMMA tracking, ESSA emulation, migration mode)
Reviewed-by: Cornelia Huck <cohuck(a)redhat.com>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/kvm/priv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/s390/kvm/priv.c
+++ b/arch/s390/kvm/priv.c
@@ -1009,7 +1009,7 @@ static inline int do_essa(struct kvm_vcp
cbrlo[entries] = gfn << PAGE_SHIFT;
}
- if (orc) {
+ if (orc && gfn < ms->bitmap_size) {
/* increment only if we are really flipping the bit to 1 */
if (!test_and_set_bit(gfn, ms->pgste_bitmap))
atomic64_inc(&ms->dirty_pages);
Patches currently in stable-queue which might be from borntraeger(a)de.ibm.com are
queue-4.14/kvm-s390-prevent-buffer-overrun-on-memory-hotplug-during-migration.patch
queue-4.14/kvm-s390-fix-cmma-migration-for-multiple-memory-slots.patch
This is a note to let you know that I've just added the patch titled
KVM: s390: fix cmma migration for multiple memory slots
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-s390-fix-cmma-migration-for-multiple-memory-slots.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 32aa144fc32abfcbf7140f473dfbd94c5b9b4105 Mon Sep 17 00:00:00 2001
From: Christian Borntraeger <borntraeger(a)de.ibm.com>
Date: Fri, 15 Dec 2017 13:14:31 +0100
Subject: KVM: s390: fix cmma migration for multiple memory slots
From: Christian Borntraeger <borntraeger(a)de.ibm.com>
commit 32aa144fc32abfcbf7140f473dfbd94c5b9b4105 upstream.
When multiple memory slots are present the cmma migration code
does not allocate enough memory for the bitmap. The memory slots
are sorted in reverse order, so we must use gfn and size of
slot[0] instead of the last one.
Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda(a)linux.vnet.ibm.com>
Fixes: 190df4a212a7 (KVM: s390: CMMA tracking, ESSA emulation, migration mode)
Reviewed-by: Cornelia Huck <cohuck(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/kvm/kvm-s390.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -794,11 +794,12 @@ static int kvm_s390_vm_start_migration(s
if (kvm->arch.use_cmma) {
/*
- * Get the last slot. They should be sorted by base_gfn, so the
- * last slot is also the one at the end of the address space.
- * We have verified above that at least one slot is present.
+ * Get the first slot. They are reverse sorted by base_gfn, so
+ * the first slot is also the one at the end of the address
+ * space. We have verified above that at least one slot is
+ * present.
*/
- ms = slots->memslots + slots->used_slots - 1;
+ ms = slots->memslots;
/* round up so we only use full longs */
ram_pages = roundup(ms->base_gfn + ms->npages, BITS_PER_LONG);
/* allocate enough bytes to store all the bits */
Patches currently in stable-queue which might be from borntraeger(a)de.ibm.com are
queue-4.14/kvm-s390-prevent-buffer-overrun-on-memory-hotplug-during-migration.patch
queue-4.14/kvm-s390-fix-cmma-migration-for-multiple-memory-slots.patch
This is a note to let you know that I've just added the patch titled
apparmor: fix regression in mount mediation when feature set is pinned
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
apparmor-fix-regression-in-mount-mediation-when-feature-set-is-pinned.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5b9f57cf47b87f07210875d6a24776b4496b818d Mon Sep 17 00:00:00 2001
From: John Johansen <john.johansen(a)canonical.com>
Date: Thu, 7 Dec 2017 00:28:27 -0800
Subject: apparmor: fix regression in mount mediation when feature set is pinned
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: John Johansen <john.johansen(a)canonical.com>
commit 5b9f57cf47b87f07210875d6a24776b4496b818d upstream.
When the mount code was refactored for Labels it was not correctly
updated to check whether policy supported mediation of the mount
class. This causes a regression when the kernel feature set is
reported as supporting mount and policy is pinned to a feature set
that does not support mount mediation.
BugLink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882697#41
Fixes: 2ea3ffb7782a ("apparmor: add mount mediation")
Reported-by: Fabian Grünbichler <f.gruenbichler(a)proxmox.com>
Signed-off-by: John Johansen <john.johansen(a)canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/apparmor/mount.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/security/apparmor/mount.c
+++ b/security/apparmor/mount.c
@@ -330,6 +330,9 @@ static int match_mnt_path_str(struct aa_
AA_BUG(!mntpath);
AA_BUG(!buffer);
+ if (!PROFILE_MEDIATES(profile, AA_CLASS_MOUNT))
+ return 0;
+
error = aa_path_name(mntpath, path_flags(profile, mntpath), buffer,
&mntpnt, &info, profile->disconnected);
if (error)
@@ -381,6 +384,9 @@ static int match_mnt(struct aa_profile *
AA_BUG(!profile);
AA_BUG(devpath && !devbuffer);
+ if (!PROFILE_MEDIATES(profile, AA_CLASS_MOUNT))
+ return 0;
+
if (devpath) {
error = aa_path_name(devpath, path_flags(profile, devpath),
devbuffer, &devname, &info,
@@ -559,6 +565,9 @@ static int profile_umount(struct aa_prof
AA_BUG(!profile);
AA_BUG(!path);
+ if (!PROFILE_MEDIATES(profile, AA_CLASS_MOUNT))
+ return 0;
+
error = aa_path_name(path, path_flags(profile, path), buffer, &name,
&info, profile->disconnected);
if (error)
@@ -614,7 +623,8 @@ static struct aa_label *build_pivotroot(
AA_BUG(!new_path);
AA_BUG(!old_path);
- if (profile_unconfined(profile))
+ if (profile_unconfined(profile) ||
+ !PROFILE_MEDIATES(profile, AA_CLASS_MOUNT))
return aa_get_newest_label(&profile->label);
error = aa_path_name(old_path, path_flags(profile, old_path),
Patches currently in stable-queue which might be from john.johansen(a)canonical.com are
queue-4.14/apparmor-fix-regression-in-mount-mediation-when-feature-set-is-pinned.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: pxa3xx: Fix READOOB implementation
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mtd-nand-pxa3xx-fix-readoob-implementation.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From fee4380f368e84ed216b62ccd2fbc4126f2bf40b Mon Sep 17 00:00:00 2001
From: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Date: Mon, 18 Dec 2017 11:32:45 +0100
Subject: mtd: nand: pxa3xx: Fix READOOB implementation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Boris Brezillon <boris.brezillon(a)free-electrons.com>
commit fee4380f368e84ed216b62ccd2fbc4126f2bf40b upstream.
In the current driver, OOB bytes are accessed in raw mode, and when a
page access is done with NDCR_SPARE_EN set and NDCR_ECC_EN cleared, the
driver must read the whole spare area (64 bytes in case of a 2k page,
16 bytes for a 512 page). The driver was only reading the free OOB
bytes, which was leaving some unread data in the FIFO and was somehow
leading to a timeout.
We could patch the driver to read ->spare_size + ->ecc_size instead of
just ->spare_size when READOOB is requested, but we'd better make
in-band and OOB accesses consistent.
Since the driver is always accessing in-band data in non-raw mode (with
the ECC engine enabled), we should also access OOB data in this mode.
That's particularly useful when using the BCH engine because in this
mode the free OOB bytes are also ECC protected.
Fixes: 43bcfd2bb24a ("mtd: nand: pxa3xx: Add driver-specific ECC BCH support")
Reported-by: Sean Nyekjær <sean.nyekjaer(a)prevas.dk>
Tested-by: Willy Tarreau <w(a)1wt.eu>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Acked-by: Ezequiel Garcia <ezequiel(a)vanguardiasur.com.ar>
Tested-by: Sean Nyekjaer <sean.nyekjaer(a)prevas.dk>
Acked-by: Robert Jarzmik <robert.jarzmik(a)free.fr>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/pxa3xx_nand.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -743,6 +743,7 @@ static void prepare_start_command(struct
switch (command) {
case NAND_CMD_READ0:
+ case NAND_CMD_READOOB:
case NAND_CMD_PAGEPROG:
info->use_ecc = 1;
case NAND_CMD_READOOB:
Patches currently in stable-queue which might be from boris.brezillon(a)free-electrons.com are
queue-3.18/mtd-nand-pxa3xx-fix-readoob-implementation.patch
If we are asked for number of entries of an offset bigger than the
sg list we should not crash.
Cc: stable(a)vger.kernel.org
Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com>
---
drivers/staging/ccree/ssi_buffer_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c b/drivers/staging/ccree/ssi_buffer_mgr.c
index 78288ed..0f71264 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -94,7 +94,7 @@ static unsigned int cc_get_sgl_nents(struct device *dev,
{
unsigned int nents = 0;
- while (nbytes) {
+ while (nbytes && sg_list) {
if (sg_list->length) {
nents++;
/* get the number of bytes in the last entry */
--
2.7.4
If we ran out of DMA pool buffers, we get into the unmap
code path with a NULL before. Deal with this by checking
the virtual mapping is not NULL.
Cc: stable(a)vger.kernel.org
Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com>
---
drivers/staging/ccree/ssi_buffer_mgr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c b/drivers/staging/ccree/ssi_buffer_mgr.c
index e85bb53..78288ed 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -465,7 +465,8 @@ void cc_unmap_blkcipher_request(struct device *dev, void *ctx,
DMA_TO_DEVICE);
}
/* Release pool */
- if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI) {
+ if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI &&
+ req_ctx->mlli_params.mlli_virt_addr) {
dma_pool_free(req_ctx->mlli_params.curr_pool,
req_ctx->mlli_params.mlli_virt_addr,
req_ctx->mlli_params.mlli_dma_addr);
--
2.7.4
This is a note to let you know that I've just added the patch titled
x86/microcode/AMD: Add support for fam17h microcode loading
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-microcode-amd-add-support-for-fam17h-microcode-loading.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf Mon Sep 17 00:00:00 2001
From: Tom Lendacky <thomas.lendacky(a)amd.com>
Date: Thu, 30 Nov 2017 16:46:40 -0600
Subject: x86/microcode/AMD: Add support for fam17h microcode loading
From: Tom Lendacky <thomas.lendacky(a)amd.com>
commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf upstream.
The size for the Microcode Patch Block (MPB) for an AMD family 17h
processor is 3200 bytes. Add a #define for fam17h so that it does
not default to 2048 bytes and fail a microcode load/update.
Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Borislav Petkov <bp(a)alien8.de>
Link: https://lkml.kernel.org/r/20171130224640.15391.40247.stgit@tlendack-t1.amdo…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Alice Ferrazzi <alicef(a)gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/microcode/amd.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -592,6 +592,7 @@ static unsigned int verify_patch_size(u8
#define F14H_MPB_MAX_SIZE 1824
#define F15H_MPB_MAX_SIZE 4096
#define F16H_MPB_MAX_SIZE 3458
+#define F17H_MPB_MAX_SIZE 3200
switch (family) {
case 0x14:
@@ -603,6 +604,9 @@ static unsigned int verify_patch_size(u8
case 0x16:
max_size = F16H_MPB_MAX_SIZE;
break;
+ case 0x17:
+ max_size = F17H_MPB_MAX_SIZE;
+ break;
default:
max_size = F1XH_MPB_MAX_SIZE;
break;
Patches currently in stable-queue which might be from thomas.lendacky(a)amd.com are
queue-4.9/x86-microcode-amd-add-support-for-fam17h-microcode-loading.patch