OSDN Git Service
Nathan Chancellor [Thu, 18 Oct 2018 00:56:28 +0000 (17:56 -0700)]
mfd: db8500-prcmu: Fix some section annotations
[ Upstream commit
a3888f62fe66429fad3be7f2ba962e1e08c26fd6 ]
When building the kernel with Clang, the following section mismatch
warnings appear:
WARNING: vmlinux.o(.text+0x7239cc): Section mismatch in reference from
the function db8500_prcmu_probe() to the function
.init.text:init_prcm_registers()
The function db8500_prcmu_probe() references
the function __init init_prcm_registers().
This is often because db8500_prcmu_probe lacks a __init
annotation or the annotation of init_prcm_registers is wrong.
WARNING: vmlinux.o(.text+0x723e28): Section mismatch in reference from
the function db8500_prcmu_probe() to the function
.init.text:fw_project_name()
The function db8500_prcmu_probe() references
the function __init fw_project_name().
This is often because db8500_prcmu_probe lacks a __init
annotation or the annotation of fw_project_name is wrong.
db8500_prcmu_probe should not be marked as __init so remove the __init
annotation from fw_project_name and init_prcm_registers.
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Wed, 17 Oct 2018 17:13:23 +0000 (10:13 -0700)]
mfd: twl-core: Fix section annotations on {,un}protect_pm_master
[ Upstream commit
8838555089f0345b87f4277fe5a8dd647dc65589 ]
When building the kernel with Clang, the following section mismatch
warning appears:
WARNING: vmlinux.o(.text+0x3d84a3b): Section mismatch in reference from
the function twl_probe() to the function
.init.text:unprotect_pm_master()
The function twl_probe() references
the function __init unprotect_pm_master().
This is often because twl_probe lacks a __init
annotation or the annotation of unprotect_pm_master is wrong.
Remove the __init annotation on the *protect_pm_master functions so
there is no more mismatch.
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vignesh R [Mon, 3 Dec 2018 08:01:17 +0000 (13:31 +0530)]
mfd: ti_am335x_tscadc: Use PLATFORM_DEVID_AUTO while registering mfd cells
[ Upstream commit
b40ee006fe6a8a25093434e5d394128c356a48f3 ]
Use PLATFORM_DEVID_AUTO to number mfd cells while registering, so that
different instances are uniquely identified. This is required in order
to support registering of multiple instances of same ti_am335x_tscadc IP.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Biggers [Thu, 14 Feb 2019 16:20:01 +0000 (16:20 +0000)]
KEYS: allow reaching the keys quotas exactly
commit
a08bf91ce28ed3ae7b6fef35d843fef8dc8c2cd9 upstream.
If the sysctl 'kernel.keys.maxkeys' is set to some number n, then
actually users can only add up to 'n - 1' keys. Likewise for
'kernel.keys.maxbytes' and the root_* versions of these sysctls. But
these sysctls are apparently supposed to be *maximums*, as per their
names and all documentation I could find -- the keyrings(7) man page,
Documentation/security/keys/core.rst, and all the mentions of EDQUOT
meaning that the key quota was *exceeded* (as opposed to reached).
Thus, fix the code to allow reaching the quotas exactly.
Fixes:
0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.morris@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ralph Campbell [Thu, 21 Feb 2019 06:18:58 +0000 (22:18 -0800)]
numa: change get_mempolicy() to use nr_node_ids instead of MAX_NUMNODES
commit
050c17f239fd53adb55aa768d4f41bc76c0fe045 upstream.
The system call, get_mempolicy() [1], passes an unsigned long *nodemask
pointer and an unsigned long maxnode argument which specifies the length
of the user's nodemask array in bits (which is rounded up). The manual
page says that if the maxnode value is too small, get_mempolicy will
return EINVAL but there is no system call to return this minimum value.
To determine this value, some programs search /proc/<pid>/status for a
line starting with "Mems_allowed:" and use the number of digits in the
mask to determine the minimum value. A recent change to the way this line
is formatted [2] causes these programs to compute a value less than
MAX_NUMNODES so get_mempolicy() returns EINVAL.
Change get_mempolicy(), the older compat version of get_mempolicy(), and
the copy_nodes_to_user() function to use nr_node_ids instead of
MAX_NUMNODES, thus preserving the defacto method of computing the minimum
size for the nodemask array and the maxnode argument.
[1] http://man7.org/linux/man-pages/man2/get_mempolicy.2.html
[2] https://lore.kernel.org/lkml/
1545405631-6808-1-git-send-email-longman@redhat.com
Link: http://lkml.kernel.org/r/20190211180245.22295-1-rcampbell@nvidia.com
Fixes:
4fb8e5b89bcbbbb ("include/linux/nodemask.h: use nr_node_ids (not MAX_NUMNODES) in __nodemask_pr_numnodes()")
Signed-off-by: Ralph Campbell <rcampbell@nvidia.com>
Suggested-by: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Waiman Long <longman@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yan, Zheng [Mon, 11 Feb 2019 07:18:52 +0000 (15:18 +0800)]
ceph: avoid repeatedly adding inode to mdsc->snap_flush_list
commit
04242ff3ac0abbaa4362f97781dac268e6c3541a upstream.
Otherwise, mdsc->snap_flush_list may get corrupted.
Cc: stable@vger.kernel.org
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sat, 23 Feb 2019 08:05:14 +0000 (09:05 +0100)]
Linux 4.4.176
Joerg Roedel [Thu, 21 Feb 2019 13:52:13 +0000 (14:52 +0100)]
KVM: VMX: Fix x2apic check in vmx_msr_bitmap_mode()
The stable backport of upstream commit
904e14fb7cb96 KVM: VMX: make MSR bitmaps per-VCPU
has a bug in vmx_msr_bitmap_mode(). It enables the x2apic
MSR-bitmap when the kernel emulates x2apic for the guest in
software. The upstream version of the commit checkes whether
the hardware has virtualization enabled for x2apic
emulation.
Since KVM emulates x2apic for guests even when the host does
not support x2apic in hardware, this causes the intercept of
at least the X2APIC_TASKPRI MSR to be disabled on machines
not supporting that MSR. The result is undefined behavior,
on some machines (Intel Westmere based) it causes a crash of
the guest kernel when it tries to access that MSR.
Change the check in vmx_msr_bitmap_mode() to match the upstream
code. This fixes the guest crashes observed with stable
kernels starting with v4.4.168 through v4.4.175.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Tue, 22 Jan 2019 18:40:59 +0000 (10:40 -0800)]
ax25: fix possible use-after-free
commit
63530aba7826a0f8e129874df9c4d264f9db3f9e upstream.
syzbot found that ax25 routes where not properly protected
against concurrent use [1].
In this particular report the bug happened while
copying ax25->digipeat.
Fix this problem by making sure we call ax25_get_route()
while ax25_route_lock is held, so that no modification
could happen while using the route.
The current two ax25_get_route() callers do not sleep,
so this change should be fine.
Once we do that, ax25_get_route() no longer needs to
grab a reference on the found route.
[1]
ax25_connect(): syz-executor0 uses autobind, please contact jreuter@yaina.de
BUG: KASAN: use-after-free in memcpy include/linux/string.h:352 [inline]
BUG: KASAN: use-after-free in kmemdup+0x42/0x60 mm/util.c:113
Read of size 66 at addr
ffff888066641a80 by task syz-executor2/531
ax25_connect(): syz-executor0 uses autobind, please contact jreuter@yaina.de
CPU: 1 PID: 531 Comm: syz-executor2 Not tainted 5.0.0-rc2+ #10
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
check_memory_region_inline mm/kasan/generic.c:185 [inline]
check_memory_region+0x123/0x190 mm/kasan/generic.c:191
memcpy+0x24/0x50 mm/kasan/common.c:130
memcpy include/linux/string.h:352 [inline]
kmemdup+0x42/0x60 mm/util.c:113
kmemdup include/linux/string.h:425 [inline]
ax25_rt_autobind+0x25d/0x750 net/ax25/ax25_route.c:424
ax25_connect.cold+0x30/0xa4 net/ax25/af_ax25.c:1224
__sys_connect+0x357/0x490 net/socket.c:1664
__do_sys_connect net/socket.c:1675 [inline]
__se_sys_connect net/socket.c:1672 [inline]
__x64_sys_connect+0x73/0xb0 net/socket.c:1672
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x458099
Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:
00007f870ee22c78 EFLAGS:
00000246 ORIG_RAX:
000000000000002a
RAX:
ffffffffffffffda RBX:
0000000000000003 RCX:
0000000000458099
RDX:
0000000000000048 RSI:
0000000020000080 RDI:
0000000000000005
RBP:
000000000073bf00 R08:
0000000000000000 R09:
0000000000000000
ax25_connect(): syz-executor4 uses autobind, please contact jreuter@yaina.de
R10:
0000000000000000 R11:
0000000000000246 R12:
00007f870ee236d4
R13:
00000000004be48e R14:
00000000004ce9a8 R15:
00000000ffffffff
Allocated by task 526:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_kmalloc mm/kasan/common.c:496 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:504
ax25_connect(): syz-executor5 uses autobind, please contact jreuter@yaina.de
kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3609
kmalloc include/linux/slab.h:545 [inline]
ax25_rt_add net/ax25/ax25_route.c:95 [inline]
ax25_rt_ioctl+0x3b9/0x1270 net/ax25/ax25_route.c:233
ax25_ioctl+0x322/0x10b0 net/ax25/af_ax25.c:1763
sock_do_ioctl+0xe2/0x400 net/socket.c:950
sock_ioctl+0x32f/0x6c0 net/socket.c:1074
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0x107b/0x17d0 fs/ioctl.c:696
ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
ax25_connect(): syz-executor5 uses autobind, please contact jreuter@yaina.de
Freed by task 550:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
__cache_free mm/slab.c:3487 [inline]
kfree+0xcf/0x230 mm/slab.c:3806
ax25_rt_add net/ax25/ax25_route.c:92 [inline]
ax25_rt_ioctl+0x304/0x1270 net/ax25/ax25_route.c:233
ax25_ioctl+0x322/0x10b0 net/ax25/af_ax25.c:1763
sock_do_ioctl+0xe2/0x400 net/socket.c:950
sock_ioctl+0x32f/0x6c0 net/socket.c:1074
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0x107b/0x17d0 fs/ioctl.c:696
ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at
ffff888066641a80
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 0 bytes inside of
96-byte region [
ffff888066641a80,
ffff888066641ae0)
The buggy address belongs to the page:
page:
ffffea0001999040 count:1 mapcount:0 mapping:
ffff88812c3f04c0 index:0x0
flags: 0x1fffc0000000200(slab)
ax25_connect(): syz-executor4 uses autobind, please contact jreuter@yaina.de
raw:
01fffc0000000200 ffffea0001817948 ffffea0002341dc8 ffff88812c3f04c0
raw:
0000000000000000 ffff888066641000 0000000100000020 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888066641980: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff888066641a00: 00 00 00 00 00 00 00 00 02 fc fc fc fc fc fc fc
>
ffff888066641a80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff888066641b00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff888066641b80: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Tue, 5 Feb 2019 23:38:44 +0000 (15:38 -0800)]
mISDN: fix a race in dev_expire_timer()
commit
bdcc5bc25548ef6b08e2e43937148f907c212292 upstream.
Since mISDN_close() uses dev->pending to iterate over active
timers, there is a chance that one timer got removed from the
->pending list in dev_expire_timer() but that the thread
has not called yet wake_up_interruptible()
So mISDN_close() could miss this and free dev before
completion of at least one dev_expire_timer()
syzbot was able to catch this race :
BUG: KASAN: use-after-free in register_lock_class+0x140c/0x1bf0 kernel/locking/lockdep.c:827
Write of size 8 at addr
ffff88809fc18948 by task syz-executor1/24769
CPU: 1 PID: 24769 Comm: syz-executor1 Not tainted 5.0.0-rc5 #60
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
__asan_report_store8_noabort+0x17/0x20 mm/kasan/generic_report.c:140
register_lock_class+0x140c/0x1bf0 kernel/locking/lockdep.c:827
__lock_acquire+0x11f/0x4700 kernel/locking/lockdep.c:3224
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:152
__wake_up_common_lock+0xc7/0x190 kernel/sched/wait.c:120
__wake_up+0xe/0x10 kernel/sched/wait.c:145
dev_expire_timer+0xe4/0x3b0 drivers/isdn/mISDN/timerdev.c:174
call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
protocol 88fb is buggy, dev hsr_slave_0
protocol 88fb is buggy, dev hsr_slave_1
expire_timers kernel/time/timer.c:1362 [inline]
__run_timers kernel/time/timer.c:1681 [inline]
__run_timers kernel/time/timer.c:1649 [inline]
run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
__do_softirq+0x266/0x95a kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x180/0x1d0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
</IRQ>
RIP: 0010:__sanitizer_cov_trace_pc+0x26/0x50 kernel/kcov.c:101
Code: 90 90 90 90 55 48 89 e5 48 8b 75 08 65 48 8b 04 25 40 ee 01 00 65 8b 15 98 12 92 7e 81 e2 00 01 1f 00 75 2b 8b 90 d8 12 00 00 <83> fa 02 75 20 48 8b 88 e0 12 00 00 8b 80 dc 12 00 00 48 8b 11 48
RSP: 0018:
ffff8880589b7a60 EFLAGS:
00000246 ORIG_RAX:
ffffffffffffff13
RAX:
ffff888087ce25c0 RBX:
0000000000000001 RCX:
ffffffff818f8ca3
RDX:
0000000000000000 RSI:
ffffffff818f8b48 RDI:
0000000000000001
RBP:
ffff8880589b7a60 R08:
ffff888087ce25c0 R09:
ffffed1015d25bd0
R10:
ffffed1015d25bcf R11:
ffff8880ae92de7b R12:
ffffea0001ae4680
R13:
ffffea0001ae4688 R14:
0000000000000000 R15:
ffffea0001b41648
PageIdle include/linux/page-flags.h:398 [inline]
page_is_idle include/linux/page_idle.h:29 [inline]
mark_page_accessed+0x618/0x1140 mm/swap.c:398
touch_buffer fs/buffer.c:59 [inline]
__find_get_block+0x312/0xcc0 fs/buffer.c:1298
sb_find_get_block include/linux/buffer_head.h:338 [inline]
recently_deleted fs/ext4/ialloc.c:682 [inline]
find_inode_bit.isra.0+0x202/0x510 fs/ext4/ialloc.c:722
__ext4_new_inode+0x14ad/0x52c0 fs/ext4/ialloc.c:914
ext4_symlink+0x3f8/0xbe0 fs/ext4/namei.c:3096
vfs_symlink fs/namei.c:4126 [inline]
vfs_symlink+0x378/0x5d0 fs/namei.c:4112
do_symlinkat+0x22b/0x290 fs/namei.c:4153
__do_sys_symlink fs/namei.c:4172 [inline]
__se_sys_symlink fs/namei.c:4170 [inline]
__x64_sys_symlink+0x59/0x80 fs/namei.c:4170
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457b67
Code: 0f 1f 00 b8 5c 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 6d bb fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 58 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 4d bb fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:
00007fff045ce0f8 EFLAGS:
00000202 ORIG_RAX:
0000000000000058
RAX:
ffffffffffffffda RBX:
0000000000000001 RCX:
0000000000457b67
RDX:
00007fff045ce173 RSI:
00000000004bd63f RDI:
00007fff045ce160
RBP:
0000000000000000 R08:
0000000000000000 R09:
0000000000000013
R10:
0000000000000075 R11:
0000000000000202 R12:
0000000000000000
R13:
0000000000000001 R14:
000000000000029b R15:
0000000000000001
Allocated by task 24763:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_kmalloc mm/kasan/common.c:496 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:504
kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3609
kmalloc include/linux/slab.h:545 [inline]
mISDN_open+0x9a/0x270 drivers/isdn/mISDN/timerdev.c:59
misc_open+0x398/0x4c0 drivers/char/misc.c:141
chrdev_open+0x247/0x6b0 fs/char_dev.c:417
do_dentry_open+0x47d/0x1130 fs/open.c:771
vfs_open+0xa0/0xd0 fs/open.c:880
do_last fs/namei.c:3418 [inline]
path_openat+0x10d7/0x4690 fs/namei.c:3534
do_filp_open+0x1a1/0x280 fs/namei.c:3564
do_sys_open+0x3fe/0x5d0 fs/open.c:1063
__do_sys_openat fs/open.c:1090 [inline]
__se_sys_openat fs/open.c:1084 [inline]
__x64_sys_openat+0x9d/0x100 fs/open.c:1084
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 24762:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
__cache_free mm/slab.c:3487 [inline]
kfree+0xcf/0x230 mm/slab.c:3806
mISDN_close+0x2a1/0x390 drivers/isdn/mISDN/timerdev.c:97
__fput+0x2df/0x8d0 fs/file_table.c:278
____fput+0x16/0x20 fs/file_table.c:309
task_work_run+0x14a/0x1c0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:188 [inline]
exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at
ffff88809fc18900
which belongs to the cache kmalloc-192 of size 192
The buggy address is located 72 bytes inside of
192-byte region [
ffff88809fc18900,
ffff88809fc189c0)
The buggy address belongs to the page:
page:
ffffea00027f0600 count:1 mapcount:0 mapping:
ffff88812c3f0040 index:0xffff88809fc18000
flags: 0x1fffc0000000200(slab)
raw:
01fffc0000000200 ffffea000269f648 ffffea00029f7408 ffff88812c3f0040
raw:
ffff88809fc18000 ffff88809fc18000 000000010000000b 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88809fc18800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88809fc18880: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
ffff88809fc18900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88809fc18980: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff88809fc18a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Fri, 8 Feb 2019 20:41:05 +0000 (12:41 -0800)]
net/x25: do not hold the cpu too long in x25_new_lci()
commit
cf657d22ee1f0e887326a92169f2e28dc932fd10 upstream.
Due to quadratic behavior of x25_new_lci(), syzbot was able
to trigger an rcu stall.
Fix this by not blocking BH for the whole duration of
the function, and inserting a reschedule point when possible.
If we care enough, using a bitmap could get rid of the quadratic
behavior.
syzbot report :
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 0-...!: (10500 ticks this GP) idle=4fa/1/0x4000000000000002 softirq=283376/283376 fqs=0
rcu: (t=10501 jiffies g=383105 q=136)
rcu: rcu_preempt kthread starved for 10502 jiffies! g383105 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
rcu: RCU grace-period kthread stack dump:
rcu_preempt I28928 10 2 0x80000000
Call Trace:
context_switch kernel/sched/core.c:2844 [inline]
__schedule+0x817/0x1cc0 kernel/sched/core.c:3485
schedule+0x92/0x180 kernel/sched/core.c:3529
schedule_timeout+0x4db/0xfd0 kernel/time/timer.c:1803
rcu_gp_fqs_loop kernel/rcu/tree.c:1948 [inline]
rcu_gp_kthread+0x956/0x17a0 kernel/rcu/tree.c:2105
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
NMI backtrace for cpu 0
CPU: 0 PID: 8759 Comm: syz-executor2 Not tainted 5.0.0-rc4+ #51
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
nmi_cpu_backtrace.cold+0x63/0xa4 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x1be/0x236 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
rcu_dump_cpu_stacks+0x183/0x1cf kernel/rcu/tree.c:1211
print_cpu_stall kernel/rcu/tree.c:1348 [inline]
check_cpu_stall kernel/rcu/tree.c:1422 [inline]
rcu_pending kernel/rcu/tree.c:3018 [inline]
rcu_check_callbacks.cold+0x500/0xa4a kernel/rcu/tree.c:2521
update_process_times+0x32/0x80 kernel/time/timer.c:1635
tick_sched_handle+0xa2/0x190 kernel/time/tick-sched.c:161
tick_sched_timer+0x47/0x130 kernel/time/tick-sched.c:1271
__run_hrtimer kernel/time/hrtimer.c:1389 [inline]
__hrtimer_run_queues+0x33e/0xde0 kernel/time/hrtimer.c:1451
hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1509
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1035 [inline]
smp_apic_timer_interrupt+0x120/0x570 arch/x86/kernel/apic/apic.c:1060
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
</IRQ>
RIP: 0010:__read_once_size include/linux/compiler.h:193 [inline]
RIP: 0010:queued_write_lock_slowpath+0x13e/0x290 kernel/locking/qrwlock.c:86
Code: 00 00 fc ff df 4c 8d 2c 01 41 83 c7 03 41 0f b6 45 00 41 38 c7 7c 08 84 c0 0f 85 0c 01 00 00 8b 03 3d 00 01 00 00 74 1a f3 90 <41> 0f b6 55 00 41 38 d7 7c eb 84 d2 74 e7 48 89 df e8 6c 0f 4f 00
RSP: 0018:
ffff88805f117bd8 EFLAGS:
00000206 ORIG_RAX:
ffffffffffffff13
RAX:
0000000000000300 RBX:
ffffffff89413ba0 RCX:
1ffffffff1282774
RDX:
0000000000000000 RSI:
0000000000000004 RDI:
ffffffff89413ba0
RBP:
ffff88805f117c70 R08:
1ffffffff1282774 R09:
fffffbfff1282775
R10:
fffffbfff1282774 R11:
ffffffff89413ba3 R12:
00000000000000ff
R13:
fffffbfff1282774 R14:
1ffff1100be22f7d R15:
0000000000000003
queued_write_lock include/asm-generic/qrwlock.h:104 [inline]
do_raw_write_lock+0x1d6/0x290 kernel/locking/spinlock_debug.c:203
__raw_write_lock_bh include/linux/rwlock_api_smp.h:204 [inline]
_raw_write_lock_bh+0x3b/0x50 kernel/locking/spinlock.c:312
x25_insert_socket+0x21/0xe0 net/x25/af_x25.c:267
x25_bind+0x273/0x340 net/x25/af_x25.c:705
__sys_bind+0x23f/0x290 net/socket.c:1505
__do_sys_bind net/socket.c:1516 [inline]
__se_sys_bind net/socket.c:1514 [inline]
__x64_sys_bind+0x73/0xb0 net/socket.c:1514
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e39
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:
00007fafccd0dc78 EFLAGS:
00000246 ORIG_RAX:
0000000000000031
RAX:
ffffffffffffffda RBX:
0000000000000003 RCX:
0000000000457e39
RDX:
0000000000000012 RSI:
0000000020000240 RDI:
0000000000000004
RBP:
000000000073bf00 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000246 R12:
00007fafccd0e6d4
R13:
00000000004bdf8b R14:
00000000004ce4b8 R15:
00000000ffffffff
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 8752 Comm: syz-executor4 Not tainted 5.0.0-rc4+ #51
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:__x25_find_socket+0x78/0x120 net/x25/af_x25.c:328
Code: 89 f8 48 c1 e8 03 80 3c 18 00 0f 85 a6 00 00 00 4d 8b 64 24 68 4d 85 e4 74 7f e8 03 97 3d fb 49 83 ec 68 74 74 e8 f8 96 3d fb <49> 8d bc 24 88 04 00 00 48 89 f8 48 c1 e8 03 0f b6 04 18 84 c0 74
RSP: 0018:
ffff8880639efc58 EFLAGS:
00000246
RAX:
0000000000040000 RBX:
dffffc0000000000 RCX:
ffffc9000e677000
RDX:
0000000000040000 RSI:
ffffffff863244b8 RDI:
ffff88806a764628
RBP:
ffff8880639efc80 R08:
ffff8880a80d05c0 R09:
fffffbfff1282775
R10:
fffffbfff1282774 R11:
ffffffff89413ba3 R12:
ffff88806a7645c0
R13:
0000000000000001 R14:
ffff88809f29ac00 R15:
0000000000000000
FS:
00007fe8d0c58700(0000) GS:
ffff8880ae900000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000001b32823000 CR3:
00000000672eb000 CR4:
00000000001406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
x25_new_lci net/x25/af_x25.c:357 [inline]
x25_connect+0x374/0xdf0 net/x25/af_x25.c:786
__sys_connect+0x266/0x330 net/socket.c:1686
__do_sys_connect net/socket.c:1697 [inline]
__se_sys_connect net/socket.c:1694 [inline]
__x64_sys_connect+0x73/0xb0 net/socket.c:1694
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e39
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:
00007fe8d0c57c78 EFLAGS:
00000246 ORIG_RAX:
000000000000002a
RAX:
ffffffffffffffda RBX:
0000000000000003 RCX:
0000000000457e39
RDX:
0000000000000012 RSI:
0000000020000200 RDI:
0000000000000004
RBP:
000000000073bf00 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000246 R12:
00007fe8d0c586d4
R13:
00000000004be378 R14:
00000000004ceb00 R15:
00000000ffffffff
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Andrew Hendry <andrew.hendry@gmail.com>
Cc: linux-x25@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Tue, 8 Dec 2015 15:21:05 +0000 (16:21 +0100)]
mfd: as3722: Mark PM functions as __maybe_unused
commit
a7b956fd38dd217dd78e3058110929f5ac914df1 upstream.
The newly introduced as3722_i2c_suspend/resume functions are built
unconditionally, but only used when power management is enabled,
so we get a warning otherwise:
drivers/mfd/as3722.c:427:12: warning: 'as3722_i2c_suspend' defined but not used [-Wunused-function]
drivers/mfd/as3722.c:438:12: warning: 'as3722_i2c_resume' defined but not used [-Wunused-function]
This marks them both as __maybe_unused, which avoids an ugly #ifdef
and gives us best compile-time coverage. When they are unused, the
compiler will silently drop the functions from its output.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes:
35deff7eb212 ("mfd: as3722: Handle interrupts on suspend")
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jon Hunter [Fri, 20 Nov 2015 10:51:00 +0000 (10:51 +0000)]
mfd: as3722: Handle interrupts on suspend
commit
35deff7eb212b661b32177b6043f674fde6314d7 upstream.
The as3722 device is registered as an irqchip and the as3722-rtc interrupt
is one of it's interrupt sources. When using the as3722-rtc as a wake-up
device from suspend, the following is seen:
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: suspend of devices complete after 161.119 msecs
PM: late suspend of devices complete after 1.048 msecs
PM: noirq suspend of devices complete after 0.756 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Entering suspend state LP1
Enabling non-boot CPUs ...
CPU1 is up
CPU2 is up
CPU3 is up
PM: noirq resume of devices complete after 0.487 msecs
as3722 4-0040: Failed to read IRQ status: -16
as3722 4-0040: Failed to read IRQ status: -16
as3722 4-0040: Failed to read IRQ status: -16
as3722 4-0040: Failed to read IRQ status: -16
...
The reason why the as3722 interrupt status cannot be read is because the
as3722 interrupt is not masked during suspend and when the as3722-rtc
interrupt occurs, to wake-up the device, the interrupt is seen before the
i2c controller has been resumed in order to read the as3722 interrupt
status.
The as3722-rtc driver sets it's interrupt as a wake-up source during
suspend, which gets propagated to the parent as3722 interrupt. However,
the as3722-rtc driver cannot disable it's interrupt during suspend
otherwise we would never be woken up and so the as3722 must disable it's
interrupt instead.
Fix this by disabling the as3722 interrupt during suspend. To ensure that
a wake-up event from the as3722 is not missing, enable the as3722 interrupt
as a wake-up source before disabling the interrupt on entering suspend.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jann Horn [Sat, 26 Jan 2019 00:54:33 +0000 (01:54 +0100)]
kvm: fix kvm_ioctl_create_device() reference counting (CVE-2019-6974)
commit
cfa39381173d5f969daf43582c95ad679189cbc9 upstream.
kvm_ioctl_create_device() does the following:
1. creates a device that holds a reference to the VM object (with a borrowed
reference, the VM's refcount has not been bumped yet)
2. initializes the device
3. transfers the reference to the device to the caller's file descriptor table
4. calls kvm_get_kvm() to turn the borrowed reference to the VM into a real
reference
The ownership transfer in step 3 must not happen before the reference to the VM
becomes a proper, non-borrowed reference, which only happens in step 4.
After step 3, an attacker can close the file descriptor and drop the borrowed
reference, which can cause the refcount of the kvm object to drop to zero.
This means that we need to grab a reference for the device before
anon_inode_getfd(), otherwise the VM can disappear from under us.
Fixes:
852b6d57dc7f ("kvm: add device control API")
Cc: stable@kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
chenzefeng (A) [Wed, 20 Feb 2019 12:37:54 +0000 (12:37 +0000)]
x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32
Signed-off-by: chenzefeng <chenzefeng2@huawei.com>
On x86-64, for 32-bit PC-relacive branches, we can generate PLT32
relocation, instead of PC32 relocation. and R_X86_64_PLT32 can be
treated the same as R_X86_64_PC32 since linux kernel doesn't use PLT.
commit
b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") been
fixed for the module loading, but not fixed for livepatch relocation,
which will fail to load livepatch with the error message as follow:
relocation failed for symbol <symbol name> at <symbol address>
This issue only effacted the kernel version from 4.0 to 4.6, becauce the
function klp_write_module_reloc is introduced by: commit
b700e7f03df5
("livepatch: kernel: add support for live patching") and deleted by:
commit
425595a7fc20 ("livepatch: reuse module loader code to write
relocations")
Signed-off-by: chenzefeng <chenzefeng2@huawei.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lorenzo Bianconi [Wed, 6 Feb 2019 18:18:04 +0000 (19:18 +0100)]
net: ipv4: use a dedicated counter for icmp_v4 redirect packets
[ Upstream commit
c09551c6ff7fe16a79a42133bcecba5fc2fc3291 ]
According to the algorithm described in the comment block at the
beginning of ip_rt_send_redirect, the host should try to send
'ip_rt_redirect_number' ICMP redirect packets with an exponential
backoff and then stop sending them at all assuming that the destination
ignores redirects.
If the device has previously sent some ICMP error packets that are
rate-limited (e.g TTL expired) and continues to receive traffic,
the redirect packets will never be transmitted. This happens since
peer->rate_tokens will be typically greater than 'ip_rt_redirect_number'
and so it will never be reset even if the redirect silence timeout
(ip_rt_redirect_silence) has elapsed without receiving any packet
requiring redirects.
Fix it by using a dedicated counter for the number of ICMP redirect
packets that has been sent by the host
I have not been able to identify a given commit that introduced the
issue since ip_rt_send_redirect implements the same rate-limiting
algorithm from commit
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jose Abreu [Mon, 18 Feb 2019 13:35:03 +0000 (14:35 +0100)]
net: stmmac: Fix a race in EEE enable callback
[ Upstream commit
8a7493e58ad688eb23b81e45461c5d314f4402f1 ]
We are saving the status of EEE even before we try to enable it. This
leads to a race with XMIT function that tries to arm EEE timer before we
set it up.
Fix this by only saving the EEE parameters after all operations are
performed with success.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Fixes:
d765955d2ae0 ("stmmac: add the Energy Efficient Ethernet support")
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Thu, 7 Feb 2019 20:27:38 +0000 (12:27 -0800)]
vxlan: test dev->flags & IFF_UP before calling netif_rx()
[ Upstream commit
4179cb5a4c924cd233eaadd081882425bc98f44e ]
netif_rx() must be called under a strict contract.
At device dismantle phase, core networking clears IFF_UP
and flush_all_backlogs() is called after rcu grace period
to make sure no incoming packet might be in a cpu backlog
and still referencing the device.
Most drivers call netif_rx() from their interrupt handler,
and since the interrupts are disabled at device dismantle,
netif_rx() does not have to check dev->flags & IFF_UP
Virtual drivers do not have this guarantee, and must
therefore make the check themselves.
Otherwise we risk use-after-free and/or crashes.
Note this patch also fixes a small issue that came
with commit
ce6502a8f957 ("vxlan: fix a use after free
in vxlan_encap_bypass"), since the dev->stats.rx_dropped
change was done on the wrong device.
Fixes:
d342894c5d2f ("vxlan: virtual extensible lan")
Fixes:
ce6502a8f957 ("vxlan: fix a use after free in vxlan_encap_bypass")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Petr Machata <petrm@mellanox.com>
Cc: Ido Schimmel <idosch@mellanox.com>
Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
Cc: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Fri, 15 Feb 2019 21:36:20 +0000 (13:36 -0800)]
tcp: clear icsk_backoff in tcp_write_queue_purge()
[ Upstream commit
04c03114be82194d4a4858d41dba8e286ad1787c ]
soukjin bae reported a crash in tcp_v4_err() handling
ICMP_DEST_UNREACH after tcp_write_queue_head(sk)
returned a NULL pointer.
Current logic should have prevented this :
if (seq != tp->snd_una || !icsk->icsk_retransmits ||
!icsk->icsk_backoff || fastopen)
break;
Problem is the write queue might have been purged
and icsk_backoff has not been cleared.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: soukjin bae <soukjin.bae@samsung.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Duyck [Fri, 15 Feb 2019 22:44:18 +0000 (14:44 -0800)]
net: Do not allocate page fragments that are not skb aligned
[ Upstream commit
3bed3cc4156eedf652b4df72bdb35d4f1a2a739d ]
This patch addresses the fact that there are drivers, specifically tun,
that will call into the network page fragment allocators with buffer sizes
that are not cache aligned. Doing this could result in data alignment
and DMA performance issues as these fragment pools are also shared with the
skb allocator and any other devices that will use napi_alloc_frags or
netdev_alloc_frags.
Fixes:
ffde7328a36d ("net: Split netdev_alloc_frag into __alloc_page_frag and add __napi_alloc_frag")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Fri, 15 Feb 2019 21:36:21 +0000 (13:36 -0800)]
tcp: tcp_v4_err() should be more careful
[ Upstream commit
2c4cc9712364c051b1de2d175d5fbea6be948ebf ]
ICMP handlers are not very often stressed, we should
make them more resilient to bugs that might surface in
the future.
If there is no packet in retransmit queue, we should
avoid a NULL deref.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: soukjin bae <soukjin.bae@samsung.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Sat, 16 Feb 2019 21:44:39 +0000 (13:44 -0800)]
net: Add header for usage of fls64()
[ Upstream commit
8681ef1f3d295bd3600315325f3b3396d76d02f6 ]
Fixes:
3b89ea9c5902 ("net: Fix for_each_netdev_feature on Big endian")
Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kai-Heng Feng [Tue, 19 Feb 2019 15:45:29 +0000 (23:45 +0800)]
sky2: Increase D3 delay again
[ Upstream commit
1765f5dcd00963e33f1b8a4e0f34061fbc0e2f7f ]
Another platform requires even longer delay to make the device work
correctly after S3.
So increase the delay to 300ms.
BugLink: https://bugs.launchpad.net/bugs/1798921
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hauke Mehrtens [Fri, 15 Feb 2019 16:58:54 +0000 (17:58 +0100)]
net: Fix for_each_netdev_feature on Big endian
[ Upstream commit
3b89ea9c5902acccdbbdec307c85edd1bf52515e ]
The features attribute is of type u64 and stored in the native endianes on
the system. The for_each_set_bit() macro takes a pointer to a 32 bit array
and goes over the bits in this area. On little Endian systems this also
works with an u64 as the most significant bit is on the highest address,
but on big endian the words are swapped. When we expect bit 15 here we get
bit 47 (15 + 32).
This patch converts it more or less to its own for_each_set_bit()
implementation which works on 64 bit integers directly. This is then
completely in host endianness and should work like expected.
Fixes:
fd867d51f ("net/core: generic support for disabling netdev features down stack")
Signed-off-by: Hauke Mehrtens <hauke.mehrtens@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei Yongjun [Wed, 26 Dec 2018 11:28:24 +0000 (11:28 +0000)]
hwmon: (lm80) Fix missing unlock on error in set_fan_div()
[ Upstream commit
07bd14ccc3049f9c0147a91a4227a571f981601a ]
Add the missing unlock before return from function set_fan_div()
in the error handling case.
Fixes:
c9c63915519b ("hwmon: (lm80) fix a missing check of the status of SMBus read")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paolo Abeni [Thu, 7 Feb 2019 13:13:18 +0000 (14:13 +0100)]
vsock: cope with memory allocation failure at socket creation time
[ Upstream commit
225d9464268599a5b4d094d02ec17808e44c7553 ]
In the unlikely event that the kmalloc call in vmci_transport_socket_init()
fails, we end-up calling vmci_transport_destruct() with a NULL vmci_trans()
and oopsing.
This change addresses the above explicitly checking for zero vmci_trans()
at destruction time.
Reported-by: Xiumei Mu <xmu@redhat.com>
Fixes:
d021c344051a ("VSOCK: Introduce VM Sockets")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Jorgen Hansen <jhansen@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhiqiang Liu [Mon, 11 Feb 2019 02:57:46 +0000 (10:57 +0800)]
net: fix IPv6 prefix route residue
[ Upstream commit
e75913c93f7cd5f338ab373c34c93a655bd309cb ]
Follow those steps:
# ip addr add 2001:123::1/32 dev eth0
# ip addr add 2001:123:456::2/64 dev eth0
# ip addr del 2001:123::1/32 dev eth0
# ip addr del 2001:123:456::2/64 dev eth0
and then prefix route of 2001:123::1/32 will still exist.
This is because ipv6_prefix_equal in check_cleanup_prefix_route
func does not check whether two IPv6 addresses have the same
prefix length. If the prefix of one address starts with another
shorter address prefix, even though their prefix lengths are
different, the return value of ipv6_prefix_equal is true.
Here I add a check of whether two addresses have the same prefix
to decide whether their prefixes are equal.
Fixes:
5b84efecb7d9 ("ipv6 addrconf: don't cleanup prefix route for IFA_F_NOPREFIXROUTE")
Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Reported-by: Wenhao Zhang <zhangwenhao8@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Kroah-Hartman [Wed, 20 Feb 2019 09:13:24 +0000 (10:13 +0100)]
Linux 4.4.175
Hauke Mehrtens [Mon, 12 Feb 2018 22:59:51 +0000 (23:59 +0100)]
uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define
commit
da360299b6734135a5f66d7db458dcc7801c826a upstream.
This fixes a compile problem of some user space applications by not
including linux/libc-compat.h in uapi/if_ether.h.
linux/libc-compat.h checks which "features" the header files, included
from the libc, provide to make the Linux kernel uapi header files only
provide no conflicting structures and enums. If a user application mixes
kernel headers and libc headers it could happen that linux/libc-compat.h
gets included too early where not all other libc headers are included
yet. Then the linux/libc-compat.h would not prevent all the
redefinitions and we run into compile problems.
This patch removes the include of linux/libc-compat.h from
uapi/if_ether.h to fix the recently introduced case, but not all as this
is more or less impossible.
It is no problem to do the check directly in the if_ether.h file and not
in libc-compat.h as this does not need any fancy glibc header detection
as glibc never provided struct ethhdr and should define
__UAPI_DEF_ETHHDR by them self when they will provide this.
The following test program did not compile correctly any more:
#include <linux/if_ether.h>
#include <netinet/in.h>
#include <linux/in.h>
int main(void)
{
return 0;
}
Fixes:
6926e041a892 ("uapi/if_ether.h: prevent redefinition of struct ethhdr")
Reported-by: Guillaume Nault <g.nault@alphalink.fr>
Cc: <stable@vger.kernel.org> # 4.15
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian Lamparter [Mon, 21 May 2018 20:57:37 +0000 (22:57 +0200)]
pinctrl: msm: fix gpio-hog related boot issues
commit
a86caa9ba5d70696ceb35d1d39caa20d8b641387 upstream.
Sven Eckelmann reported an issue with the current IPQ4019 pinctrl.
Setting up any gpio-hog in the device-tree for his device would
"kill the bootup completely":
| [ 0.477838] msm_serial
78af000.serial: could not find pctldev for node /soc/pinctrl@
1000000/serial_pinmux, deferring probe
| [ 0.499828] spi_qup
78b5000.spi: could not find pctldev for node /soc/pinctrl@
1000000/spi_0_pinmux, deferring probe
| [ 1.298883] requesting hog GPIO enable USB2 power (chip
1000000.pinctrl, offset 58) failed, -517
| [ 1.299609] gpiochip_add_data: GPIOs 0..99 (
1000000.pinctrl) failed to register
| [ 1.308589] ipq4019-pinctrl
1000000.pinctrl: Failed register gpiochip
| [ 1.316586] msm_serial
78af000.serial: could not find pctldev for node /soc/pinctrl@
1000000/serial_pinmux, deferring probe
| [ 1.322415] spi_qup
78b5000.spi: could not find pctldev for node /soc/pinctrl@
1000000/spi_0_pinmux, deferri
This was also verified on a RT-AC58U (IPQ4018) which would
no longer boot, if a gpio-hog was specified. (Tried forcing
the USB LED PIN (GPIO0) to high.).
The problem is that Pinctrl+GPIO registration is currently
peformed in the following order in pinctrl-msm.c:
1. pinctrl_register()
2. gpiochip_add()
3. gpiochip_add_pin_range()
The actual error code -517 == -EPROBE_DEFER is coming from
pinctrl_get_device_gpio_range(), which is called through:
gpiochip_add
of_gpiochip_add
of_gpiochip_scan_gpios
gpiod_hog
gpiochip_request_own_desc
__gpiod_request
chip->request
gpiochip_generic_request
pinctrl_gpio_request
pinctrl_get_device_gpio_range
pinctrl_get_device_gpio_range() is unable to find any valid
pin ranges, since nothing has been added to the pinctrldev_list yet.
so the range can't be found, and the operation fails with -EPROBE_DEFER.
This patch fixes the issue by adding the "gpio-ranges" property to
the pinctrl device node of all upstream Qcom SoC. The pin ranges are
then added by the gpio core.
In order to remain compatible with older, existing DTs (and ACPI)
a check for the "gpio-ranges" property has been added to
msm_gpio_init(). This prevents the driver of adding the same entry
to the pinctrldev_list twice.
Reported-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Tested-by: Sven Eckelmann <sven.eckelmann@openmesh.com> [ipq4019]
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John Youn [Fri, 4 Nov 2016 00:55:45 +0000 (17:55 -0700)]
usb: dwc2: Remove unnecessary kfree
commit
cd4b1e34655d46950c065d9284b596cd8d7b28cd upstream.
This shouldn't be freed by the HCD as it is owned by the core and
allocated with devm_kzalloc.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Wed, 19 Apr 2017 16:59:26 +0000 (09:59 -0700)]
kaweth: use skb_cow_head() to deal with cloned skbs
commit
39fba7835aacda65284a86e611774cbba71dac20 upstream.
We can use skb_cow_head() to properly deal with clones,
especially the ones coming from TCP stack that allow their head being
modified. This avoids a copy.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: James Hughes <james.hughes@raspberrypi.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Wed, 19 Apr 2017 16:59:25 +0000 (09:59 -0700)]
ch9200: use skb_cow_head() to deal with cloned skbs
commit
6bc6895bdd6744e0136eaa4a11fbdb20a7db4e40 upstream.
We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.
skb_cow_head() is the proper helper to deal with this.
Fixes:
4a476bd6d1d9 ("usbnet: New driver for QinHeng CH9200 devices")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: James Hughes <james.hughes@raspberrypi.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hughes [Wed, 19 Apr 2017 10:13:40 +0000 (11:13 +0100)]
smsc95xx: Use skb_cow_head to deal with cloned skbs
commit
e9156cd26a495a18706e796f02a81fee41ec14f4 upstream.
The driver was failing to check that the SKB wasn't cloned
before adding checksum data.
Replace existing handling to extend/copy the header buffer
with skb_cow_head.
Signed-off-by: James Hughes <james.hughes@raspberrypi.org>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Woojung Huh <Woojung.Huh@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nikos Tsironis [Thu, 14 Feb 2019 18:38:47 +0000 (20:38 +0200)]
dm thin: fix bug where bio that overwrites thin block ignores FUA
commit
4ae280b4ee3463fa57bbe6eede26b97daff8a0f1 upstream.
When provisioning a new data block for a virtual block, either because
the block was previously unallocated or because we are breaking sharing,
if the whole block of data is being overwritten the bio that triggered
the provisioning is issued immediately, skipping copying or zeroing of
the data block.
When this bio completes the new mapping is inserted in to the pool's
metadata by process_prepared_mapping(), where the bio completion is
signaled to the upper layers.
This completion is signaled without first committing the metadata. If
the bio in question has the REQ_FUA flag set and the system crashes
right after its completion and before the next metadata commit, then the
write is lost despite the REQ_FUA flag requiring that I/O completion for
this request must only be signaled after the data has been committed to
non-volatile storage.
Fix this by deferring the completion of overwrite bios, with the REQ_FUA
flag set, until after the metadata has been committed.
Cc: stable@vger.kernel.org
Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Acked-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Tue, 12 Feb 2019 13:28:03 +0000 (14:28 +0100)]
x86/a.out: Clear the dump structure initially
commit
10970e1b4be9c74fce8ab6e3c34a7d718f063f2c upstream.
dump_thread32() in aout_core_dump() does not clear the user32 structure
allocated on the stack as the first thing on function entry.
As a result, the dump.u_comm, dump.u_ar0 and dump.signal which get
assigned before the clearing, get overwritten.
Rename that function to fill_dump() to make it clear what it does and
call it first thing.
This was caught while staring at a patch by Derek Robson
<robsonde@gmail.com>.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Derek Robson <robsonde@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Matz <matz@suse.de>
Cc: x86@kernel.org
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20190202005512.3144-1-robsonde@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric W. Biederman [Tue, 12 Feb 2019 05:27:42 +0000 (23:27 -0600)]
signal: Restore the stop PTRACE_EVENT_EXIT
commit
cf43a757fd49442bc38f76088b70c2299eed2c2f upstream.
In the middle of do_exit() there is there is a call
"ptrace_event(PTRACE_EVENT_EXIT, code);" That call places the process
in TACKED_TRACED aka "(TASK_WAKEKILL | __TASK_TRACED)" and waits for
for the debugger to release the task or SIGKILL to be delivered.
Skipping past dequeue_signal when we know a fatal signal has already
been delivered resulted in SIGKILL remaining pending and
TIF_SIGPENDING remaining set. This in turn caused the
scheduler to not sleep in PTACE_EVENT_EXIT as it figured
a fatal signal was pending. This also caused ptrace_freeze_traced
in ptrace_check_attach to fail because it left a per thread
SIGKILL pending which is what fatal_signal_pending tests for.
This difference in signal state caused strace to report
strace: Exit of unknown pid NNNNN ignored
Therefore update the signal handling state like dequeue_signal
would when removing a per thread SIGKILL, by removing SIGKILL
from the per thread signal mask and clearing TIF_SIGPENDING.
Acked-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Ivan Delalande <colona@arista.com>
Cc: stable@vger.kernel.org
Fixes:
35634ffa1751 ("signal: Always notice exiting tasks")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hedi Berriche [Wed, 13 Feb 2019 19:34:13 +0000 (19:34 +0000)]
x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls
commit
f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream.
Calls into UV firmware must be protected against concurrency, expose the
efi_runtime_lock to the UV platform, and use it to serialise UV BIOS
calls.
Signed-off-by: Hedi Berriche <hedi.berriche@hpe.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Russ Anderson <rja@hpe.com>
Reviewed-by: Dimitri Sivanich <sivanich@hpe.com>
Reviewed-by: Mike Travis <mike.travis@hpe.com>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: Bhupesh Sharma <bhsharma@redhat.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-efi <linux-efi@vger.kernel.org>
Cc: platform-driver-x86@vger.kernel.org
Cc: stable@vger.kernel.org # v4.9+
Cc: Steve Wahl <steve.wahl@hpe.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berriche@hpe.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andreas Ziegler [Wed, 16 Jan 2019 14:16:29 +0000 (15:16 +0100)]
tracing/uprobes: Fix output for multiple string arguments
commit
0722069a5374b904ec1a67f91249f90e1cfae259 upstream.
When printing multiple uprobe arguments as strings the output for the
earlier arguments would also include all later string arguments.
This is best explained in an example:
Consider adding a uprobe to a function receiving two strings as
parameters which is at offset 0xa0 in strlib.so and we want to print
both parameters when the uprobe is hit (on x86_64):
$ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
/sys/kernel/debug/tracing/uprobe_events
When the function is called as func("foo", "bar") and we hit the probe,
the trace file shows a line like the following:
[...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
Note the extra "bar" printed as part of arg1. This behaviour stacks up
for additional string arguments.
The strings are stored in a dynamically growing part of the uprobe
buffer by fetch_store_string() after copying them from userspace via
strncpy_from_user(). The return value of strncpy_from_user() is then
directly used as the required size for the string. However, this does
not take the terminating null byte into account as the documentation
for strncpy_from_user() cleary states that it "[...] returns the
length of the string (not including the trailing NUL)" even though the
null byte will be copied to the destination.
Therefore, subsequent calls to fetch_store_string() will overwrite
the terminating null byte of the most recently fetched string with
the first character of the current string, leading to the
"accumulation" of strings in earlier arguments in the output.
Fix this by incrementing the return value of strncpy_from_user() by
one if we did not hit the maximum buffer size.
Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de
Cc: Ingo Molnar <mingo@redhat.com>
Cc: stable@vger.kernel.org
Fixes:
5baaa59ef09e ("tracing/probes: Implement 'memory' fetch method for uprobes")
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Meelis Roos [Fri, 12 Oct 2018 09:27:51 +0000 (12:27 +0300)]
alpha: Fix Eiger NR_IRQS to 128
commit
bfc913682464f45bc4d6044084e370f9048de9d5 upstream.
Eiger machine vector definition has nr_irqs 128, and working 2.6.26
boot shows SCSI getting IRQ-s 64 and 65. Current kernel boot fails
because Symbios SCSI fails to request IRQ-s and does not find the disks.
It has been broken at least since 3.18 - the earliest I could test with
my gcc-5.
The headers have moved around and possibly another order of defines has
worked in the past - but since 128 seems to be correct and used, fix
arch/alpha/include/asm/irq.h to have NR_IRQS=128 for Eiger.
This fixes 4.19-rc7 boot on my Force Flexor A264 (Eiger subarch).
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergei Trofimovich [Mon, 31 Dec 2018 11:53:55 +0000 (11:53 +0000)]
alpha: fix page fault handling for r16-r18 targets
commit
491af60ffb848b59e82f7c9145833222e0bf27a5 upstream.
Fix page fault handling code to fixup r16-r18 registers.
Before the patch code had off-by-two registers bug.
This bug caused overwriting of ps,pc,gp registers instead
of fixing intended r16,r17,r18 (see `struct pt_regs`).
More details:
Initially Dmitry noticed a kernel bug as a failure
on strace test suite. Test passes unmapped userspace
pointer to io_submit:
```c
#include <err.h>
#include <unistd.h>
#include <sys/mman.h>
#include <asm/unistd.h>
int main(void)
{
unsigned long ctx = 0;
if (syscall(__NR_io_setup, 1, &ctx))
err(1, "io_setup");
const size_t page_size = sysconf(_SC_PAGESIZE);
const size_t size = page_size * 2;
void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (MAP_FAILED == ptr)
err(1, "mmap(%zu)", size);
if (munmap(ptr, size))
err(1, "munmap");
syscall(__NR_io_submit, ctx, 1, ptr + page_size);
syscall(__NR_io_destroy, ctx);
return 0;
}
```
Running this test causes kernel to crash when handling page fault:
```
Unable to handle kernel paging request at virtual address
ffffffffffff9468
CPU 3
aio(26027): Oops 0
pc = [<
fffffc00004eddf8>] ra = [<
fffffc00004edd5c>] ps = 0000 Not tainted
pc is at sys_io_submit+0x108/0x200
ra is at sys_io_submit+0x6c/0x200
v0 =
fffffc00c58e6300 t0 =
fffffffffffffff2 t1 =
000002000025e000
t2 =
fffffc01f159fef8 t3 =
fffffc0001009640 t4 =
fffffc0000e0f6e0
t5 =
0000020001002e9e t6 =
4c41564e49452031 t7 =
fffffc01f159c000
s0 =
0000000000000002 s1 =
000002000025e000 s2 =
0000000000000000
s3 =
0000000000000000 s4 =
0000000000000000 s5 =
fffffffffffffff2
s6 =
fffffc00c58e6300
a0 =
fffffc00c58e6300 a1 =
0000000000000000 a2 =
000002000025e000
a3 =
00000200001ac260 a4 =
00000200001ac1e8 a5 =
0000000000000001
t8 =
0000000000000008 t9 =
000000011f8bce30 t10=
00000200001ac440
t11=
0000000000000000 pv =
fffffc00006fd320 at =
0000000000000000
gp =
0000000000000000 sp =
00000000265fd174
Disabling lock debugging due to kernel taint
Trace:
[<
fffffc0000311404>] entSys+0xa4/0xc0
```
Here `gp` has invalid value. `gp is s overwritten by a fixup for the
following page fault handler in `io_submit` syscall handler:
```
__se_sys_io_submit
...
ldq a1,0(t1)
bne t0,4280 <__se_sys_io_submit+0x180>
```
After a page fault `t0` should contain -EFALUT and `a1` is 0.
Instead `gp` was overwritten in place of `a1`.
This happens due to a off-by-two bug in `dpf_reg()` for `r16-r18`
(aka `a0-a2`).
I think the bug went unnoticed for a long time as `gp` is one
of scratch registers. Any kernel function call would re-calculate `gp`.
Dmitry tracked down the bug origin back to 2.1.32 kernel version
where trap_a{0,1,2} fields were inserted into struct pt_regs.
And even before that `dpf_reg()` contained off-by-one error.
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: linux-alpha@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reported-and-reviewed-by: "Dmitry V. Levin" <ldv@altlinux.org>
Cc: stable@vger.kernel.org # v2.1.32+
Bug: https://bugs.gentoo.org/672040
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matti Kurkela [Fri, 8 Feb 2019 07:49:23 +0000 (23:49 -0800)]
Input: elantech - enable 3rd button support on Fujitsu CELSIUS H780
commit
e8b22d0a329f0fb5c7ef95406872d268f01ee3b1 upstream.
Like Fujitsu CELSIUS H760, the H780 also has a three-button Elantech
touchpad, but the driver needs to be told so to enable the middle touchpad
button.
The elantech_dmi_force_crc_enabled quirk was not necessary with the H780.
Also document the fw_version and caps values detected for both H760 and
H780 models.
Signed-off-by: Matti Kurkela <Matti.Kurkela@iki.fi>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Bakker [Wed, 6 Feb 2019 18:45:37 +0000 (10:45 -0800)]
Input: bma150 - register input device after setting private data
commit
90cc55f067f6ca0e64e5e52883ece47d8af7b67b upstream.
Otherwise we introduce a race condition where userspace can request input
before we're ready leading to null pointer dereference such as
input: bma150 as /devices/platform/i2c-gpio-2/i2c-5/5-0038/input/input3
Unable to handle kernel NULL pointer dereference at virtual address
00000018
pgd = (ptrval)
[
00000018] *pgd=
55dac831, *pte=
00000000, *ppte=
00000000
Internal error: Oops: 17 [#1] PREEMPT ARM
Modules linked in: bma150 input_polldev [last unloaded: bma150]
CPU: 0 PID: 2870 Comm: accelerometer Not tainted 5.0.0-rc3-dirty #46
Hardware name: Samsung S5PC110/S5PV210-based board
PC is at input_event+0x8/0x60
LR is at bma150_report_xyz+0x9c/0xe0 [bma150]
pc : [<
80450f70>] lr : [<
7f0a614c>] psr:
800d0013
sp :
a4c1fd78 ip :
00000081 fp :
00020000
r10:
00000000 r9 :
a5e2944c r8 :
a7455000
r7 :
00000016 r6 :
00000101 r5 :
a7617940 r4 :
80909048
r3 :
fffffff2 r2 :
00000000 r1 :
00000003 r0 :
00000000
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control:
10c5387d Table:
54e34019 DAC:
00000051
Process accelerometer (pid: 2870, stack limit = 0x(ptrval))
Stackck: (0xa4c1fd78 to 0xa4c20000)
fd60:
fffffff3 fc813f6c
fd80:
40410581 d7530ce3 a5e2817c a7617f00 a5e29404 a5e2817c 00000000 7f008324
fda0:
a5e28000 8044f59c a5fdd9d0 a5e2945c a46a4a00 a5e29668 a7455000 80454f10
fdc0:
80909048 a5e29668 a5fdd9d0 a46a4a00 806316d0 00000000 a46a4a00 801df5f0
fde0:
00000000 d7530ce3 a4c1fec0 a46a4a00 00000000 a5fdd9d0 a46a4a08 801df53c
fe00:
00000000 801d74bc a4c1fec0 00000000 a4c1ff70 00000000 a7038da8 00000000
fe20:
a46a4a00 801e91fc a411bbe0 801f2e88 00000004 00000000 80909048 00000041
fe40:
00000000 00020000 00000000 dead4ead a6a88da0 00000000 ffffe000 806fcae8
fe60:
a4c1fec8 00000000 80909048 00000002 a5fdd9d0 a7660110 a411bab0 00000001
fe80:
dead4ead ffffffff ffffffff a4c1fe8c a4c1fe8c d7530ce3 20000013 80909048
fea0:
80909048 a4c1ff70 00000001 fffff000 a4c1e000 00000005 00026038 801eabd8
fec0:
a7660110 a411bab0 b9394901 00000006 a696201b 76fb3000 00000000 a7039720
fee0:
a5fdd9d0 00000101 00000002 00000096 00000000 00000000 00000000 a4c1ff00
ff00:
a6b310f4 805cb174 a6b310f4 00000010 00000fe0 00000010 a4c1e000 d7530ce3
ff20:
00000003 a5f41400 a5f41424 00000000 a6962000 00000000 00000003 00000002
ff40:
ffffff9c 000a0000 80909048 d7530ce3 a6962000 00000003 80909048 ffffff9c
ff60:
a6962000 801d890c 00000000 00000000 00020000 a7590000 00000004 00000100
ff80:
00000001 d7530ce3 000288b8 00026320 000288b8 00000005 80101204 a4c1e000
ffa0:
00000005 80101000 000288b8 00026320 000288b8 000a0000 00000000 00000000
ffc0:
000288b8 00026320 000288b8 00000005 7eef3bac 000264e8 00028ad8 00026038
ffe0:
00000005 7eef3300 76f76e91 76f78546 800d0030 000288b8 00000000 00000000
[<
80450f70>] (input_event) from [<
a5e2817c>] (0xa5e2817c)
Code:
e1a08148 eaffffa8 e351001f 812fff1e (
e590c018)
---[ end trace
1c691ee85f2ff243 ]---
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Manuel Reinhardt [Thu, 31 Jan 2019 14:32:35 +0000 (15:32 +0100)]
ALSA: usb-audio: Fix implicit fb endpoint setup by quirk
commit
2bc16b9f3223d049b57202ee702fcb5b9b507019 upstream.
The commit
a60945fd08e4 ("ALSA: usb-audio: move implicit fb quirks to
separate function") introduced an error in the handling of quirks for
implicit feedback endpoints. This commit fixes this.
If a quirk successfully sets up an implicit feedback endpoint, usb-audio
no longer tries to find the implicit fb endpoint itself.
Fixes:
a60945fd08e4 ("ALSA: usb-audio: move implicit fb quirks to separate function")
Signed-off-by: Manuel Reinhardt <manuel.rhdt@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jurica Vukadin [Thu, 7 Feb 2019 15:29:37 +0000 (16:29 +0100)]
ALSA: hda - Add quirk for HP EliteBook 840 G5
commit
4cd3016ce996494f78fdfd87ea35c8ca5d0b413e upstream.
This enables mute LED support and fixes switching jacks when the laptop
is docked.
Signed-off-by: Jurica Vukadin <jurica.vukadin@rt-rk.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ingo Molnar [Wed, 13 Feb 2019 06:57:02 +0000 (07:57 +0100)]
perf/core: Fix impossible ring-buffer sizes warning
commit
528871b456026e6127d95b1b2bd8e3a003dc1614 upstream.
The following commit:
9dff0aa95a32 ("perf/core: Don't WARN() for impossible ring-buffer sizes")
results in perf recording failures with larger mmap areas:
root@skl:/tmp# perf record -g -a
failed to mmap with 12 (Cannot allocate memory)
The root cause is that the following condition is buggy:
if (order_base_2(size) >= MAX_ORDER)
goto fail;
The problem is that @size is in bytes and MAX_ORDER is in pages,
so the right test is:
if (order_base_2(size) >= PAGE_SHIFT+MAX_ORDER)
goto fail;
Fix it.
Reported-by: "Jin, Yao" <yao.jin@linux.intel.com>
Bisected-by: Borislav Petkov <bp@alien8.de>
Analyzed-by: Peter Zijlstra <peterz@infradead.org>
Cc: Julien Thierry <julien.thierry@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org>
Fixes:
9dff0aa95a32 ("perf/core: Don't WARN() for impossible ring-buffer sizes")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Ciancio [Mon, 14 Jan 2019 13:24:53 +0000 (10:24 -0300)]
Input: elan_i2c - add ACPI ID for touchpad in Lenovo V330-15ISK
commit
7ad222b3aed350adfc27ee7eec4587ffe55dfdce upstream.
This adds ELAN0617 to the ACPI table to support Elan touchpad found in
Lenovo V330-15ISK.
Signed-off-by: Mauro Ciancio <mauro@acadeu.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Torokhov [Mon, 11 Feb 2019 22:32:40 +0000 (14:32 -0800)]
Revert "Input: elan_i2c - add ACPI ID for touchpad in ASUS Aspire F5-573G"
commit
f420c54e4b12c1361c6ed313002ee7bd7ac58362 upstream.
This reverts commit
7db54c89f0b30a101584e09d3729144e6170059d as it
breaks Acer Aspire V-371 and other devices. According to Elan:
"Acer Aspire F5-573G is MS Precision touchpad which should use hid
multitouch driver. ELAN0501 should not be added in elan_i2c."
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202503
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rustad [Fri, 15 Feb 2019 16:19:55 +0000 (08:19 -0800)]
Documentation/network: reword kernel version reference
It seemed odd to say "since 4.17" in a 4.4 kernel. Consider
rewording the reference to indicate where in the stable series
it was introduced as well as where it originated.
Signed-off-by: Mark Rustad <mrustad@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ross Lagerwall [Tue, 8 Jan 2019 18:30:56 +0000 (18:30 +0000)]
cifs: Limit memory used by lock request calls to a page
[ Upstream commit
92a8109e4d3a34fb6b115c9098b51767dc933444 ]
The code tries to allocate a contiguous buffer with a size supplied by
the server (maxBuf). This could fail if memory is fragmented since it
results in high order allocations for commonly used server
implementations. It is also wasteful since there are probably
few locks in the usual case. Limit the buffer to be no larger than a
page to avoid memory allocation failures due to fragmentation.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nicholas Mc Guire [Sat, 1 Dec 2018 11:57:18 +0000 (12:57 +0100)]
gpio: pl061: handle failed allocations
[ Upstream commit
df209c43a0e8258e096fb722dfbdae4f0dd13fde ]
devm_kzalloc(), devm_kstrdup() and devm_kasprintf() all can
fail internal allocation and return NULL. Using any of the assigned
objects without checking is not safe. As this is early in the boot
phase and these allocations really should not fail, any failure here
is probably an indication of a more serious issue so it makes little
sense to try and rollback the previous allocated resources or try to
continue; but rather the probe function is simply exited with -ENOMEM.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Fixes:
684284b64aae ("ARM: integrator: add MMCI device to IM-PD1")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Linus Walleij [Mon, 7 Jan 2019 23:08:18 +0000 (00:08 +0100)]
ARM: dts: kirkwood: Fix polarity of GPIO fan lines
[ Upstream commit
b5f034845e70916fd33e172fad5ad530a29c10ab ]
These two lines are active high, not active low. The bug was
found when we changed the kernel to respect the polarity defined
in the device tree.
Fixes:
1b90e06b1429 ("ARM: kirkwood: Use devicetree to define DNS-32[05] fan")
Cc: Jamie Lentin <jm@lentin.co.uk>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@bootlin.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Julien D'Ascenzio <jdascenzio@posteo.net>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Jamie Lentin <jm@lentin.co.uk>
Reported-by: Julien D'Ascenzio <jdascenzio@posteo.net>
Tested-by: Julien D'Ascenzio <jdascenzio@posteo.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Ujfalusi [Wed, 19 Dec 2018 11:47:24 +0000 (13:47 +0200)]
ARM: dts: da850-evm: Correct the sound card name
[ Upstream commit
7fca69d4e43fa1ae9cb4f652772c132dc5a659c6 ]
To avoid the following error:
asoc-simple-card sound: ASoC: Failed to create card debugfs directory
Which is because the card name contains '/' character, which can not be
used in file or directory names.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hauke Mehrtens [Thu, 14 Feb 2019 13:18:00 +0000 (14:18 +0100)]
uapi/if_ether.h: prevent redefinition of struct ethhdr
commit
6926e041a8920c8ec27e4e155efa760aa01551fd upstream.
Musl provides its own ethhdr struct definition. Add a guard to prevent
its definition of the appropriate musl header has already been included.
glibc does not implement this header, but when glibc will implement this
they can just define __UAPI_DEF_ETHHDR 0 to make it work with the
kernel.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Linus Torvalds [Thu, 14 Feb 2019 23:02:18 +0000 (15:02 -0800)]
Revert "exec: load_script: don't blindly truncate shebang string"
commit
cb5b020a8d38f77209d0472a0fea755299a8ec78 upstream.
This reverts commit
8099b047ecc431518b9bb6bdbba3549bbecdc343.
It turns out that people do actually depend on the shebang string being
truncated, and on the fact that an interpreter (like perl) will often
just re-interpret it entirely to get the full argument list.
Reported-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sven Eckelmann [Mon, 31 Dec 2018 21:31:01 +0000 (22:31 +0100)]
batman-adv: Force mac header to start of data on xmit
commit
9114daa825fc3f335f9bea3313ce667090187280 upstream.
The caller of ndo_start_xmit may not already have called
skb_reset_mac_header. The returned value of skb_mac_header/eth_hdr
therefore can be in the wrong position and even outside the current skbuff.
This for example happens when the user binds to the device using a
PF_PACKET-SOCK_RAW with enabled qdisc-bypass:
int opt = 4;
setsockopt(sock, SOL_PACKET, PACKET_QDISC_BYPASS, &opt, sizeof(opt));
Since eth_hdr is used all over the codebase, the batadv_interface_tx
function must always take care of resetting it.
Fixes:
c6c8fea29769 ("net: Add batman-adv meshing protocol")
Reported-by: syzbot+9d7405c7faa390e60b4e@syzkaller.appspotmail.com
Reported-by: syzbot+7d20bc3f1ddddc0f9079@syzkaller.appspotmail.com
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sven Eckelmann [Sun, 30 Dec 2018 11:46:01 +0000 (12:46 +0100)]
batman-adv: Avoid WARN on net_device without parent in netns
commit
955d3411a17f590364238bd0d3329b61f20c1cd2 upstream.
It is not allowed to use WARN* helpers on potential incorrect input from
the user or transient problems because systems configured as panic_on_warn
will reboot due to such a problem.
A NULL return value of __dev_get_by_index can be caused by various problems
which can either be related to the system configuration or problems
(incorrectly returned network namespaces) in other (virtual) net_device
drivers. batman-adv should not cause a (harmful) WARN in this situation and
instead only report it via a simple message.
Fixes:
b7eddd0b3950 ("batman-adv: prevent using any virtual device created on batman-adv as hard-interface")
Reported-by: syzbot+c764de0fcfadca9a8595@syzkaller.appspotmail.com
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Wed, 9 Jan 2019 13:37:34 +0000 (14:37 +0100)]
xfrm: refine validation of template and selector families
commit
35e6103861a3a970de6c84688c6e7a1f65b164ca upstream.
The check assumes that in transport mode, the first templates family
must match the address family of the policy selector.
Syzkaller managed to build a template using MODE_ROUTEOPTIMIZATION,
with ipv4-in-ipv6 chain, leading to following splat:
BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x1db/0x1854
Read of size 4 at addr
ffff888063e57aa0 by task a.out/2050
xfrm_state_find+0x1db/0x1854
xfrm_tmpl_resolve+0x100/0x1d0
xfrm_resolve_and_create_bundle+0x108/0x1000 [..]
Problem is that addresses point into flowi4 struct, but xfrm_state_find
treats them as being ipv6 because it uses templ->encap_family is used
(AF_INET6 in case of reproducer) rather than family (AF_INET).
This patch inverts the logic: Enforce 'template family must match
selector' EXCEPT for tunnel and BEET mode.
In BEET and Tunnel mode, xfrm_tmpl_resolve_one will have remote/local
address pointers changed to point at the addresses found in the template,
rather than the flowi ones, so no oob read will occur.
Reported-by: 3ntr0py1337@gmail.com
Reported-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilya Dryomov [Mon, 14 Jan 2019 20:13:10 +0000 (21:13 +0100)]
libceph: avoid KEEPALIVE_PENDING races in ceph_con_keepalive()
commit
4aac9228d16458cedcfd90c7fb37211cf3653ac3 upstream.
con_fault() can transition the connection into STANDBY right after
ceph_con_keepalive() clears STANDBY in clear_standby():
libceph user thread ceph-msgr worker
ceph_con_keepalive()
mutex_lock(&con->mutex)
clear_standby(con)
mutex_unlock(&con->mutex)
mutex_lock(&con->mutex)
con_fault()
...
if KEEPALIVE_PENDING isn't set
set state to STANDBY
...
mutex_unlock(&con->mutex)
set KEEPALIVE_PENDING
set WRITE_PENDING
This triggers warnings in clear_standby() when either ceph_con_send()
or ceph_con_keepalive() get to clearing STANDBY next time.
I don't see a reason to condition queue_con() call on the previous
value of KEEPALIVE_PENDING, so move the setting of KEEPALIVE_PENDING
into the critical section -- unlike WRITE_PENDING, KEEPALIVE_PENDING
could have been a non-atomic flag.
Reported-by: syzbot+acdeb633f6211ccdf886@syzkaller.appspotmail.com
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Tested-by: Myungho Jung <mhjungk@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 13 Feb 2019 15:01:54 +0000 (16:01 +0100)]
Revert "cifs: In Kconfig CONFIG_CIFS_POSIX needs depends on legacy (insecure cifs)"
This reverts commit
60da90b224ba77a934decbb8129dabc861edd526 which is
commit
6e785302dad32228819d8066e5376acd15d0e6ba upstream.
Yi writes:
I notice that 4.4.169 merged
60da90b224ba7 ("cifs: In Kconfig
CONFIG_CIFS_POSIX needs depends on legacy (insecure cifs)") add
a Kconfig dependency CIFS_ALLOW_INSECURE_LEGACY, which was not
defined in 4.4 stable, so after this patch we are not able to
enable CIFS_POSIX anymore. Linux 4.4 stable didn't merge the
legacy dialects codes, so do we really need this patch for 4.4?
So revert this patch.
Reported-by: "zhangyi (F)" <yi.zhang@huawei.com>
Cc: Steve French <stfrench@microsoft.com>
Cc: Pavel Shilovsky <pshilov@microsoft.com>
Cc: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Sat, 1 Aug 2015 13:59:29 +0000 (06:59 -0700)]
NFC: nxp-nci: Include unaligned.h instead of access_ok.h
commit
2eee74b7e2a496dea49847c36fd09320505f45b7 upstream.
Directly including access_ok.h can result in the following compile errors
if an architecture such as ia64 does not support direct unaligned accesses.
include/linux/unaligned/access_ok.h:7:19: error:
redefinition of 'get_unaligned_le16'
include/linux/unaligned/le_struct.h:6:19: note:
previous definition of 'get_unaligned_le16' was here
include/linux/unaligned/access_ok.h:12:19: error:
redefinition of 'get_unaligned_le32'
include/linux/unaligned/le_struct.h:11:19: note:
previous definition of 'get_unaligned_le32' was here
Include asm/unaligned.h instead and let the architecture decide which
access functions to use.
Cc: Clément Perrochaud <clement.perrochaud@effinnov.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vladis Dronov [Tue, 29 Jan 2019 10:58:35 +0000 (11:58 +0100)]
HID: debug: fix the ring buffer implementation
commit
13054abbaa4f1fd4e6f3b4b63439ec033b4c8035 upstream.
Ring buffer implementation in hid_debug_event() and hid_debug_events_read()
is strange allowing lost or corrupted data. After commit
717adfdaf147
("HID: debug: check length before copy_to_user()") it is possible to enter
an infinite loop in hid_debug_events_read() by providing 0 as count, this
locks up a system. Fix this by rewriting the ring buffer implementation
with kfifo and simplify the code.
This fixes CVE-2019-3819.
v2: fix an execution logic and add a comment
v3: use __set_current_state() instead of set_current_state()
Backport to v4.4: some (tree-wide) patches are missing in v4.4 so
cherry-pick relevant pieces from:
*
6396bb22151 ("treewide: kzalloc() -> kcalloc()")
*
a9a08845e9ac ("vfs: do bulk POLL* -> EPOLL* replacement")
*
92529623d242 ("HID: debug: improve hid_debug_event()")
*
174cd4b1e5fb ("sched/headers: Prepare to move signal wakeup & sigpending
methods from <linux/sched.h> into <linux/sched/signal.h>")
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187
Cc: stable@vger.kernel.org # v4.18+
Fixes:
cd667ce24796 ("HID: use debugfs for events/reports dumping")
Fixes:
717adfdaf147 ("HID: debug: check length before copy_to_user()")
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Hellstrom [Thu, 31 Jan 2019 09:55:37 +0000 (10:55 +0100)]
drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user
commit
728354c005c36eaf44b6e5552372b67e60d17f56 upstream.
The function was unconditionally returning 0, and a caller would have to
rely on the returned fence pointer being NULL to detect errors. However,
the function vmw_execbuf_copy_fence_user() would expect a non-zero error
code in that case and would BUG otherwise.
So make sure we return a proper non-zero error code if the fence pointer
returned is NULL.
Cc: <stable@vger.kernel.org>
Fixes:
ae2a104058e2: ("vmwgfx: Implement fence objects")
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Hellstrom [Mon, 28 Jan 2019 09:31:33 +0000 (10:31 +0100)]
drm/vmwgfx: Fix setting of dma masks
commit
4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initially set to 64 bits.
Cc: <stable@vger.kernel.org>
Fixes:
0d00c488f3de: ("drm/vmwgfx: Fix the driver for large dma addresses")
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tina Zhang [Wed, 23 Jan 2019 07:28:59 +0000 (15:28 +0800)]
drm/modes: Prevent division by zero htotal
commit
a2fcd5c84f7a7825e028381b10182439067aa90d upstream.
This patch prevents division by zero htotal.
In a follow-up mail Tina writes:
> > How did you manage to get here with htotal == 0? This needs backtraces (or if
> > this is just about static checkers, a mention of that).
> > -Daniel
>
> In GVT-g, we are trying to enable a virtual display w/o setting timings for a pipe
> (a.k.a htotal=0), then we met the following kernel panic:
>
> [ 32.832048] divide error: 0000 [#1] SMP PTI
> [ 32.833614] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc4-sriov+ #33
> [ 32.834438] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.10.1-0-g8891697-dirty-20180511_165818-tinazhang-linux-1 04/01/2014
> [ 32.835901] RIP: 0010:drm_mode_hsync+0x1e/0x40
> [ 32.836004] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
> [ 32.836004] RSP: 0000:
ffffc900000ebb90 EFLAGS:
00010206
> [ 32.836004] RAX:
0000000000000000 RBX:
ffff88001c67c8a0 RCX:
0000000000000000
> [ 32.836004] RDX:
0000000000000000 RSI:
ffff88001c67c000 RDI:
ffff88001c67c8a0
> [ 32.836004] RBP:
ffff88001c7d03a0 R08:
ffff88001c67c8a0 R09:
ffff88001c7d0330
> [ 32.836004] R10:
ffffffff822c3a98 R11:
0000000000000001 R12:
ffff88001c67c000
> [ 32.836004] R13:
ffff88001c7d0370 R14:
ffffffff8207eb78 R15:
ffff88001c67c800
> [ 32.836004] FS:
0000000000000000(0000) GS:
ffff88001da00000(0000) knlGS:
0000000000000000
> [ 32.836004] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
> [ 32.836004] CR2:
0000000000000000 CR3:
000000000220a000 CR4:
00000000000006f0
> [ 32.836004] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
> [ 32.836004] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
> [ 32.836004] Call Trace:
> [ 32.836004] intel_mode_from_pipe_config+0x72/0x90
> [ 32.836004] intel_modeset_setup_hw_state+0x569/0xf90
> [ 32.836004] intel_modeset_init+0x905/0x1db0
> [ 32.836004] i915_driver_load+0xb8c/0x1120
> [ 32.836004] i915_pci_probe+0x4d/0xb0
> [ 32.836004] local_pci_probe+0x44/0xa0
> [ 32.836004] ? pci_assign_irq+0x27/0x130
> [ 32.836004] pci_device_probe+0x102/0x1c0
> [ 32.836004] driver_probe_device+0x2b8/0x480
> [ 32.836004] __driver_attach+0x109/0x110
> [ 32.836004] ? driver_probe_device+0x480/0x480
> [ 32.836004] bus_for_each_dev+0x67/0xc0
> [ 32.836004] ? klist_add_tail+0x3b/0x70
> [ 32.836004] bus_add_driver+0x1e8/0x260
> [ 32.836004] driver_register+0x5b/0xe0
> [ 32.836004] ? mipi_dsi_bus_init+0x11/0x11
> [ 32.836004] do_one_initcall+0x4d/0x1eb
> [ 32.836004] kernel_init_freeable+0x197/0x237
> [ 32.836004] ? rest_init+0xd0/0xd0
> [ 32.836004] kernel_init+0xa/0x110
> [ 32.836004] ret_from_fork+0x35/0x40
> [ 32.836004] Modules linked in:
> [ 32.859183] ---[ end trace
525608b0ed0e8665 ]---
> [ 32.859722] RIP: 0010:drm_mode_hsync+0x1e/0x40
> [ 32.860287] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
> [ 32.862680] RSP: 0000:
ffffc900000ebb90 EFLAGS:
00010206
> [ 32.863309] RAX:
0000000000000000 RBX:
ffff88001c67c8a0 RCX:
0000000000000000
> [ 32.864182] RDX:
0000000000000000 RSI:
ffff88001c67c000 RDI:
ffff88001c67c8a0
> [ 32.865206] RBP:
ffff88001c7d03a0 R08:
ffff88001c67c8a0 R09:
ffff88001c7d0330
> [ 32.866359] R10:
ffffffff822c3a98 R11:
0000000000000001 R12:
ffff88001c67c000
> [ 32.867213] R13:
ffff88001c7d0370 R14:
ffffffff8207eb78 R15:
ffff88001c67c800
> [ 32.868075] FS:
0000000000000000(0000) GS:
ffff88001da00000(0000) knlGS:
0000000000000000
> [ 32.868983] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
> [ 32.869659] CR2:
0000000000000000 CR3:
000000000220a000 CR4:
00000000000006f0
> [ 32.870599] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
> [ 32.871598] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
> [ 32.872549] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> Since drm_mode_hsync() has the logic to check mode->htotal, I just extend it to cover the case htotal==0.
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
[danvet: Add additional explanations + cc: stable.]
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1548228539-3061-1-git-send-email-tina.zhang@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Fietkau [Tue, 29 Jan 2019 10:10:57 +0000 (11:10 +0100)]
mac80211: ensure that mgmt tx skbs have tailroom for encryption
commit
9d0f50b80222dc273e67e4e14410fcfa4130a90c upstream.
Some drivers use IEEE80211_KEY_FLAG_SW_MGMT_TX to indicate that management
frames need to be software encrypted. Since normal data packets are still
encrypted by the hardware, crypto_tx_tailroom_needed_cnt gets decremented
after key upload to hw. This can lead to passing skbs to ccmp_encrypt_skb,
which don't have the necessary tailroom for software encryption.
Change the code to add tailroom for encrypted management packets, even if
crypto_tx_tailroom_needed_cnt is 0.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Fri, 25 Jan 2019 20:10:15 +0000 (20:10 +0000)]
ARM: iop32x/n2100: fix PCI IRQ mapping
commit
db4090920ba2d61a5827a23e441447926a02ffee upstream.
Booting 4.20 on a TheCUS N2100 results in a kernel oops while probing
PCI, due to n2100_pci_map_irq() having been discarded during boot.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Cc: stable@vger.kernel.org # 2.6.18+
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Burton [Mon, 28 Jan 2019 23:16:22 +0000 (23:16 +0000)]
MIPS: VDSO: Include $(ccflags-vdso) in o32,n32 .lds builds
commit
67fc5dc8a541e8f458d7f08bf88ff55933bf9f9d upstream.
When generating vdso-o32.lds & vdso-n32.lds for use with programs
running as compat ABIs under 64b kernels, we previously haven't included
the compiler flags that are supposedly common to all ABIs - ie. those in
the ccflags-vdso variable.
This is problematic in cases where we need to provide the -m%-float flag
in order to ensure that we don't attempt to use a floating point ABI
that's incompatible with the target CPU & ABI. For example a toolchain
using current gcc trunk configured --with-fp-32=xx fails to build a
64r6el_defconfig kernel with the following error:
cc1: error: '-march=mips1' requires '-mfp32'
make[2]: *** [arch/mips/vdso/Makefile:135: arch/mips/vdso/vdso-o32.lds] Error 1
Include $(ccflags-vdso) for the compat VDSO .lds builds, just as it is
included for the native VDSO .lds & when compiling objects for the
compat VDSOs. This ensures we consistently provide the -msoft-float flag
amongst others, avoiding the problem by ensuring we're agnostic to the
toolchain defaults.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Fixes:
ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Cc: linux-mips@vger.kernel.org
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Maciej W . Rozycki <macro@linux-mips.org>
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aaro Koskinen [Sun, 27 Jan 2019 21:28:33 +0000 (23:28 +0200)]
MIPS: OCTEON: don't set octeon_dma_bar_type if PCI is disabled
commit
dcf300a69ac307053dfb35c2e33972e754a98bce upstream.
Don't set octeon_dma_bar_type if PCI is disabled. This avoids creation
of the MSI irqchip later on, and saves a bit of memory.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Fixes:
a214720cbf50 ("Disable MSI also when pcie-octeon.pcie_disable on")
Cc: stable@vger.kernel.org # v3.3+
Cc: linux-mips@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vladimir Kondratiev [Wed, 6 Feb 2019 11:46:17 +0000 (13:46 +0200)]
mips: cm: reprime error cause
commit
05dc6001af0630e200ad5ea08707187fe5537e6d upstream.
Accordingly to the documentation
---cut---
The GCR_ERROR_CAUSE.ERR_TYPE field and the GCR_ERROR_MULT.ERR_TYPE
fields can be cleared by either a reset or by writing the current
value of GCR_ERROR_CAUSE.ERR_TYPE to the
GCR_ERROR_CAUSE.ERR_TYPE register.
---cut---
Do exactly this. Original value of cm_error may be safely written back;
it clears error cause and keeps other bits untouched.
Fixes:
3885c2b463f6 ("MIPS: CM: Add support for reporting CM cache errors")
Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@linux.intel.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v4.3+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 23 Jan 2019 10:27:02 +0000 (11:27 +0100)]
debugfs: fix debugfs_rename parameter checking
commit
d88c93f090f708c18195553b352b9f205e65418f upstream.
debugfs_rename() needs to check that the dentries passed into it really
are valid, as sometimes they are not (i.e. if the return value of
another debugfs call is passed into this one.) So fix this up by
properly checking if the two parent directories are errors (they are
allowed to be NULL), and if the dentry to rename is not NULL or an
error.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Mon, 3 Dec 2018 14:52:19 +0000 (17:52 +0300)]
misc: vexpress: Off by one in vexpress_syscfg_exec()
commit
f8a70d8b889f180e6860cb1f85fed43d37844c5a upstream.
The > comparison should be >= to prevent reading beyond the end of the
func->template[] array.
(The func->template array is allocated in vexpress_syscfg_regmap_init()
and it has func->num_templates elements.)
Fixes:
974cc7b93441 ("mfd: vexpress: Define the device as MFD cells")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric W. Biederman [Wed, 6 Feb 2019 23:51:47 +0000 (17:51 -0600)]
signal: Better detection of synchronous signals
commit
7146db3317c67b517258cb5e1b08af387da0618b upstream.
Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER. Ultimately causing a loop failing
to deliver SIGHUP but always trying.
When the stack overflows delivery of SIGHUP fails and force_sigsegv is
called. Unfortunately because SIGSEGV is numerically higher than
SIGHUP next_signal tries again to deliver a SIGHUP.
From a quality of implementation standpoint attempting to deliver the
timer SIGHUP signal is wrong. We should attempt to deliver the
synchronous SIGSEGV signal we just forced.
We can make that happening in a fairly straight forward manner by
instead of just looking at the signal number we also look at the
si_code. In particular for exceptions (aka synchronous signals) the
si_code is always greater than 0.
That still has the potential to pick up a number of asynchronous
signals as in a few cases the same si_codes that are used
for synchronous signals are also used for asynchronous signals,
and SI_KERNEL is also included in the list of possible si_codes.
Still the heuristic is much better and timer signals are definitely
excluded. Which is enough to prevent all known ways for someone
sending a process signals fast enough to cause unexpected and
arguably incorrect behavior.
Cc: stable@vger.kernel.org
Fixes:
a27341cd5fcb ("Prioritize synchronous signals over 'normal' signals")
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric W. Biederman [Thu, 7 Feb 2019 00:39:40 +0000 (18:39 -0600)]
signal: Always notice exiting tasks
commit
35634ffa1751b6efd8cf75010b509dcb0263e29b upstream.
Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER. Ultimately causing a loop
failing to deliver SIGHUP but always trying.
Upon examination it turns out part of the problem is actually most of
the solution. Since 2.5 signal delivery has found all fatal signals,
marked the signal group for death, and queued SIGKILL in every threads
thread queue relying on signal->group_exit_code to preserve the
information of which was the actual fatal signal.
The conversion of all fatal signals to SIGKILL results in the
synchronous signal heuristic in next_signal kicking in and preferring
SIGHUP to SIGKILL. Which is especially problematic as all
fatal signals have already been transformed into SIGKILL.
Instead of dequeueing signals and depending upon SIGKILL to
be the first signal dequeued, first test if the signal group
has already been marked for death. This guarantees that
nothing in the signal queue can prevent a process that needs
to exit from exiting.
Cc: stable@vger.kernel.org
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Ref:
ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin Kepplinger [Tue, 5 Feb 2019 15:52:51 +0000 (16:52 +0100)]
mtd: rawnand: gpmi: fix MX28 bus master lockup problem
commit
d5d27fd9826b59979b184ec288e4812abac0e988 upstream.
Disable BCH soft reset according to MX23 erratum #2847 ("BCH soft
reset may cause bus master lock up") for MX28 too. It has the same
problem.
Observed problem: once per 100,000+ MX28 reboots NAND read failed on
DMA timeout errors:
[ 1.770823] UBI: attaching mtd3 to ubi0
[ 2.768088] gpmi_nand: DMA timeout, last DMA :1
[ 3.958087] gpmi_nand: BCH timeout, last DMA :1
[ 4.156033] gpmi_nand: Error in ECC-based read: -110
[ 4.161136] UBI warning: ubi_io_read: error -110 while reading 64
bytes from PEB 0:0, read only 0 bytes, retry
[ 4.171283] step 1 error
[ 4.173846] gpmi_nand: Chip: 0, Error -1
Without BCH soft reset we successfully executed 1,000,000 MX28 reboots.
I have a quote from NXP regarding this problem, from July 18th 2016:
"As the i.MX23 and i.MX28 are of the same generation, they share many
characteristics. Unfortunately, also the erratas may be shared.
In case of the documented erratas and the workarounds, you can also
apply the workaround solution of one device on the other one. This have
been reported, but I’m afraid that there are not an estimated date for
updating the Errata documents.
Please accept our apologies for any inconveniences this may cause."
Fixes:
6f2a6a52560a ("mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems")
Cc: stable@vger.kernel.org
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com>
Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Han Xu <han.xu@nxp.com>
Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gustavo A. R. Silva [Tue, 22 Jan 2019 23:34:39 +0000 (17:34 -0600)]
perf tests evsel-tp-sched: Fix bitwise operator
commit
489338a717a0dfbbd5a3fabccf172b78f0ac9015 upstream.
Notice that the use of the bitwise OR operator '|' always leads to true
in this particular case, which seems a bit suspicious due to the context
in which this expression is being used.
Fix this by using bitwise AND operator '&' instead.
This bug was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: stable@vger.kernel.org
Fixes:
6a6cd11d4e57 ("perf test: Add test for the sched tracepoint format fields")
Link: http://lkml.kernel.org/r/20190122233439.GA5868@embeddedor
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rutland [Thu, 10 Jan 2019 14:27:45 +0000 (14:27 +0000)]
perf/core: Don't WARN() for impossible ring-buffer sizes
commit
9dff0aa95a324e262ffb03f425d00e4751f3294e upstream.
The perf tool uses /proc/sys/kernel/perf_event_mlock_kb to determine how
large its ringbuffer mmap should be. This can be configured to arbitrary
values, which can be larger than the maximum possible allocation from
kmalloc.
When this is configured to a suitably large value (e.g. thanks to the
perf fuzzer), attempting to use perf record triggers a WARN_ON_ONCE() in
__alloc_pages_nodemask():
WARNING: CPU: 2 PID: 5666 at mm/page_alloc.c:4511 __alloc_pages_nodemask+0x3f8/0xbc8
Let's avoid this by checking that the requested allocation is possible
before calling kzalloc.
Reported-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20190110142745.25495-1-mark.rutland@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tony Luck [Fri, 1 Feb 2019 00:33:41 +0000 (16:33 -0800)]
x86/MCE: Initialize mce.bank in the case of a fatal error in mce_no_way_out()
commit
d28af26faa0b1daf3c692603d46bc4687c16f19e upstream.
Internal injection testing crashed with a console log that said:
mce: [Hardware Error]: CPU 7: Machine Check Exception: f Bank 0:
bd80000000100134
This caused a lot of head scratching because the MCACOD (bits 15:0) of
that status is a signature from an L1 data cache error. But Linux says
that it found it in "Bank 0", which on this model CPU only reports L1
instruction cache errors.
The answer was that Linux doesn't initialize "m->bank" in the case that
it finds a fatal error in the mce_no_way_out() pre-scan of banks. If
this was a local machine check, then this partially initialized struct
mce is being passed to mce_panic().
Fix is simple: just initialize m->bank in the case of a fatal error.
Fixes:
40c36e2741d7 ("x86/mce: Fix incorrect "Machine check from unknown source" message")
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: x86-ml <x86@kernel.org>
Cc: stable@vger.kernel.org # v4.18 Note pre-v5.0 arch/x86/kernel/cpu/mce/core.c was called arch/x86/kernel/cpu/mcheck/mce.c
Link: https://lkml.kernel.org/r/20190201003341.10638-1-tony.luck@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kan Liang [Sun, 27 Jan 2019 14:53:14 +0000 (06:53 -0800)]
perf/x86/intel/uncore: Add Node ID mask
commit
9e63a7894fd302082cf3627fe90844421a6cbe7f upstream.
Some PCI uncore PMUs cannot be registered on an 8-socket system (HPE
Superdome Flex).
To understand which Socket the PCI uncore PMUs belongs to, perf retrieves
the local Node ID of the uncore device from CPUNODEID(0xC0) of the PCI
configuration space, and the mapping between Socket ID and Node ID from
GIDNIDMAP(0xD4). The Socket ID can be calculated accordingly.
The local Node ID is only available at bit 2:0, but current code doesn't
mask it. If a BIOS doesn't clear the rest of the bits, an incorrect Node ID
will be fetched.
Filter the Node ID by adding a mask.
Reported-by: Song Liu <songliubraving@fb.com>
Tested-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: <stable@vger.kernel.org> # v3.7+
Fixes:
7c94ee2e0917 ("perf/x86: Add Intel Nehalem and Sandy Bridge-EP uncore support")
Link: https://lkml.kernel.org/r/1548600794-33162-1-git-send-email-kan.liang@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Shier [Thu, 11 Oct 2018 18:46:46 +0000 (11:46 -0700)]
KVM: nVMX: unconditionally cancel preemption timer in free_nested (CVE-2019-7221)
commit
ecec76885bcfe3294685dc363fd1273df0d5d65f upstream.
Bugzilla:
1671904
There are multiple code paths where an hrtimer may have been started to
emulate an L1 VMX preemption timer that can result in a call to free_nested
without an intervening L2 exit where the hrtimer is normally
cancelled. Unconditionally cancel in free_nested to cover all cases.
Embargoed until Feb 7th 2019.
Signed-off-by: Peter Shier <pshier@google.com>
Reported-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Reported-by: Felix Wilhelm <fwilhelm@google.com>
Cc: stable@kernel.org
Message-Id: <
20181011184646.154065-1-pshier@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paolo Bonzini [Tue, 29 Jan 2019 17:41:16 +0000 (18:41 +0100)]
KVM: x86: work around leak of uninitialized stack contents (CVE-2019-7222)
commit
353c0956a618a07ba4bbe7ad00ff29fe70e8412a upstream.
Bugzilla:
1671930
Emulation of certain instructions (VMXON, VMCLEAR, VMPTRLD, VMWRITE with
memory operand, INVEPT, INVVPID) can incorrectly inject a page fault
when passed an operand that points to an MMIO address. The page fault
will use uninitialized kernel stack memory as the CR2 and error code.
The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR
exit to userspace; however, it is not an easy fix, so for now just
ensure that the error code and CR2 are zero.
Embargoed until Feb 7th 2019.
Reported-by: Felix Wilhelm <fwilhelm@google.com>
Cc: stable@kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gustavo A. R. Silva [Tue, 22 Jan 2019 21:28:08 +0000 (15:28 -0600)]
usb: gadget: udc: net2272: Fix bitwise and boolean operations
commit
07c69f1148da7de3978686d3af9263325d9d60bd upstream.
(!x & y) strikes again.
Fix bitwise and boolean operations by enclosing the expression:
intcsr & (1 << NET2272_PCI_IRQ)
in parentheses, before applying the boolean operator '!'.
Notice that this code has been there since 2011. So, it would
be helpful if someone can double-check this.
This issue was detected with the help of Coccinelle.
Fixes:
ceb80363b2ec ("USB: net2272: driver for PLX NET2272 USB device controller")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bin Liu [Wed, 16 Jan 2019 17:54:07 +0000 (11:54 -0600)]
usb: phy: am335x: fix race condition in _probe
commit
a53469a68eb886e84dd8b69a1458a623d3591793 upstream.
power off the phy should be done before populate the phy. Otherwise,
am335x_init() could be called by the phy owner to power on the phy first,
then am335x_phy_probe() turns off the phy again without the caller knowing
it.
Fixes:
2fc711d76352 ("usb: phy: am335x: Enable USB remote wakeup using PHY wakeup")
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Leonid Iziumtsev [Tue, 15 Jan 2019 17:15:23 +0000 (17:15 +0000)]
dmaengine: imx-dma: fix wrong callback invoke
commit
341198eda723c8c1cddbb006a89ad9e362502ea2 upstream.
Once the "ld_queue" list is not empty, next descriptor will migrate
into "ld_active" list. The "desc" variable will be overwritten
during that transition. And later the dmaengine_desc_get_callback_invoke()
will use it as an argument. As result we invoke wrong callback.
That behaviour was in place since:
commit
fcaaba6c7136 ("dmaengine: imx-dma: fix callback path in tasklet").
But after commit
4cd13c21b207 ("softirq: Let ksoftirqd do its job")
things got worse, since possible delay between tasklet_schedule()
from DMA irq handler and actual tasklet function execution got bigger.
And that gave more time for new DMA request to be submitted and
to be put into "ld_queue" list.
It has been noticed that DMA issue is causing problems for "mxc-mmc"
driver. While stressing the system with heavy network traffic and
writing/reading to/from sd card simultaneously the timeout may happen:
10013000.sdhci: mxcmci_watchdog: read time out (status = 0x30004900)
That often lead to file system corruption.
Signed-off-by: Leonid Iziumtsev <leonid.iziumtsev@gmail.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miklos Szeredi [Wed, 16 Jan 2019 09:27:59 +0000 (10:27 +0100)]
fuse: handle zero sized retrieve correctly
commit
97e1532ef81acb31c30f9e75bf00306c33a77812 upstream.
Dereferencing req->page_descs[0] will Oops if req->max_pages is zero.
Reported-by: syzbot+c1e36d30ee3416289cc0@syzkaller.appspotmail.com
Tested-by: syzbot+c1e36d30ee3416289cc0@syzkaller.appspotmail.com
Fixes:
b2430d7567a3 ("fuse: add per-page descriptor <offset, length> to fuse_req")
Cc: <stable@vger.kernel.org> # v3.9
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miklos Szeredi [Wed, 16 Jan 2019 09:27:59 +0000 (10:27 +0100)]
fuse: decrement NR_WRITEBACK_TEMP on the right page
commit
a2ebba824106dabe79937a9f29a875f837e1b6d4 upstream.
NR_WRITEBACK_TEMP is accounted on the temporary page in the request, not
the page cache page.
Fixes:
8b284dc47291 ("fuse: writepages: handle same page rewrites")
Cc: <stable@vger.kernel.org> # v3.13
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jann Horn [Sat, 12 Jan 2019 01:39:05 +0000 (02:39 +0100)]
fuse: call pipe_buf_release() under pipe lock
commit
9509941e9c534920ccc4771ae70bd6cbbe79df1c upstream.
Some of the pipe_buf_release() handlers seem to assume that the pipe is
locked - in particular, anon_pipe_buf_release() accesses pipe->tmp_page
without taking any extra locks. From a glance through the callers of
pipe_buf_release(), it looks like FUSE is the only one that calls
pipe_buf_release() without having the pipe locked.
This bug should only lead to a memory leak, nothing terrible.
Fixes:
dd3bb14f44a6 ("fuse: support splice() writing to fuse device")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 30 Jan 2019 16:46:03 +0000 (17:46 +0100)]
ALSA: hda - Serialize codec registrations
commit
305a0ade180981686eec1f92aa6252a7c6ebb1cf upstream.
In the current code, the codec registration may happen both at the
codec bind time and the end of the controller probe time. In a rare
occasion, they race with each other, leading to Oops due to the still
uninitialized card device.
This patch introduces a simple flag to prevent the codec registration
at the codec bind time as long as the controller probe is going on.
The controller probe invokes snd_card_register() that does the whole
registration task, and we don't need to register each piece
beforehand.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Charles Keepax [Tue, 5 Feb 2019 16:29:40 +0000 (16:29 +0000)]
ALSA: compress: Fix stop handling on compressed capture streams
commit
4f2ab5e1d13d6aa77c55f4914659784efd776eb4 upstream.
It is normal user behaviour to start, stop, then start a stream
again without closing it. Currently this works for compressed
playback streams but not capture ones.
The states on a compressed capture stream go directly from OPEN to
PREPARED, unlike a playback stream which moves to SETUP and waits
for a write of data before moving to PREPARED. Currently however,
when a stop is sent the state is set to SETUP for both types of
streams. This leaves a capture stream in the situation where a new
start can't be sent as that requires the state to be PREPARED and
a new set_params can't be sent as that requires the state to be
OPEN. The only option being to close the stream, and then reopen.
Correct this issues by allowing snd_compr_drain_notify to set the
state depending on the stream direction, as we already do in
set_params.
Fixes:
49bb6402f1aa ("ALSA: compress_core: Add support for capture streams")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rundong Ge [Sat, 2 Feb 2019 14:29:35 +0000 (14:29 +0000)]
net: dsa: slave: Don't propagate flag changes on down slave interfaces
[ Upstream commit
17ab4f61b8cd6f9c38e9d0b935d86d73b5d0d2b5 ]
The unbalance of master's promiscuity or allmulti will happen after ifdown
and ifup a slave interface which is in a bridge.
When we ifdown a slave interface , both the 'dsa_slave_close' and
'dsa_slave_change_rx_flags' will clear the master's flags. The flags
of master will be decrease twice.
In the other hand, if we ifup the slave interface again, since the
slave's flags were cleared the 'dsa_slave_open' won't set the master's
flag, only 'dsa_slave_change_rx_flags' that triggered by 'br_add_if'
will set the master's flags. The flags of master is increase once.
Only propagating flag changes when a slave interface is up makes
sure this does not happen. The 'vlan_dev_change_rx_flags' had the
same problem and was fixed, and changes here follows that fix.
Fixes:
91da11f870f0 ("net: Distributed Switch Architecture protocol support")
Signed-off-by: Rundong Ge <rdong.ge@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Fainelli [Fri, 1 Feb 2019 21:23:38 +0000 (13:23 -0800)]
net: systemport: Fix WoL with password after deep sleep
[ Upstream commit
8dfb8d2cceb76b74ad5b58cc65c75994329b4d5e ]
Broadcom STB chips support a deep sleep mode where all register
contents are lost. Because we were stashing the MagicPacket password
into some of these registers a suspend into that deep sleep then a
resumption would not lead to being able to wake-up from MagicPacket with
password again.
Fix this by keeping a software copy of the password and program it
during suspend.
Fixes:
83e82f4c706b ("net: systemport: add Wake-on-LAN support")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 1 Feb 2019 08:28:16 +0000 (11:28 +0300)]
skge: potential memory corruption in skge_get_regs()
[ Upstream commit
294c149a209c6196c2de85f512b52ef50f519949 ]
The "p" buffer is 0x4000 bytes long. B3_RI_WTO_R1 is 0x190. The value
of "regs->len" is in the 1-0x4000 range. The bug here is that
"regs->len - B3_RI_WTO_R1" can be a negative value which would lead to
memory corruption and an abrupt crash.
Fixes:
c3f8be961808 ("[PATCH] skge: expand ethtool debug register dump")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior [Mon, 4 Feb 2019 10:20:29 +0000 (11:20 +0100)]
net: dp83640: expire old TX-skb
[ Upstream commit
53bc8d2af08654659abfadfd3e98eb9922ff787c ]
During sendmsg() a cloned skb is saved via dp83640_txtstamp() in
->tx_queue. After the NIC sends this packet, the PHY will reply with a
timestamp for that TX packet. If the cable is pulled at the right time I
don't see that packet. It might gets flushed as part of queue shutdown
on NIC's side.
Once the link is up again then after the next sendmsg() we enqueue
another skb in dp83640_txtstamp() and have two on the list. Then the PHY
will send a reply and decode_txts() attaches it to the first skb on the
list.
No crash occurs since refcounting works but we are one packet behind.
linuxptp/ptp4l usually closes the socket and opens a new one (in such a
timeout case) so those "stale" replies never get there. However it does
not resume normal operation anymore.
Purge old skbs in decode_txts().
Fixes:
cb646e2b02b2 ("ptp: Added a clock driver for the National Semiconductor PHYTER.")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Govindarajulu Varadarajan [Wed, 30 Jan 2019 14:59:00 +0000 (06:59 -0800)]
enic: fix checksum validation for IPv6
[ Upstream commit
7596175e99b3d4bce28022193efd954c201a782a ]
In case of IPv6 pkts, ipv4_csum_ok is 0. Because of this, driver does
not set skb->ip_summed. So IPv6 rx checksum is not offloaded.
Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Wed, 30 Jan 2019 19:39:41 +0000 (11:39 -0800)]
dccp: fool proof ccid_hc_[rt]x_parse_options()
[ Upstream commit
9b1f19d810e92d6cdc68455fbc22d9f961a58ce1 ]
Similarly to commit
276bdb82dedb ("dccp: check ccid before dereferencing")
it is wise to test for a NULL ccid.
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.0.0-rc3+ #37
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:ccid_hc_tx_parse_options net/dccp/ccid.h:205 [inline]
RIP: 0010:dccp_parse_options+0x8d9/0x12b0 net/dccp/options.c:233
Code: c5 0f b6 75 b3 80 38 00 0f 85 d6 08 00 00 48 b9 00 00 00 00 00 fc ff df 48 8b 45 b8 4c 8b b8 f8 07 00 00 4c 89 f8 48 c1 e8 03 <80> 3c 08 00 0f 85 95 08 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b
kobject: 'loop5' (
0000000080f78fc1): kobject_uevent_env
RSP: 0018:
ffff8880a94df0b8 EFLAGS:
00010246
RAX:
0000000000000000 RBX:
ffff8880858ac723 RCX:
dffffc0000000000
RDX:
0000000000000100 RSI:
0000000000000007 RDI:
0000000000000001
RBP:
ffff8880a94df140 R08:
0000000000000001 R09:
ffff888061b83a80
R10:
ffffed100c370752 R11:
ffff888061b83a97 R12:
0000000000000026
R13:
0000000000000001 R14:
0000000000000000 R15:
0000000000000000
FS:
0000000000000000(0000) GS:
ffff8880ae700000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00007f0defa33518 CR3:
000000008db5e000 CR4:
00000000001406e0
kobject: 'loop5' (
0000000080f78fc1): fill_kobj_path: path = '/devices/virtual/block/loop5'
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
dccp_rcv_state_process+0x2b6/0x1af6 net/dccp/input.c:654
dccp_v4_do_rcv+0x100/0x190 net/dccp/ipv4.c:688
sk_backlog_rcv include/net/sock.h:936 [inline]
__sk_receive_skb+0x3a9/0xea0 net/core/sock.c:473
dccp_v4_rcv+0x10cb/0x1f80 net/dccp/ipv4.c:880
ip_protocol_deliver_rcu+0xb6/0xa20 net/ipv4/ip_input.c:208
ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
ip_local_deliver+0x1f0/0x740 net/ipv4/ip_input.c:255
dst_input include/net/dst.h:450 [inline]
ip_rcv_finish+0x1f4/0x2f0 net/ipv4/ip_input.c:414
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
ip_rcv+0xed/0x620 net/ipv4/ip_input.c:524
__netif_receive_skb_one_core+0x160/0x210 net/core/dev.c:4973
__netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083
process_backlog+0x206/0x750 net/core/dev.c:5923
napi_poll net/core/dev.c:6346 [inline]
net_rx_action+0x76d/0x1930 net/core/dev.c:6412
__do_softirq+0x30b/0xb11 kernel/softirq.c:292
run_ksoftirqd kernel/softirq.c:654 [inline]
run_ksoftirqd+0x8e/0x110 kernel/softirq.c:646
smpboot_thread_fn+0x6ab/0xa10 kernel/smpboot.c:164
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace
58a0ba03bea2c376 ]---
RIP: 0010:ccid_hc_tx_parse_options net/dccp/ccid.h:205 [inline]
RIP: 0010:dccp_parse_options+0x8d9/0x12b0 net/dccp/options.c:233
Code: c5 0f b6 75 b3 80 38 00 0f 85 d6 08 00 00 48 b9 00 00 00 00 00 fc ff df 48 8b 45 b8 4c 8b b8 f8 07 00 00 4c 89 f8 48 c1 e8 03 <80> 3c 08 00 0f 85 95 08 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b
RSP: 0018:
ffff8880a94df0b8 EFLAGS:
00010246
RAX:
0000000000000000 RBX:
ffff8880858ac723 RCX:
dffffc0000000000
RDX:
0000000000000100 RSI:
0000000000000007 RDI:
0000000000000001
RBP:
ffff8880a94df140 R08:
0000000000000001 R09:
ffff888061b83a80
R10:
ffffed100c370752 R11:
ffff888061b83a97 R12:
0000000000000026
R13:
0000000000000001 R14:
0000000000000000 R15:
0000000000000000
FS:
0000000000000000(0000) GS:
ffff8880ae700000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00007f0defa33518 CR3:
0000000009871000 CR4:
00000000001406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Tue, 9 Jan 2018 15:21:15 +0000 (07:21 -0800)]
string: drop __must_check from strscpy() and restore strscpy() usages in cgroup
commit
08a77676f9c5fc69a681ccd2cd8140e65dcb26c7 upstream.
e7fd37ba1217 ("cgroup: avoid copying strings longer than the buffers")
converted possibly unsafe strncpy() usages in cgroup to strscpy().
However, although the callsites are completely fine with truncated
copied, because strscpy() is marked __must_check, it led to the
following warnings.
kernel/cgroup/cgroup.c: In function ‘cgroup_file_name’:
kernel/cgroup/cgroup.c:1400:10: warning: ignoring return value of ‘strscpy’, declared with attribute warn_unused_result [-Wunused-result]
strscpy(buf, cft->name, CGROUP_FILE_NAME_MAX);
^
To avoid the warnings,
50034ed49645 ("cgroup: use strlcpy() instead of
strscpy() to avoid spurious warning") switched them to strlcpy().
strlcpy() is worse than strlcpy() because it unconditionally runs
strlen() on the source string, and the only reason we switched to
strlcpy() here was because it was lacking __must_check, which doesn't
reflect any material differences between the two function. It's just
that someone added __must_check to strscpy() and not to strlcpy().
These basic string copy operations are used in variety of ways, and
one of not-so-uncommon use cases is safely handling truncated copies,
where the caller naturally doesn't care about the return value. The
__must_check doesn't match the actual use cases and forces users to
opt for inferior variants which lack __must_check by happenstance or
spread ugly (void) casts.
Remove __must_check from strscpy() and restore strscpy() usages in
cgroup.
Signed-off-by: Tejun Heo <tj@kernel.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
[backport only the string.h portion to remove build warnings starting to show up - gregkh]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guoqing Jiang [Fri, 19 Oct 2018 04:08:22 +0000 (12:08 +0800)]
tipc: use destination length for copy string
commit
29e270fc32192e7729057963ae7120663856c93e upstream.
Got below warning with gcc 8.2 compiler.
net/tipc/topsrv.c: In function ‘tipc_topsrv_start’:
net/tipc/topsrv.c:660:2: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
strncpy(srv->name, name, strlen(name) + 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/tipc/topsrv.c:660:27: note: length computed here
strncpy(srv->name, name, strlen(name) + 1);
^~~~~~~~~~~~
So change it to correct length and use strscpy.
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Fri, 30 Nov 2018 20:13:15 +0000 (12:13 -0800)]
test_hexdump: use memcpy instead of strncpy
commit
b1286ed7158e9b62787508066283ab0b8850b518 upstream.
New versions of gcc reasonably warn about the odd pattern of
strncpy(p, q, strlen(q));
which really doesn't make sense: the strncpy() ends up being just a slow
and odd way to write memcpy() in this case.
Apparently there was a patch for this floating around earlier, but it
got lost.
Acked-again-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eduardo Valentin [Wed, 2 Jan 2019 00:34:03 +0000 (00:34 +0000)]
thermal: hwmon: inline helpers when CONFIG_THERMAL_HWMON is not set
commit
03334ba8b425b2ad275c8f390cf83c7b081c3095 upstream.
Avoid warnings like this:
thermal_hwmon.h:29:1: warning: ‘thermal_remove_hwmon_sysfs’ defined but not used [-Wunused-function]
thermal_remove_hwmon_sysfs(struct thermal_zone_device *tz)
Fixes:
0dd88793aacd ("thermal: hwmon: move hwmon support to single file")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Thu, 3 Jan 2019 23:28:07 +0000 (15:28 -0800)]
exec: load_script: don't blindly truncate shebang string
[ Upstream commit
8099b047ecc431518b9bb6bdbba3549bbecdc343 ]
load_script() simply truncates bprm->buf and this is very wrong if the
length of shebang string exceeds BINPRM_BUF_SIZE-2. This can silently
truncate i_arg or (worse) we can execute the wrong binary if buf[2:126]
happens to be the valid executable path.
Change load_script() to return ENOEXEC if it can't find '\n' or zero in
bprm->buf. Note that '\0' can come from either
prepare_binprm()->memset() or from kernel_read(), we do not care.
Link: http://lkml.kernel.org/r/20181112160931.GA28463@redhat.com
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Ben Woodard <woodard@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>