The patch titled
Subject: uprobes: __replace_page() avoid BUG in munlock_vma_page()
has been added to the -mm tree. Its filename is
uprobes-__replace_page-avoid-bug-in-munlock_vma_page.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/uprobes-__replace_page-avoid-bug-i…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/uprobes-__replace_page-avoid-bug-i…
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: Hugh Dickins <hughd(a)google.com>
Subject: uprobes: __replace_page() avoid BUG in munlock_vma_page()
syzbot crashed on the VM_BUG_ON_PAGE(PageTail) in munlock_vma_page(), when
called from uprobes __replace_page(). Which of many ways to fix it?
Settled on not calling when PageCompound (since Head and Tail are equals
in this context, PageCompound the usual check in uprobes.c, and the prior
use of FOLL_SPLIT_PMD will have cleared PageMlocked already).
Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2008161338360.20413@eggly.anvils
Fixes: 5a52c9df62b4 ("uprobe: use FOLL_SPLIT_PMD instead of FOLL_SPLIT")
Signed-off-by: Hugh Dickins <hughd(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Acked-by: Song Liu <songliubraving(a)fb.com>
Acked-by: Oleg Nesterov <oleg(a)redhat.com>
Reviewed-by: Srikar Dronamraju <srikar(a)linux.vnet.ibm.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> [5.4+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
kernel/events/uprobes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/events/uprobes.c~uprobes-__replace_page-avoid-bug-in-munlock_vma_page
+++ a/kernel/events/uprobes.c
@@ -205,7 +205,7 @@ static int __replace_page(struct vm_area
try_to_free_swap(old_page);
page_vma_mapped_walk_done(&pvmw);
- if (vma->vm_flags & VM_LOCKED)
+ if ((vma->vm_flags & VM_LOCKED) && !PageCompound(old_page))
munlock_vma_page(old_page);
put_page(old_page);
_
Patches currently in -mm which might be from hughd(a)google.com are
uprobes-__replace_page-avoid-bug-in-munlock_vma_page.patch
khugepaged-adjust-vm_bug_on_mm-in-__khugepaged_enter.patch
The patch titled
Subject: kernel/relay.c: fix memleak on destroy relay channel
has been added to the -mm tree. Its filename is
kernel-relayc-fix-memleak-on-destroy-relay-channel.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/kernel-relayc-fix-memleak-on-destr…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/kernel-relayc-fix-memleak-on-destr…
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: Wei Yongjun <weiyongjun1(a)huawei.com>
Subject: kernel/relay.c: fix memleak on destroy relay channel
kmemleak report memory leak as follows:
unreferenced object 0x607ee4e5f948 (size 8):
comm "syz-executor.1", pid 2098, jiffies 4295031601 (age 288.468s)
hex dump (first 8 bytes):
00 00 00 00 00 00 00 00 ........
backtrace:
[<00000000ca1de2fa>] relay_open kernel/relay.c:583 [inline]
[<00000000ca1de2fa>] relay_open+0xb6/0x970 kernel/relay.c:563
[<0000000038ae5a4b>] do_blk_trace_setup+0x4a8/0xb20 kernel/trace/blktrace.c:557
[<00000000d5e778e9>] __blk_trace_setup+0xb6/0x150 kernel/trace/blktrace.c:597
[<0000000038fdf803>] blk_trace_ioctl+0x146/0x280 kernel/trace/blktrace.c:738
[<00000000ce25a0ca>] blkdev_ioctl+0xb2/0x6a0 block/ioctl.c:613
[<00000000579e47e0>] block_ioctl+0xe5/0x120 fs/block_dev.c:1871
[<00000000b1588c11>] vfs_ioctl fs/ioctl.c:48 [inline]
[<00000000b1588c11>] __do_sys_ioctl fs/ioctl.c:753 [inline]
[<00000000b1588c11>] __se_sys_ioctl fs/ioctl.c:739 [inline]
[<00000000b1588c11>] __x64_sys_ioctl+0x170/0x1ce fs/ioctl.c:739
[<0000000088fc9942>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
[<000000004f6dd57a>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
'chan->buf' is malloced in relay_open() by alloc_percpu() but not free
while destroy the relay channel. Fix it by adding free_percpu() before
return from relay_destroy_channel().
Link: http://lkml.kernel.org/r/20200817122826.48518-1-weiyongjun1@huawei.com
Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel buffer pointers")
Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com>
Reported-by: Hulk Robot <hulkci(a)huawei.com>
Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: Michael Ellerman <mpe(a)ellerman.id.au>
Cc: David Rientjes <rientjes(a)google.com>
Cc: Michel Lespinasse <walken(a)google.com>
Cc: Daniel Axtens <dja(a)axtens.net>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Akash Goel <akash.goel(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
kernel/relay.c | 1 +
1 file changed, 1 insertion(+)
--- a/kernel/relay.c~kernel-relayc-fix-memleak-on-destroy-relay-channel
+++ a/kernel/relay.c
@@ -197,6 +197,7 @@ free_buf:
static void relay_destroy_channel(struct kref *kref)
{
struct rchan *chan = container_of(kref, struct rchan, kref);
+ free_percpu(chan->buf);
kfree(chan);
}
_
Patches currently in -mm which might be from weiyongjun1(a)huawei.com are
kernel-relayc-fix-memleak-on-destroy-relay-channel.patch
The patch titled
Subject: romfs: fix uninitialized memory leak in romfs_dev_read()
has been added to the -mm tree. Its filename is
romfs-fix-uninitialized-memory-leak-in-romfs_dev_read.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/romfs-fix-uninitialized-memory-lea…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/romfs-fix-uninitialized-memory-lea…
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: Jann Horn <jannh(a)google.com>
Subject: romfs: fix uninitialized memory leak in romfs_dev_read()
romfs has a superblock field that limits the size of the filesystem; data
beyond that limit is never accessed.
romfs_dev_read() fetches a caller-supplied number of bytes from the
backing device. It returns 0 on success or an error code on failure;
therefore, its API can't represent short reads, it's all-or-nothing.
However, when romfs_dev_read() detects that the requested operation would
cross the filesystem size limit, it currently silently truncates the
requested number of bytes. This e.g. means that when the content of a
file with size 0x1000 starts one byte before the filesystem size limit,
->readpage() will only fill a single byte of the supplied page while
leaving the rest uninitialized, leaking that uninitialized memory to
userspace.
Fix it by returning an error code instead of truncating the read when the
requested read operation would go beyond the end of the filesystem.
Link: http://lkml.kernel.org/r/20200818013202.2246365-1-jannh@google.com
Fixes: da4458bda237 ("NOMMU: Make it possible for RomFS to use MTD devices directly")
Signed-off-by: Jann Horn <jannh(a)google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: David Howells <dhowells(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/romfs/storage.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/fs/romfs/storage.c~romfs-fix-uninitialized-memory-leak-in-romfs_dev_read
+++ a/fs/romfs/storage.c
@@ -217,10 +217,8 @@ int romfs_dev_read(struct super_block *s
size_t limit;
limit = romfs_maxsize(sb);
- if (pos >= limit)
+ if (pos >= limit || buflen > limit - pos)
return -EIO;
- if (buflen > limit - pos)
- buflen = limit - pos;
#ifdef CONFIG_ROMFS_ON_MTD
if (sb->s_mtd)
_
Patches currently in -mm which might be from jannh(a)google.com are
romfs-fix-uninitialized-memory-leak-in-romfs_dev_read.patch
The patch titled
Subject: include/asm-generic/vmlinux.lds.h: align ro_after_init
has been removed from the -mm tree. Its filename was
include-asm-generic-vmlinuxldsh-align-ro_after_init.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Romain Naour <romain.naour(a)gmail.com>
Subject: include/asm-generic/vmlinux.lds.h: align ro_after_init
Since the patch [1], building the kernel using a toolchain built with
binutils 2.33.1 prevents booting a sh4 system under Qemu. Apply the patch
provided by Alan Modra [2] that fix alignment of rodata.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebd2263ba9a9124d…
[2] https://www.sourceware.org/ml/binutils/2019-12/msg00112.html
Link: https://marc.info/?l=linux-sh&m=158429470221261
Signed-off-by: Romain Naour <romain.naour(a)gmail.com>
Cc: Alan Modra <amodra(a)gmail.com>
Cc: Bin Meng <bin.meng(a)windriver.com>
Cc: Chen Zhou <chenzhou10(a)huawei.com>
Cc: Geert Uytterhoeven <geert+renesas(a)glider.be>
Cc: John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de>
Cc: Krzysztof Kozlowski <krzk(a)kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Cc: Rich Felker <dalias(a)libc.org>
Cc: Sam Ravnborg <sam(a)ravnborg.org>
Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/asm-generic/vmlinux.lds.h | 1 +
1 file changed, 1 insertion(+)
--- a/include/asm-generic/vmlinux.lds.h~include-asm-generic-vmlinuxldsh-align-ro_after_init
+++ a/include/asm-generic/vmlinux.lds.h
@@ -394,6 +394,7 @@
*/
#ifndef RO_AFTER_INIT_DATA
#define RO_AFTER_INIT_DATA \
+ . = ALIGN(8); \
__start_ro_after_init = .; \
*(.data..ro_after_init) \
JUMP_TABLE_DATA \
_
Patches currently in -mm which might be from romain.naour(a)gmail.com are
The patch titled
Subject: Revert "mm/vmstat.c: do not show lowmem reserve protection information of empty zone"
has been removed from the -mm tree. Its filename was
revert-mm-vmstatc-do-not-show-lowmem-reserve-protection-information-of-empty-zone.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Baoquan He <bhe(a)redhat.com>
Subject: Revert "mm/vmstat.c: do not show lowmem reserve protection information of empty zone"
This reverts commit 26e7deadaae175.
Sonny reported that one of their tests started failing on the latest
kernel on their Chrome OS platform. The root cause is that the above
commit removed the protection line of empty zone, while the parser used in
the test relies on the protection line to mark the end of each zone.
Let's revert it to avoid breaking userspace testing or applications.
Link: http://lkml.kernel.org/r/20200811075412.12872-1-bhe@redhat.com
Fixes: 26e7deadaae175 ("mm/vmstat.c: do not show lowmem reserve protection information of empty zone)"
Signed-off-by: Baoquan He <bhe(a)redhat.com>
Reported-by: Sonny Rao <sonnyrao(a)chromium.org>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Acked-by: David Rientjes <rientjes(a)google.com>
Cc: <stable(a)vger.kernel.org> [5.8.x]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/vmstat.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/mm/vmstat.c~revert-mm-vmstatc-do-not-show-lowmem-reserve-protection-information-of-empty-zone
+++ a/mm/vmstat.c
@@ -1642,12 +1642,6 @@ static void zoneinfo_show_print(struct s
zone->present_pages,
zone_managed_pages(zone));
- /* If unpopulated, no other information is useful */
- if (!populated_zone(zone)) {
- seq_putc(m, '\n');
- return;
- }
-
seq_printf(m,
"\n protection: (%ld",
zone->lowmem_reserve[0]);
@@ -1655,6 +1649,12 @@ static void zoneinfo_show_print(struct s
seq_printf(m, ", %ld", zone->lowmem_reserve[i]);
seq_putc(m, ')');
+ /* If unpopulated, no other information is useful */
+ if (!populated_zone(zone)) {
+ seq_putc(m, '\n');
+ return;
+ }
+
for (i = 0; i < NR_VM_ZONE_STAT_ITEMS; i++)
seq_printf(m, "\n %-12s %lu", zone_stat_name(i),
zone_page_state(zone, i));
_
Patches currently in -mm which might be from bhe(a)redhat.com are
Commit 0f348db01fdf ("thermal: ti-soc-thermal: Fix reversed condition
in ti_thermal_expose_sensor()") Fixes an issue that was introduced by
accidentally inverting the check which disabled the functionality.
The issue was then backported to 4.14+ kernels, so they are also
affected and this patch fixes the regressions.
Please backport this fix to kernels 4.14+ to restore functionality.
Thank you,
adam
LLVM implemented a recent "libcall optimization" that lowers calls to
`sprintf(dest, "%s", str)` where the return value is used to
`stpcpy(dest, str) - dest`. This generally avoids the machinery involved
in parsing format strings. This optimization was introduced into
clang-12. Because the kernel does not provide an implementation of
stpcpy, we observe linkage failures for almost all targets when building
with ToT clang.
The interface is unsafe as it does not perform any bounds checking.
Disable this "libcall optimization" via `-fno-builtin-stpcpy`.
Unlike
commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
which cited failures with `-fno-builtin-*` flags being retained in LLVM
LTO, that bug seems to have been fixed by
https://reviews.llvm.org/D71193, so the above sha can now be reverted in
favor of `-fno-builtin-bcmp`.
Cc: stable(a)vger.kernel.org # 4.4
Link: https://bugs.llvm.org/show_bug.cgi?id=47162
Link: https://github.com/ClangBuiltLinux/linux/issues/1126
Link: https://reviews.llvm.org/D85963
Reported-by: Sami Tolvanen <samitolvanen(a)google.com>
Suggested-by: Dávid Bolvanský <david.bolvansky(a)gmail.com>
Suggested-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
---
Makefile | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Makefile b/Makefile
index 9cac6fde3479..211a1b6f6478 100644
--- a/Makefile
+++ b/Makefile
@@ -959,6 +959,12 @@ ifdef CONFIG_RETPOLINE
KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
endif
+# The compiler may "libcall optimize" certain function calls into the below
+# functions, for architectures that don't use -ffreestanding. If we don't plan
+# to provide implementations of these routines, then prevent the compiler from
+# emitting calls to what will be undefined symbols.
+KBUILD_CFLAGS += -fno-builtin-stpcpy
+
# include additional Makefiles when needed
include-y := scripts/Makefile.extrawarn
include-$(CONFIG_KASAN) += scripts/Makefile.kasan
--
2.28.0.220.ged08abb693-goog