The patch titled
Subject: userfaultfd: remove uffd flags from vma->vm_flags if UFFD_EVENT_FORK fails
has been added to the -mm tree. Its filename is
userfaultfd-remove-uffd-flags-from-vma-vm_flags-if-uffd_event_fork-fails.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/userfaultfd-remove-uffd-flags-from…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/userfaultfd-remove-uffd-flags-from…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Mike Rapoport <rppt(a)linux.vnet.ibm.com>
Subject: userfaultfd: remove uffd flags from vma->vm_flags if UFFD_EVENT_FORK fails
The fix in 0cbb4b4f4c44 ("userfaultfd: clear the vma->vm_userfaultfd_ctx
if UFFD_EVENT_FORK fails") cleared the vma->vm_userfaultfd_ctx but kept
userfaultfd flags in vma->vm_flags that were copied from the parent
process VMA.
As the result, there is an inconsistency between the values of
vma->vm_userfaultfd_ctx.ctx and vma->vm_flags which triggers BUG_ON in
userfaultfd_release().
Clearing the uffd flags from vma->vm_flags in case of UFFD_EVENT_FORK
failure resolves the issue.
Link: http://lkml.kernel.org/r/1532931975-25473-1-git-send-email-rppt@linux.vnet.…
Fixes: 0cbb4b4f4c44 ("userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK fails")
Signed-off-by: Mike Rapoport <rppt(a)linux.vnet.ibm.com>
Reported-by: syzbot+121be635a7a35ddb7dcb(a)syzkaller.appspotmail.com
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Eric Biggers <ebiggers3(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN fs/userfaultfd.c~userfaultfd-remove-uffd-flags-from-vma-vm_flags-if-uffd_event_fork-fails fs/userfaultfd.c
--- a/fs/userfaultfd.c~userfaultfd-remove-uffd-flags-from-vma-vm_flags-if-uffd_event_fork-fails
+++ a/fs/userfaultfd.c
@@ -633,8 +633,10 @@ static void userfaultfd_event_wait_compl
/* the various vma->vm_userfaultfd_ctx still points to it */
down_write(&mm->mmap_sem);
for (vma = mm->mmap; vma; vma = vma->vm_next)
- if (vma->vm_userfaultfd_ctx.ctx == release_new_ctx)
+ if (vma->vm_userfaultfd_ctx.ctx == release_new_ctx) {
vma->vm_userfaultfd_ctx = NULL_VM_UFFD_CTX;
+ vma->vm_flags &= ~(VM_UFFD_WP | VM_UFFD_MISSING);
+ }
up_write(&mm->mmap_sem);
userfaultfd_ctx_put(release_new_ctx);
_
Patches currently in -mm which might be from rppt(a)linux.vnet.ibm.com are
userfaultfd-remove-uffd-flags-from-vma-vm_flags-if-uffd_event_fork-fails.patch
mm-make-deferred_struct_page_init-explicitly-depend-on-sparsemem.patch
mm-memblock-replace-u64-with-phys_addr_t-where-appropriate.patch
mm-mempool-add-missing-parameter-description.patch
mm-util-make-strndup_user-description-a-kernel-doc-comment.patch
mm-util-add-kernel-doc-for-kvfree.patch
docs-core-api-kill-trailing-whitespace-in-kernel-apirst.patch
docs-core-api-move-strmemdup-to-string-manipulation.patch
docs-core-api-split-memory-management-api-to-a-separate-file.patch
docs-mm-make-gfp-flags-descriptions-usable-as-kernel-doc.patch
docs-core-api-mm-api-add-section-about-gfp-flags.patch
Hi Greg,
Kindly consider/review following net/sched fixes for stable 4.4.y.
This patchset is a follow-up of upstream fix
87b60cfacf9f ("net_sched: fix error recovery at qdisc creation")
cherry-picked on stable 4.4.y.
It fix null pointer dereferences due to uninitialized timer
(qdisc watchdog) or double frees due to ->destroy cleaning up a
second time. Here is the original submission
https://www.mail-archive.com/netdev@vger.kernel.org/msg186003.html
Cherry-picked and build tested on Linux 4.4.145 for ARCH=arm/arm64.
Regards,
Amit Pundir
Nikolay Aleksandrov (5):
sch_htb: fix crash on init failure
sch_multiq: fix double free on init failure
sch_hhf: fix null pointer dereference on init failure
sch_netem: avoid null pointer deref on init failure
sch_tbf: fix two null pointer dereferences on init failure
net/sched/sch_hhf.c | 3 +++
net/sched/sch_htb.c | 5 +++--
net/sched/sch_multiq.c | 7 +------
net/sched/sch_netem.c | 4 ++--
net/sched/sch_tbf.c | 5 +++--
5 files changed, 12 insertions(+), 12 deletions(-)
--
2.7.4
'type' is a user-controlled value used to index into 's_qf_names', which
can be used in a Spectre v1 attack. Clamp 'type' to the size of the
array to avoid a speculative out-of-bounds read.
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Jeremy Cline <jcline(a)redhat.com>
---
fs/ext4/super.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 6480e763080f..c04a09b51742 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -40,6 +40,7 @@
#include <linux/crc16.h>
#include <linux/dax.h>
#include <linux/cleancache.h>
+#include <linux/nospec.h>
#include <linux/uaccess.h>
#include <linux/iversion.h>
@@ -5559,6 +5560,7 @@ static int ext4_quota_on(struct super_block *sb, int type, int format_id,
if (path->dentry->d_sb != sb)
return -EXDEV;
/* Journaling quota? */
+ type = array_index_nospec(type, EXT4_MAXQUOTAS);
if (EXT4_SB(sb)->s_qf_names[type]) {
/* Quotafile not in fs root? */
if (path->dentry->d_parent != sb->s_root)
--
2.17.1
Starting with Clang-7.0, _THIS_IP_ generates -Wreturn-stack-address
warnings for almost every translation unit. In general, I'd prefer to
leave this on (returning the address of a stack allocated variable is in
general a bad idea) and disable it only at whitelisted call sites.
We can't do something like:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wreturn-stack-address"
<code>
#pragma clang diagnostic pop
in a GNU Statement Expression or macro, hence we use _Pragma, which is
its raison d'être: https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html
Cc: stable(a)vger.kernel.org # 4.17, 4.14, 4.9, 4.4
Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
---
include/linux/kernel.h | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 941dc0a5a877..5906f5727f90 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -168,7 +168,15 @@
#define _RET_IP_ (unsigned long)__builtin_return_address(0)
-#define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })
+#define _THIS_IP_ ( \
+{ \
+ _Pragma("clang diagnostic push") \
+ _Pragma("clang diagnostic ignored \"-Wreturn-stack-address\"") \
+ __label__ __here; \
+__here: (unsigned long)&&__here; \
+ _Pragma("clang diagnostic pop") \
+} \
+)
#ifdef CONFIG_LBDAF
# include <asm/div64.h>
--
2.18.0.233.g985f88cf7e-goog
I tested this on AMD Ryzen & Intel Broadwell system and dumped the
boot_cpu_data before and after a microcode update. On the Intel
system I also did a fatal MCE using mce-inject to confirm the output
from the mce handling code.
P.
---8<---
On systems where a runtime microcode update has occurred the microcode
version output in a MCE log record is wrong because
boot_cpu_data.microcode is not updated during runtime.
Update boot_cpu_data.microcode when the BSP's microcode is updated.
Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check records")
Suggested-by: Borislav Petkov <bp(a)alien8.com>
Signed-off-by: Prarit Bhargava <prarit(a)redhat.com>
Cc: stable(a)vger.kernel.org
Cc: sironi(a)amazon.de
Cc: tony.luck(a)intel.com
---
Changes in v2: Use mc_amd->hdr.patch_id on AMD
arch/x86/kernel/cpu/microcode/amd.c | 4 ++++
arch/x86/kernel/cpu/microcode/intel.c | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
index 0624957aa068..63b072377ba4 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -537,6 +537,10 @@ static enum ucode_state apply_microcode_amd(int cpu)
uci->cpu_sig.rev = mc_amd->hdr.patch_id;
c->microcode = mc_amd->hdr.patch_id;
+ /* Update boot_cpu_data's revision too, if we're on the BSP: */
+ if (c->cpu_index == boot_cpu_data.cpu_index)
+ boot_cpu_data.microcode = mc_amd->hdr.patch_id;
+
return UCODE_UPDATED;
}
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index 97ccf4c3b45b..256d336cbc04 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -851,6 +851,10 @@ static enum ucode_state apply_microcode_intel(int cpu)
uci->cpu_sig.rev = rev;
c->microcode = rev;
+ /* Update boot_cpu_data's revision too, if we're on the BSP: */
+ if (c->cpu_index == boot_cpu_data.cpu_index)
+ boot_cpu_data.microcode = rev;
+
return UCODE_UPDATED;
}
--
2.17.0