Check the allocation size before toggling kfence_allocation_gate.
This way allocations that can't be served by KFENCE will not result in
waiting for another CONFIG_KFENCE_SAMPLE_INTERVAL without allocating
anything.
Suggested-by: Marco Elver <elver(a)google.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Marco Elver <elver(a)google.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: stable(a)vger.kernel.org # 5.12+
Signed-off-by: Alexander Potapenko <glider(a)google.com>
Reviewed-by: Marco Elver <elver(a)google.com>
---
mm/kfence/core.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/mm/kfence/core.c b/mm/kfence/core.c
index d7666ace9d2e4..2623ff401a104 100644
--- a/mm/kfence/core.c
+++ b/mm/kfence/core.c
@@ -733,6 +733,13 @@ void kfence_shutdown_cache(struct kmem_cache *s)
void *__kfence_alloc(struct kmem_cache *s, size_t size, gfp_t flags)
{
+ /*
+ * Perform size check before switching kfence_allocation_gate, so that
+ * we don't disable KFENCE without making an allocation.
+ */
+ if (size > PAGE_SIZE)
+ return NULL;
+
/*
* allocation_gate only needs to become non-zero, so it doesn't make
* sense to continue writing to it and pay the associated contention
@@ -757,9 +764,6 @@ void *__kfence_alloc(struct kmem_cache *s, size_t size, gfp_t flags)
if (!READ_ONCE(kfence_enabled))
return NULL;
- if (size > PAGE_SIZE)
- return NULL;
-
return kfence_guarded_alloc(s, size, flags);
}
--
2.32.0.93.g670b81a890-goog
Xiaochen Zou (1):
can: fix a potential UAF access in j1939_session_deactivate(). Both
session and session->priv may be freed in
j1939_session_deactivate_locked(). It leads to potential UAF read
and write in j1939_session_list_unlock(). The free chain is
j1939_session_deactivate_locked()->j1939_session_put()->__j1939_session_release()->j1939_session_destroy().
To fix this bug, I moved j1939_session_put() behind
j1939_session_deactivate_locked(), and guarded it with a check of
active since the session would be freed only if active is true.
net/can/j1939/transport.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--
2.17.1
>From 9c4733d093e05db22eb89825579c83e020c3c1a6 Mon Sep 17 00:00:00 2001
From: Xiaochen Zou <xzou017(a)ucr.edu>
Date: Tue, 13 Jul 2021 13:15:59 -0700
Subject: [PATCH 1/1] can: fix a potential UAF access in
j1939_session_deactivate().
To: greg(a)kroah.com
Cc: stable@vger.kernel.org,netdev@vger.kernel.org,linux-can@vger.kernel.org
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------2.17.1"
This is a multi-part message in MIME format.
The patch titled
Subject: mm: page_alloc: fix page_poison=1 / INIT_ON_ALLOC_DEFAULT_ON interaction
has been added to the -mm tree. Its filename is
mm-page_alloc-fix-page_poison=1-init_on_alloc_default_on-interaction.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-page_alloc-fix-page_poison%3D1…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-page_alloc-fix-page_poison%3D1…
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: Sergei Trofimovich <slyfox(a)gentoo.org>
Subject: mm: page_alloc: fix page_poison=1 / INIT_ON_ALLOC_DEFAULT_ON interaction
To reproduce the failure we need the following system:
- kernel command: page_poison=1 init_on_free=0 init_on_alloc=0
- kernel config:
* CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
* CONFIG_INIT_ON_FREE_DEFAULT_ON=y
* CONFIG_PAGE_POISONING=y
0000000085629bdd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000000022861832: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000000c597f5b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
CPU: 11 PID: 15195 Comm: bash Kdump: loaded Tainted: G U O 5.13.1-gentoo-x86_64 #1
Hardware name: System manufacturer System Product Name/PRIME Z370-A, BIOS 2801 01/13/2021
Call Trace:
dump_stack+0x64/0x7c
__kernel_unpoison_pages.cold+0x48/0x84
post_alloc_hook+0x60/0xa0
get_page_from_freelist+0xdb8/0x1000
__alloc_pages+0x163/0x2b0
__get_free_pages+0xc/0x30
pgd_alloc+0x2e/0x1a0
? dup_mm+0x37/0x4f0
mm_init+0x185/0x270
dup_mm+0x6b/0x4f0
? __lock_task_sighand+0x35/0x70
copy_process+0x190d/0x1b10
kernel_clone+0xba/0x3b0
__do_sys_clone+0x8f/0xb0
do_syscall_64+0x68/0x80
? do_syscall_64+0x11/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Before the 51cba1eb ("init_on_alloc: Optimize static branches")
init_on_alloc never enabled static branch by default. It could only be
enabed explicitly by init_mem_debugging_and_hardening().
But after the 51cba1eb static branch could already be enabled by default.
There was no code to ever disable it. That caused page_poison=1 /
init_on_free=1 conflict.
This change extends init_mem_debugging_and_hardening() to also disable
static branch disabling.
Link: https://lkml.kernel.org/r/20210712215816.1512739-1-slyfox@gentoo.org
Fixes: 51cba1eb ("init_on_alloc: Optimize static branches")
Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org>
Reported-by: <bowsingbetee(a)pm.me>
Reported-by: Mikhail Morfikov
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_alloc.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--- a/mm/page_alloc.c~mm-page_alloc-fix-page_poison=1-init_on_alloc_default_on-interaction
+++ a/mm/page_alloc.c
@@ -840,18 +840,22 @@ void init_mem_debugging_and_hardening(vo
}
#endif
- if (_init_on_alloc_enabled_early) {
- if (page_poisoning_requested)
+ if (_init_on_alloc_enabled_early ||
+ IS_ENABLED(CONFIG_INIT_ON_ALLOC_DEFAULT_ON)) {
+ if (page_poisoning_requested) {
pr_info("mem auto-init: CONFIG_PAGE_POISONING is on, "
"will take precedence over init_on_alloc\n");
- else
+ static_branch_disable(&init_on_alloc);
+ } else
static_branch_enable(&init_on_alloc);
}
- if (_init_on_free_enabled_early) {
- if (page_poisoning_requested)
+ if (_init_on_free_enabled_early ||
+ IS_ENABLED(CONFIG_INIT_ON_FREE_DEFAULT_ON)) {
+ if (page_poisoning_requested) {
pr_info("mem auto-init: CONFIG_PAGE_POISONING is on, "
"will take precedence over init_on_free\n");
- else
+ static_branch_disable(&init_on_free);
+ } else
static_branch_enable(&init_on_free);
}
_
Patches currently in -mm which might be from slyfox(a)gentoo.org are
mm-page_alloc-fix-page_poison=1-init_on_alloc_default_on-interaction.patch
hallo
all fine here on an Intel i7-6700 box.
thanks
+++ UPDATE +++
##############
Regarding the above I need to be more accurate:
The kernel compiles, boots and runs without errors -so far -.
BUT: it seems under load it could lead to an dead box.
what I did:
running in one terminal: dmesg -w
and in an second terminal:
make clean && ccache -Czs && time make all -j $(nproc)
leads within a minutes to an complete dead box after make has started !
- no output regarding crashes, etc. in the first terminal running dmesg
- no mouse, no keyboard, no switch via CRTL+ALT+F3 to a console
- the box is dead
- only the power button helps
with kernel 5.13.1 all the above is fine
anyone (too) ?
--
regards
Ronald
The patch titled
Subject: mm/hugetlb: fix refs calculation from unaligned @vaddr
has been added to the -mm tree. Its filename is
mm-hugetlb-fix-refs-calculation-from-unaligned-vaddr.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-fix-refs-calculation-f…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-fix-refs-calculation-f…
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: Joao Martins <joao.m.martins(a)oracle.com>
Subject: mm/hugetlb: fix refs calculation from unaligned @vaddr
commit 82e5d378b0e47 ("mm/hugetlb: refactor subpage recording") refactored
the count of subpages but missed an edge case when @vaddr is not aligned
to PAGE_SIZE e.g. when close to vma->vm_end. It would then errousnly set
@refs to 0 and record_subpages_vmas() wouldn't set the @pages array
element to its value, consequently causing the reported null-deref by
syzbot.
Fix it by aligning down @vaddr by PAGE_SIZE in @refs calculation.
Link: https://lkml.kernel.org/r/20210713152440.28650-1-joao.m.martins@oracle.com
Fixes: 82e5d378b0e47 ("mm/hugetlb: refactor subpage recording")
Reported-by: syzbot+a3fcd59df1b372066f5a(a)syzkaller.appspotmail.com
Signed-off-by: Joao Martins <joao.m.martins(a)oracle.com>
Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/hugetlb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/mm/hugetlb.c~mm-hugetlb-fix-refs-calculation-from-unaligned-vaddr
+++ a/mm/hugetlb.c
@@ -5440,8 +5440,9 @@ long follow_hugetlb_page(struct mm_struc
continue;
}
- refs = min3(pages_per_huge_page(h) - pfn_offset,
- (vma->vm_end - vaddr) >> PAGE_SHIFT, remainder);
+ /* vaddr may not be aligned to PAGE_SIZE */
+ refs = min3(pages_per_huge_page(h) - pfn_offset, remainder,
+ (vma->vm_end - ALIGN_DOWN(vaddr, PAGE_SIZE)) >> PAGE_SHIFT);
if (pages || vmas)
record_subpages_vmas(mem_map_offset(page, pfn_offset),
_
Patches currently in -mm which might be from joao.m.martins(a)oracle.com are
mm-hugetlb-fix-refs-calculation-from-unaligned-vaddr.patch