I'm announcing the release of the 5.15.62 kernel.
All users of the 5.15 kernel series must upgrade.
The updated 5.15.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.15.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2
arch/x86/kernel/ftrace.c | 7 --
arch/x86/kernel/ftrace_64.S | 19 +++++-
drivers/tee/tee_shm.c | 3 +
fs/btrfs/raid56.c | 74 +++++++++++++++++++------
fs/io_uring.c | 2
fs/ksmbd/smb2misc.c | 7 +-
fs/ksmbd/smb2pdu.c | 45 +++++++++------
fs/ksmbd/smbacl.c | 130 +++++++++++++++++++++++++++++---------------
fs/ksmbd/smbacl.h | 2
fs/ksmbd/vfs.c | 5 +
net/sched/cls_route.c | 10 +++
12 files changed, 215 insertions(+), 91 deletions(-)
Greg Kroah-Hartman (1):
Linux 5.15.62
Hyunchul Lee (1):
ksmbd: prevent out of bound read for SMB2_WRITE
Jamal Hadi Salim (1):
net_sched: cls_route: disallow handle of 0
Jens Axboe (1):
io_uring: use original request task for inflight tracking
Jens Wiklander (1):
tee: add overflow check in register_shm_helper()
Namjae Jeon (1):
ksmbd: fix heap-based overflow in set_ntacl_dacl()
Peter Zijlstra (2):
x86/ibt,ftrace: Make function-graph play nice
x86/ftrace: Use alternative RET encoding
Qu Wenruo (2):
btrfs: only write the sectors in the vertical stripe which has data stripes
btrfs: raid56: don't trust any cached sector in __raid56_parity_recover()
Thadeu Lima de Souza Cascardo (1):
Revert "x86/ftrace: Use alternative RET encoding"
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 0b9ba6135d7f18b82f3d8bebb55ded725ba88e0e Mon Sep 17 00:00:00 2001
From: "Jason A. Donenfeld" <Jason(a)zx2c4.com>
Date: Wed, 13 Jul 2022 01:12:21 +0200
Subject: [PATCH] um: seed rng using host OS rng
UML generally does not provide access to special CPU instructions like
RDRAND, and execution tends to be rather deterministic, with no real
hardware interrupts, making good randomness really very hard, if not
all together impossible. Not only is this a security eyebrow raiser, but
it's also quite annoying when trying to do various pieces of UML-based
automation that takes a long time to boot, if ever.
Fix this by trivially calling getrandom() in the host and using that
seed as "bootloader randomness", which initializes the rng immediately
at UML boot.
The old behavior can be restored the same way as on any other arch, by
way of CONFIG_TRUST_BOOTLOADER_RANDOMNESS=n or
random.trust_bootloader=0. So seen from that perspective, this just
makes UML act like other archs, which is positive in its own right.
Additionally, wire up arch_get_random_{int,long}() in the same way, so
that reseeds can also make use of the host RNG, controllable by
CONFIG_TRUST_CPU_RANDOMNESS and random.trust_cpu, per usual.
Cc: stable(a)vger.kernel.org
Acked-by: Johannes Berg <johannes(a)sipsolutions.net>
Acked-By: Anton Ivanov <anton.ivanov(a)cambridgegreys.com>
Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com>
diff --git a/arch/um/include/asm/archrandom.h b/arch/um/include/asm/archrandom.h
new file mode 100644
index 000000000000..2f24cb96391d
--- /dev/null
+++ b/arch/um/include/asm/archrandom.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_UM_ARCHRANDOM_H__
+#define __ASM_UM_ARCHRANDOM_H__
+
+#include <linux/types.h>
+
+/* This is from <os.h>, but better not to #include that in a global header here. */
+ssize_t os_getrandom(void *buf, size_t len, unsigned int flags);
+
+static inline bool __must_check arch_get_random_long(unsigned long *v)
+{
+ return os_getrandom(v, sizeof(*v), 0) == sizeof(*v);
+}
+
+static inline bool __must_check arch_get_random_int(unsigned int *v)
+{
+ return os_getrandom(v, sizeof(*v), 0) == sizeof(*v);
+}
+
+static inline bool __must_check arch_get_random_seed_long(unsigned long *v)
+{
+ return false;
+}
+
+static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
+{
+ return false;
+}
+
+#endif
diff --git a/arch/um/include/shared/os.h b/arch/um/include/shared/os.h
index fafde1d5416e..0df646c6651e 100644
--- a/arch/um/include/shared/os.h
+++ b/arch/um/include/shared/os.h
@@ -11,6 +11,12 @@
#include <irq_user.h>
#include <longjmp.h>
#include <mm_id.h>
+/* This is to get size_t */
+#ifndef __UM_HOST__
+#include <linux/types.h>
+#else
+#include <sys/types.h>
+#endif
#define CATCH_EINTR(expr) while ((errno = 0, ((expr) < 0)) && (errno == EINTR))
@@ -243,6 +249,7 @@ extern void stack_protections(unsigned long address);
extern int raw(int fd);
extern void setup_machinename(char *machine_out);
extern void setup_hostinfo(char *buf, int len);
+extern ssize_t os_getrandom(void *buf, size_t len, unsigned int flags);
extern void os_dump_core(void) __attribute__ ((noreturn));
extern void um_early_printk(const char *s, unsigned int n);
extern void os_fix_helper_signals(void);
diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
index 0760e24f2eba..74f3efd96bd4 100644
--- a/arch/um/kernel/um_arch.c
+++ b/arch/um/kernel/um_arch.c
@@ -16,6 +16,7 @@
#include <linux/sched/task.h>
#include <linux/kmsg_dump.h>
#include <linux/suspend.h>
+#include <linux/random.h>
#include <asm/processor.h>
#include <asm/cpufeature.h>
@@ -406,6 +407,8 @@ int __init __weak read_initrd(void)
void __init setup_arch(char **cmdline_p)
{
+ u8 rng_seed[32];
+
stack_protections((unsigned long) &init_thread_info);
setup_physmem(uml_physmem, uml_reserved, physmem_size, highmem);
mem_total_pages(physmem_size, iomem_size, highmem);
@@ -416,6 +419,11 @@ void __init setup_arch(char **cmdline_p)
strlcpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
setup_hostinfo(host_info, sizeof host_info);
+
+ if (os_getrandom(rng_seed, sizeof(rng_seed), 0) == sizeof(rng_seed)) {
+ add_bootloader_randomness(rng_seed, sizeof(rng_seed));
+ memzero_explicit(rng_seed, sizeof(rng_seed));
+ }
}
void __init check_bugs(void)
diff --git a/arch/um/os-Linux/util.c b/arch/um/os-Linux/util.c
index 41297ec404bf..fc0f2a9dee5a 100644
--- a/arch/um/os-Linux/util.c
+++ b/arch/um/os-Linux/util.c
@@ -14,6 +14,7 @@
#include <sys/wait.h>
#include <sys/mman.h>
#include <sys/utsname.h>
+#include <sys/random.h>
#include <init.h>
#include <os.h>
@@ -96,6 +97,11 @@ static inline void __attribute__ ((noreturn)) uml_abort(void)
exit(127);
}
+ssize_t os_getrandom(void *buf, size_t len, unsigned int flags)
+{
+ return getrandom(buf, len, flags);
+}
+
/*
* UML helper threads must not handle SIGWINCH/INT/TERM
*/
Syzkaller has reported a warning in iomap_iter(), which got
triggered due to a call to iomap_iter_done() which has:
WARN_ON_ONCE(iter->iomap.offset > iter->pos);
The warning was triggered because `pos` was being negative.
I was having offset = 0, pos = -2950420705881096192.
This ridiculously negative value smells of an overflow, and sure
it is.
The userspace can configure a loop using an ioctl call, wherein
a configuration of type loop_config is passed (see lo_ioctl()'s
case on line 1550 of drivers/block/loop.c). This proceeds to call
loop_configure() which in turn calls loop_set_status_from_info()
(see line 1050 of loop.c), passing &config->info which is of type
loop_info64*. This function then sets the appropriate values, like
the offset.
The problem here is loop_device has lo_offset of type loff_t
(see line 52 of loop.c), which is typdef-chained to long long,
whereas loop_info64 has lo_offset of type __u64 (see line 56 of
include/uapi/linux/loop.h).
The function directly copies offset from info to the device as
follows (See line 980 of loop.c):
lo->lo_offset = info->lo_offset;
This results in the encountered overflow (in my case, the RHS
was 15496323367828455424).
Thus, convert the type definitions in loop_info64 to their
signed counterparts in order to match definitions in loop_device,
and check for negative value during loop_set_status_from_info().
Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a2…
Reported-and-tested-by: syzbot+a8e049cd3abd342936b6(a)syzkaller.appspotmail.com
Cc: stable(a)vger.kernel.org
Signed-off-by: Siddh Raman Pant <code(a)siddh.me>
---
Unless I am missing any other uses or quirks of UAPI loop_info64,
I think this won't introduce regression, since if something is
working, it will continue to work. If something does break, then
it was relying on overflows, which is anyways an incorrect way
to go about.
Also, it seems even the 32-bit compatibility structure uses the
signed types (compat_loop_info uses compat_int_t which is s32),
so this patch should be fine.
drivers/block/loop.c | 3 +++
include/uapi/linux/loop.h | 12 ++++++------
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index e3c0ba93c1a3..4ca20ce3158d 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -977,6 +977,9 @@ loop_set_status_from_info(struct loop_device *lo,
return -EINVAL;
}
+ if (info->lo_offset < 0 || info->lo_sizelimit < 0)
+ return -EINVAL;
+
lo->lo_offset = info->lo_offset;
lo->lo_sizelimit = info->lo_sizelimit;
memcpy(lo->lo_file_name, info->lo_file_name, LO_NAME_SIZE);
diff --git a/include/uapi/linux/loop.h b/include/uapi/linux/loop.h
index 6f63527dd2ed..973565f38f9d 100644
--- a/include/uapi/linux/loop.h
+++ b/include/uapi/linux/loop.h
@@ -53,12 +53,12 @@ struct loop_info64 {
__u64 lo_device; /* ioctl r/o */
__u64 lo_inode; /* ioctl r/o */
__u64 lo_rdevice; /* ioctl r/o */
- __u64 lo_offset;
- __u64 lo_sizelimit;/* bytes, 0 == max available */
- __u32 lo_number; /* ioctl r/o */
- __u32 lo_encrypt_type; /* obsolete, ignored */
- __u32 lo_encrypt_key_size; /* ioctl w/o */
- __u32 lo_flags;
+ __s64 lo_offset;
+ __s64 lo_sizelimit;/* bytes, 0 == max available */
+ __s32 lo_number; /* ioctl r/o */
+ __s32 lo_encrypt_type; /* obsolete, ignored */
+ __s32 lo_encrypt_key_size; /* ioctl w/o */
+ __s32 lo_flags;
__u8 lo_file_name[LO_NAME_SIZE];
__u8 lo_crypt_name[LO_NAME_SIZE];
__u8 lo_encrypt_key[LO_KEY_SIZE]; /* ioctl w/o */
--
2.35.1
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: fc2e426b1161761561624ebd43ce8c8d2fa058da
Gitweb: https://git.kernel.org/tip/fc2e426b1161761561624ebd43ce8c8d2fa058da
Author: Chen Zhongjin <chenzhongjin(a)huawei.com>
AuthorDate: Fri, 19 Aug 2022 16:43:34 +08:00
Committer: Ingo Molnar <mingo(a)kernel.org>
CommitterDate: Sun, 21 Aug 2022 12:19:32 +02:00
x86/unwind/orc: Unwind ftrace trampolines with correct ORC entry
When meeting ftrace trampolines in ORC unwinding, unwinder uses address
of ftrace_{regs_}call address to find the ORC entry, which gets next frame at
sp+176.
If there is an IRQ hitting at sub $0xa8,%rsp, the next frame should be
sp+8 instead of 176. It makes unwinder skip correct frame and throw
warnings such as "wrong direction" or "can't access registers", etc,
depending on the content of the incorrect frame address.
By adding the base address ftrace_{regs_}caller with the offset
*ip - ops->trampoline*, we can get the correct address to find the ORC entry.
Also change "caller" to "tramp_addr" to make variable name conform to
its content.
[ mingo: Clarified the changelog a bit. ]
Fixes: 6be7fa3c74d1 ("ftrace, orc, x86: Handle ftrace dynamically allocated trampolines")
Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org>
Cc: <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20220819084334.244016-1-chenzhongjin@huawei.com
---
arch/x86/kernel/unwind_orc.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index 38185ae..0ea57da 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -93,22 +93,27 @@ static struct orc_entry *orc_find(unsigned long ip);
static struct orc_entry *orc_ftrace_find(unsigned long ip)
{
struct ftrace_ops *ops;
- unsigned long caller;
+ unsigned long tramp_addr, offset;
ops = ftrace_ops_trampoline(ip);
if (!ops)
return NULL;
+ /* Set tramp_addr to the start of the code copied by the trampoline */
if (ops->flags & FTRACE_OPS_FL_SAVE_REGS)
- caller = (unsigned long)ftrace_regs_call;
+ tramp_addr = (unsigned long)ftrace_regs_caller;
else
- caller = (unsigned long)ftrace_call;
+ tramp_addr = (unsigned long)ftrace_caller;
+
+ /* Now place tramp_addr to the location within the trampoline ip is at */
+ offset = ip - ops->trampoline;
+ tramp_addr += offset;
/* Prevent unlikely recursion */
- if (ip == caller)
+ if (ip == tramp_addr)
return NULL;
- return orc_find(caller);
+ return orc_find(tramp_addr);
}
#else
static struct orc_entry *orc_ftrace_find(unsigned long ip)
This is the start of the stable review cycle for the 5.19.3 release.
There are 7 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun, 21 Aug 2022 15:36:59 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.19.3-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.19.3-rc1
Coiby Xu <coxu(a)redhat.com>
arm64: kexec_file: use more system keyrings to verify kernel image signature
Coiby Xu <coxu(a)redhat.com>
kexec, KEYS: make the code in bzImage64_verify_sig generic
Qu Wenruo <wqu(a)suse.com>
btrfs: raid56: don't trust any cached sector in __raid56_parity_recover()
Qu Wenruo <wqu(a)suse.com>
btrfs: only write the sectors in the vertical stripe which has data stripes
Jamal Hadi Salim <jhs(a)mojatatu.com>
net_sched: cls_route: disallow handle of 0
Jens Wiklander <jens.wiklander(a)linaro.org>
tee: add overflow check in register_shm_helper()
Marco Elver <elver(a)google.com>
Revert "mm: kfence: apply kmemleak_ignore_phys on early allocated pool"
-------------
Diffstat:
Makefile | 4 +--
arch/arm64/kernel/kexec_image.c | 11 +------
arch/x86/kernel/kexec-bzimage64.c | 20 +-----------
drivers/tee/tee_shm.c | 3 ++
fs/btrfs/raid56.c | 68 +++++++++++++++++++++++++++++++--------
include/linux/kexec.h | 7 ++++
kernel/kexec_file.c | 17 ++++++++++
mm/kfence/core.c | 18 +++++------
net/sched/cls_route.c | 10 ++++++
9 files changed, 105 insertions(+), 53 deletions(-)
--
Hello,
We the Board Directors believe you are in good health, doing great and
with the hope that this mail will meet you in good condition, We are
privileged and delighted to reach you via email" And we are urgently
waiting to hear from you. and again your number is not connecting.
My regards,
Dr. KAbore Aouessian
Sincerely,
Prof. Chin Guang
From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org>
Make filtering consistent with histograms. As "cpu" can be a field of an
event, allow for "common_cpu" to keep it from being confused with the
"cpu" field of the event.
Link: https://lore.kernel.org/all/20220820220920.e42fa32b70505b1904f0a0ad@kernel.…
Cc: stable(a)vger.kernel.org
Fixes: 1e3bac71c5053 ("tracing/histogram: Rename "cpu" to "common_cpu"")
Suggested-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org>
---
kernel/trace/trace_events.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 181f08186d32..0356cae0cf74 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -176,6 +176,7 @@ static int trace_define_generic_fields(void)
__generic_field(int, CPU, FILTER_CPU);
__generic_field(int, cpu, FILTER_CPU);
+ __generic_field(int, common_cpu, FILTER_CPU);
__generic_field(char *, COMM, FILTER_COMM);
__generic_field(char *, comm, FILTER_COMM);
--
2.35.1