The patch below does not apply to the 4.9-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 9212ec7d8357ea630031e89d0d399c761421c83b Mon Sep 17 00:00:00 2001
From: Sebastian Mayr <me(a)sam.st>
Date: Sun, 28 Jul 2019 17:26:17 +0200
Subject: [PATCH] uprobes/x86: Fix detection of 32-bit user mode
32-bit processes running on a 64-bit kernel are not always detected
correctly, causing the process to crash when uretprobes are installed.
The reason for the crash is that in_ia32_syscall() is used to determine the
process's mode, which only works correctly when called from a syscall.
In the case of uretprobes, however, the function is called from a exception
and always returns 'false' on a 64-bit kernel. In consequence this leads to
corruption of the process's return address.
Fix this by using user_64bit_mode() instead of in_ia32_syscall(), which
is correct in any situation.
[ tglx: Add a comment and the following historical info ]
This should have been detected by the rename which happened in commit
abfb9498ee13 ("x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()")
which states in the changelog:
The is_ia32_task()/is_x32_task() function names are a big misnomer: they
suggests that the compat-ness of a system call is a task property, which
is not true, the compatness of a system call purely depends on how it
was invoked through the system call layer.
.....
and then it went and blindly renamed every call site.
Sadly enough this was already mentioned here:
8faaed1b9f50 ("uprobes/x86: Introduce sizeof_long(), cleanup adjust_ret_addr() and
arch_uretprobe_hijack_return_addr()")
where the changelog says:
TODO: is_ia32_task() is not what we actually want, TS_COMPAT does
not necessarily mean 32bit. Fortunately syscall-like insns can't be
probed so it actually works, but it would be better to rename and
use is_ia32_frame().
and goes all the way back to:
0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")
Oh well. 7+ years until someone actually tried a uretprobe on a 32bit
process on a 64bit kernel....
Fixes: 0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")
Signed-off-by: Sebastian Mayr <me(a)sam.st>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Dmitry Safonov <dsafonov(a)virtuozzo.com>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: Srikar Dronamraju <srikar(a)linux.vnet.ibm.com>
Cc: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/20190728152617.7308-1-me@sam.st
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index d8359ebeea70..8cd745ef8c7b 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -508,9 +508,12 @@ struct uprobe_xol_ops {
void (*abort)(struct arch_uprobe *, struct pt_regs *);
};
-static inline int sizeof_long(void)
+static inline int sizeof_long(struct pt_regs *regs)
{
- return in_ia32_syscall() ? 4 : 8;
+ /*
+ * Check registers for mode as in_xxx_syscall() does not apply here.
+ */
+ return user_64bit_mode(regs) ? 8 : 4;
}
static int default_pre_xol_op(struct arch_uprobe *auprobe, struct pt_regs *regs)
@@ -521,9 +524,9 @@ static int default_pre_xol_op(struct arch_uprobe *auprobe, struct pt_regs *regs)
static int emulate_push_stack(struct pt_regs *regs, unsigned long val)
{
- unsigned long new_sp = regs->sp - sizeof_long();
+ unsigned long new_sp = regs->sp - sizeof_long(regs);
- if (copy_to_user((void __user *)new_sp, &val, sizeof_long()))
+ if (copy_to_user((void __user *)new_sp, &val, sizeof_long(regs)))
return -EFAULT;
regs->sp = new_sp;
@@ -556,7 +559,7 @@ static int default_post_xol_op(struct arch_uprobe *auprobe, struct pt_regs *regs
long correction = utask->vaddr - utask->xol_vaddr;
regs->ip += correction;
} else if (auprobe->defparam.fixups & UPROBE_FIX_CALL) {
- regs->sp += sizeof_long(); /* Pop incorrect return address */
+ regs->sp += sizeof_long(regs); /* Pop incorrect return address */
if (emulate_push_stack(regs, utask->vaddr + auprobe->defparam.ilen))
return -ERESTART;
}
@@ -675,7 +678,7 @@ static int branch_post_xol_op(struct arch_uprobe *auprobe, struct pt_regs *regs)
* "call" insn was executed out-of-line. Just restore ->sp and restart.
* We could also restore ->ip and try to call branch_emulate_op() again.
*/
- regs->sp += sizeof_long();
+ regs->sp += sizeof_long(regs);
return -ERESTART;
}
@@ -1056,7 +1059,7 @@ bool arch_uprobe_skip_sstep(struct arch_uprobe *auprobe, struct pt_regs *regs)
unsigned long
arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr, struct pt_regs *regs)
{
- int rasize = sizeof_long(), nleft;
+ int rasize = sizeof_long(regs), nleft;
unsigned long orig_ret_vaddr = 0; /* clear high bits for 32-bit apps */
if (copy_from_user(&orig_ret_vaddr, (void __user *)regs->sp, rasize))
Please consider
commit b14c876b994f208b6b95c222056e1deb0a45de0e
Author: Radim Krcmar <rkrcmar(a)redhat.com>
Date: Tue Aug 13 23:37:37 2019 -0400
kvm: x86: skip populating logical dest map if apic is not sw enabled
This fixes 1e08ec4a130e2745d96df169e67c58df98a07311 that was introduced in v3.7.
The bug is that the KVM lapic is not considering whether the guest apic is enabled before
populating the apic in the logical destination table.
Thanks,
Bandan
The ADC in the JZ4740 can work either in high-precision mode with a 2.5V
range, or in low-precision mode with a 7.5V range. The code in place in
this driver will select the proper scale according to the maximum
voltage of the battery.
The JZ4770 however only has one mode, with a 6.6V range. If only one
scale is available, there's no need to change it (and nothing to change
it to), and trying to do so will fail with -EINVAL.
Fixes commit fb24ccfbe1e0 ("power: supply: add Ingenic JZ47xx battery
driver.")
Signed-off-by: Paul Cercueil <paul(a)crapouillou.net>
Cc: stable(a)vger.kernel.org
---
drivers/power/supply/ingenic-battery.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/power/supply/ingenic-battery.c b/drivers/power/supply/ingenic-battery.c
index 35816d4b3012..5a53057b4f64 100644
--- a/drivers/power/supply/ingenic-battery.c
+++ b/drivers/power/supply/ingenic-battery.c
@@ -80,6 +80,10 @@ static int ingenic_battery_set_scale(struct ingenic_battery *bat)
if (ret != IIO_AVAIL_LIST || scale_type != IIO_VAL_FRACTIONAL_LOG2)
return -EINVAL;
+ /* Only one (fractional) entry - nothing to change */
+ if (scale_len == 2)
+ return 0;
+
max_mV = bat->info.voltage_max_design_uv / 1000;
for (i = 0; i < scale_len; i += 2) {
--
2.21.0.593.g511ec345e18
The following patch causes a build failure:
Author: Henry Burns <henryburns(a)google.com>
Date: Sat Aug 24 17:55:06 2019 -0700
mm/zsmalloc.c: fix race condition in zs_destroy_pool
I get this error:
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC mm/zsmalloc.o
In file included from ./include/linux/mmzone.h:10:0,
from ./include/linux/gfp.h:6,
from ./include/linux/umh.h:4,
from ./include/linux/kmod.h:9,
from ./include/linux/module.h:13,
from mm/zsmalloc.c:33:
mm/zsmalloc.c: In function ‘zs_create_pool’:
mm/zsmalloc.c:2435:27: error: ‘struct zs_pool’ has no member named
‘migration_wait’
init_waitqueue_head(&pool->migration_wait);
^
./include/linux/wait.h:67:26: note: in definition of macro ‘init_waitqueue_head’
__init_waitqueue_head((wq_head), #wq_head, &__key); \
^~~~~~~
scripts/Makefile.build:278: recipe for target 'mm/zsmalloc.o' failed
make[1]: *** [mm/zsmalloc.o] Error 1
Makefile:1073: recipe for target 'mm' failed
You can find my configuration file attached.
Does anybody have any idea about this ?
Thanks in advance,
François Valenduc
On Fri, Aug 30, 2019 at 05:51:17PM -0400, Hui Peng wrote:
> This is the backported patch for the following fix to v4.4.x and v4.14.x:
> 19bce474c45b ("ALSA: usb-audio: Fix a stack buffer overflow bug in
> check_input_term")
Now queued up, thanks.
greg k-h