- 20 Jun, 2020 1 commit
-
-
Hangbin Liu authored
[ Upstream commit 79a1f0cc ] Socket option IPV6_ADDRFORM supports UDP/UDPLITE and TCP at present. Previously the checking logic looks like: if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE) do_some_check; else if (sk->sk_protocol != IPPROTO_TCP) break; After commit b6f61189 ("ipv6: restrict IPV6_ADDRFORM operation"), TCP was blocked as the logic changed to: if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE) do_some_check; else if (sk->sk_protocol == IPPROTO_TCP) do_some_check; break; else break; Then after commit 82c9ae44 ("ipv6: fix restrict IPV6_ADDRFORM operation") UDP/UDPLITE were blocked as the logic changed to: if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE) do_some_check; if (sk->sk_protocol == IPPROTO_TCP) do_some_check; if (sk->sk_protocol != IPPROTO_TCP) break; Fix it by using Eric's code and simply remove the break in TCP check, which looks like: if (sk->sk_protocol == IPPROTO_UDP || sk->sk_protocol == IPPROTO_UDPLITE) do_some_check; else if (sk->sk_protocol == IPPROTO_TCP) do_some_check; else break; Fixes: 82c9ae44 ("ipv6: fix restrict IPV6_ADDRFORM operation") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 11 Jun, 2020 39 commits
-
-
Greg Kroah-Hartman authored
-
Oleg Nesterov authored
commit 013b2deb upstream. uprobe_write_opcode() must not cross page boundary; prepare_uprobe() relies on arch_uprobe_analyze_insn() which should validate "vaddr" but some architectures (csky, s390, and sparc) don't do this. We can remove the BUG_ON() check in prepare_uprobe() and validate the offset early in __uprobe_register(). The new IS_ALIGNED() check matches the alignment check in arch_prepare_kprobe() on supported architectures, so I think that all insns must be aligned to UPROBE_SWBP_INSN_SIZE. Another problem is __update_ref_ctr() which was wrong from the very beginning, it can read/write outside of kmap'ed page unless "vaddr" is aligned to sizeof(short), __uprobe_register() should check this too. Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Suggested-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
Srikar Dronamraju <srikar@linux.vnet.ibm.com> Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Tested-by:
Sven Schnelle <svens@linux.ibm.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Mathieu Othacehe authored
[ Upstream commit 18dfb532 ] The bytes returned by the i2c reading need to be swapped unconditionally. Otherwise, on be16 platforms, an incorrect value will be returned. Taking the slow path via next merge window as its been around a while and we have a patch set dependent on this which would be held up. Fixes: 62a1efb9 ("iio: add vcnl4000 combined ALS and proximity sensor") Signed-off-by:
Mathieu Othacehe <m.othacehe@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Josh Poimboeuf authored
commit 3798cc4d upstream Make the docs match the code. Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Mark Gross authored
commit 7222a1b5 upstream Add documentation for the SRBDS vulnerability and its mitigation. [ bp: Massage. jpoimboe: sysfs table strings. ] Signed-off-by:
Mark Gross <mgross@linux.intel.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Tony Luck <tony.luck@intel.com> Reviewed-by:
-
Mark Gross authored
commit 7e5b3c26 upstream SRBDS is an MDS-like speculative side channel that can leak bits from the random number generator (RNG) across cores and threads. New microcode serializes the processor access during the execution of RDRAND and RDSEED. This ensures that the shared buffer is overwritten before it is released for reuse. While it is present on all affected CPU models, the microcode mitigation is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the cases where TSX is not supported or has been disabled with TSX_CTRL. The mitigation is activated by default on affected processors and it increases latency for RDRAND and RDSEED instructions. Among other effects this will reduce throughput from /dev/urandom. * Enable administrator to configure the mitigation off when desired using either mitigations=off or srbds=off. * Export vulnerability status via sysfs * Rename file-scoped macros to apply for non-whitelist table initializations. [ bp: Massage, - s/VULNBL_INTEL_STEPPING/VULNBL_INTEL_STEPPINGS/g, - do not read arch cap MSR a second time in tsx_fused_off() - just pass it in, - flip check in cpu_set_bug_bits() to save an indentation level, - reflow comments. jpoimboe: s/Mitigated/Mitigation/ in user-visible strings tglx: Dropped the fused off magic for now ] Signed-off-by:
Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Reviewed-by:
Neelima Krishnan <neelima.krishnan@intel.com> Signed-off-by:
-
Mark Gross authored
commit 93920f61 upstream To make cpu_matches() reusable for other matching tables, have it take a pointer to a x86_cpu_id table as an argument. [ bp: Flip arguments order. ] Signed-off-by:
-
Mark Gross authored
commit e9d71445 upstream Intel uses the same family/model for several CPUs. Sometimes the stepping must be checked to tell them apart. On x86 there can be at most 16 steppings. Add a steppings bitmask to x86_cpu_id and a X86_MATCH_VENDOR_FAMILY_MODEL_STEPPING_FEATURE macro and support for matching against family/model/stepping. [ bp: Massage. tglx: Lightweight variant for backporting ] Signed-off-by:
-
Srinivas Kandagatla authored
commit 8d9eb0d6 upstream. qfprom has different address spaces for read and write. Reads are always done from corrected address space, where as writes are done on raw address space. Writing to corrected address space is invalid and ignored, so it does not make sense to have this support in the driver which only supports corrected address space regions at the moment. Fixes: 4ab11996 ("nvmem: qfprom: Add Qualcomm QFPROM support.") Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200522113341.7728-1-srinivas.kandagatla@linaro.orgSigned-off-by:
-
Pascal Terjan authored
commit 15ea976a upstream. The value in shared headers was fixed 9 years ago in commit 8d661f1e ("ieee80211: correct IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK macro") and while looking at using shared headers for other duplicated constants I noticed this driver uses the old value. The macros are also defined twice in this file so I am deleting the second definition. Signed-off-by:
Pascal Terjan <pterjan@google.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200523211247.23262-1-pterjan@google.comSigned-off-by:
-
Jiri Slaby authored
commit 24eb2377 upstream. hvc_open sets tty->driver_data to NULL when open fails at some point. Typically, the failure happens in hp->ops->notifier_add(). If there is a racing process which tries to open such mangled tty, which was not closed yet, the process will crash in hvc_open as tty->driver_data is NULL. All this happens because close wants to know whether open failed or not. But ->open should not NULL this and other tty fields for ->close to be happy. ->open should call tty_port_set_initialized(true) and close should check by tty_port_initialized() instead. So do this properly in this driver. So this patch removes these from ->open: * tty_port_tty_set(&hp->port, NULL). This happens on last close. * tty->driver_data = NULL. Dtto. * tty_port_put(&hp->port). This happens in shutdown and until now, this must have been causing a reference underflow, if I am not missing something. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: stable <stable@vger.kernel.org> Reported-and-tested-by:
Raghavendra <rananta@codeaurora.org> Link: https://lore.kernel.org/r/20200526145632.13879-1-jslaby@suse.czSigned-off-by:
-
Dmitry Torokhov authored
commit b86dab05 upstream. When k_ascii is invoked several times in a row there is a potential for signed integer overflow: UBSAN: Undefined behaviour in drivers/tty/vt/keyboard.c:888:19 signed integer overflow: 10 * 1111111111 cannot be represented in type 'int' CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xce/0x128 lib/dump_stack.c:118 ubsan_epilogue+0xe/0x30 lib/ubsan.c:154 handle_overflow+0xdc/0xf0 lib/ubsan.c:184 __ubsan_handle_mul_overflow+0x2a/0x40 lib/ubsan.c:205 k_ascii+0xbf/0xd0 drivers/tty/vt/keyboard.c:888 kbd_keycode drivers/tty/vt/keyboard.c:1477 [inline] kbd_event+0x888/0x3be0 drivers/tty/vt/keyboard.c:1495 While it can be worked around by using check_mul_overflow()/ check_add_overflow(), it is better to introduce a separate flag to signal that number pad is being used to compose a symbol, and change type of the accumulator from signed to unsigned, thus avoiding undefined behavior when it overflows. Reported-by:
Kyungtae Kim <kt0755@gmail.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200525232740.GA262061@dtor-wsSigned-off-by:
-
Dinghao Liu authored
commit e4befc12 upstream. When copy_from_user() returns an error code, there is a runtime PM usage counter imbalance. Fix this by moving copy_from_user() to the beginning of this function. Fixes: 7b6c1b4c ("usb: musb: fix runtime PM in debugfs") Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Cc: stable@vger.kernel.org Signed-off-by:
Bin Liu <b-liu@ti.com> Link: https://lore.kernel.org/r/20200525025049.3400-7-b-liu@ti.comSigned-off-by:
-
Daniele Palmas authored
commit 399ad947 upstream. Add Telit LE910C1-EUX compositions: 0x1031: tty, tty, tty, rmnet 0x1033: tty, tty, tty, ecm Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Link: https://lore.kernel.org/r/20200525211106.27338-1-dnlplm@gmail.com Cc: stable@vger.kernel.org Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Bin Liu authored
commit 986c1748 upstream. usb_wwan_indat_callback() shouldn't resubmit rx urb if the previous urb status is a fatal error. Or the usb controller would keep processing the new urbs then run into interrupt storm, and has no chance to recover. Fixes: 6c1ee66a ("USB-Serial: Fix error handling of usb_wwan") Cc: stable@vger.kernel.org Signed-off-by:
-
Matt Jolly authored
commit 3429444a upstream. Add support for Dell Wireless 5816e Download Mode (AKA boot & hold mode / QDL download mode) to drivers/usb/serial/qcserial.c This is required to update device firmware. Signed-off-by:
Matt Jolly <Kangie@footclan.ninja> Cc: stable@vger.kernel.org Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit d9a81a22 ] syzbot was able to trigger a crash after using an ISDN socket and fool l2tp. Fix this by making sure the UDP socket is of the proper family. BUG: KASAN: slab-out-of-bounds in setup_udp_tunnel_sock+0x465/0x540 net/ipv4/udp_tunnel.c:78 Write of size 1 at addr ffff88808ed0c590 by task syz-executor.5/3018 CPU: 0 PID: 3018 Comm: syz-executor.5 Not tainted 5.7.0-rc6-syzkaller #0 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+0x188/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd3/0x413 mm/kasan/report.c:382 __kasan_report.cold+0x20/0x38 mm/kasan/report.c:511 kasan_report+0x33/0x50 mm/kasan/common.c:625 setup_udp_tunnel_sock+0x465/0x540 net/ipv4/udp_tunnel.c:78 l2tp_tunnel_register+0xb15/0xdd0 net/l2tp/l2tp_core.c:1523 l2tp_nl_cmd_tunnel_create+0x4b2/0xa60 net/l2tp/l2tp_netlink.c:249 genl_family_rcv_msg_doit net/netlink/genetlink.c:673 [inline] genl_family_rcv_msg net/netlink/genetlink.c:718 [inline] genl_rcv_msg+0x627/0xdf0 net/netlink/genetlink.c:735 netlink_rcv_skb+0x15a/0x410 net/netlink/af_netlink.c:2469 genl_rcv+0x24/0x40 net/netlink/genetlink.c:746 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] netlink_unicast+0x537/0x740 net/netlink/af_netlink.c:1329 netlink_sendmsg+0x882/0xe10 net/netlink/af_netlink.c:1918 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 ____sys_sendmsg+0x6e6/0x810 net/socket.c:2352 ___sys_sendmsg+0x100/0x170 net/socket.c:2406 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2439 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x45ca29 Code: 0d 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 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007effe76edc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000004fe1c0 RCX: 000000000045ca29 RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 000000000000094e R14: 00000000004d5d00 R15: 00007effe76ee6d4 Allocated by task 3018: save_stack+0x1b/0x40 mm/kasan/common.c:49 set_track mm/kasan/common.c:57 [inline] __kasan_kmalloc mm/kasan/common.c:495 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:468 __do_kmalloc mm/slab.c:3656 [inline] __kmalloc+0x161/0x7a0 mm/slab.c:3665 kmalloc include/linux/slab.h:560 [inline] sk_prot_alloc+0x223/0x2f0 net/core/sock.c:1612 sk_alloc+0x36/0x1100 net/core/sock.c:1666 data_sock_create drivers/isdn/mISDN/socket.c:600 [inline] mISDN_sock_create+0x272/0x400 drivers/isdn/mISDN/socket.c:796 __sock_create+0x3cb/0x730 net/socket.c:1428 sock_create net/socket.c:1479 [inline] __sys_socket+0xef/0x200 net/socket.c:1521 __do_sys_socket net/socket.c:1530 [inline] __se_sys_socket net/socket.c:1528 [inline] __x64_sys_socket+0x6f/0xb0 net/socket.c:1528 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 Freed by task 2484: save_stack+0x1b/0x40 mm/kasan/common.c:49 set_track mm/kasan/common.c:57 [inline] kasan_set_free_info mm/kasan/common.c:317 [inline] __kasan_slab_free+0xf7/0x140 mm/kasan/common.c:456 __cache_free mm/slab.c:3426 [inline] kfree+0x109/0x2b0 mm/slab.c:3757 kvfree+0x42/0x50 mm/util.c:603 __free_fdtable+0x2d/0x70 fs/file.c:31 put_files_struct fs/file.c:420 [inline] put_files_struct+0x248/0x2e0 fs/file.c:413 exit_files+0x7e/0xa0 fs/file.c:445 do_exit+0xb04/0x2dd0 kernel/exit.c:791 do_group_exit+0x125/0x340 kernel/exit.c:894 get_signal+0x47b/0x24e0 kernel/signal.c:2739 do_signal+0x81/0x2240 arch/x86/kernel/signal.c:784 exit_to_usermode_loop+0x26c/0x360 arch/x86/entry/common.c:161 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline] syscall_return_slowpath arch/x86/entry/common.c:279 [inline] do_syscall_64+0x6b1/0x7d0 arch/x86/entry/common.c:305 entry_SYSCALL_64_after_hwframe+0x49/0xb3 The buggy address belongs to the object at ffff88808ed0c000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1424 bytes inside of 2048-byte region [ffff88808ed0c000, ffff88808ed0c800) The buggy address belongs to the page: page:ffffea00023b4300 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 flags: 0xfffe0000000200(slab) raw: 00fffe0000000200 ffffea0002838208 ffffea00015ba288 ffff8880aa000e00 raw: 0000000000000000 ffff88808ed0c000 0000000100000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88808ed0c480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88808ed0c500: 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88808ed0c580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88808ed0c600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88808ed0c680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Fixes: 6b9f3423 ("l2tp: fix races in tunnel creation") Fixes: fd558d18 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: James Chapman <jchapman@katalix.com> Cc: Guillaume Nault <gnault@redhat.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Acked-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
-
Stefano Garzarella authored
[ Upstream commit 7e0afbdf ] The accept(2) is an "input" socket interface, so we should use SO_RCVTIMEO instead of SO_SNDTIMEO to set the timeout. So this patch replace sock_sndtimeo() with sock_rcvtimeo() to use the right timeout in the vsock_accept(). Fixes: d021c344 ("VSOCK: Introduce VM Sockets") Signed-off-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Jorgen Hansen <jhansen@vmware.com> Signed-off-by:
-
Chuhong Yuan authored
[ Upstream commit 3decabdc ] st21nfca_tm_send_atr_res() misses to call kfree_skb() in an error path. Add the missed function call to fix it. Fixes: 1892bf84 ("NFC: st21nfca: Adding P2P support to st21nfca in Initiator & Target mode") Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
-
Daniele Palmas authored
[ Upstream commit 591612aa ] Add support for Telit LE910C1-EUX composition 0x1031: tty, tty, tty, rmnet Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 02c71b14 ] syzbot recently found a way to crash the kernel [1] Issue here is that inet_hash() & inet_unhash() are currently only meant to be used by TCP & DCCP, since only these protocols provide the needed hashinfo pointer. L2TP uses a single list (instead of a hash table) This old bug became an issue after commit 61023658 ("bpf: Add new cgroup attach type to enable sock modifications") since after this commit, sk_common_release() can be called while the L2TP socket is still considered 'hashed'. general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 7063 Comm: syz-executor654 Not tainted 5.7.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600 Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e dd 04 00 00 48 8d 7d 08 44 8b 73 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 55 05 00 00 48 8d 7d 14 4c 8b 6d 08 48 b8 00 00 RSP: 0018:ffffc90001777d30 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff88809a6df940 RCX: ffffffff8697c242 RDX: 0000000000000001 RSI: ffffffff8697c251 RDI: 0000000000000008 RBP: 0000000000000000 R08: ffff88809f3ae1c0 R09: fffffbfff1514cc1 R10: ffffffff8a8a6607 R11: fffffbfff1514cc0 R12: ffff88809a6df9b0 R13: 0000000000000007 R14: 0000000000000000 R15: ffffffff873a4d00 FS: 0000000001d2b880(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000006cd090 CR3: 000000009403a000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sk_common_release+0xba/0x370 net/core/sock.c:3210 inet_create net/ipv4/af_inet.c:390 [inline] inet_create+0x966/0xe00 net/ipv4/af_inet.c:248 __sock_create+0x3cb/0x730 net/socket.c:1428 sock_create net/socket.c:1479 [inline] __sys_socket+0xef/0x200 net/socket.c:1521 __do_sys_socket net/socket.c:1530 [inline] __se_sys_socket net/socket.c:1528 [inline] __x64_sys_socket+0x6f/0xb0 net/socket.c:1528 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x441e29 Code: e8 fc b3 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 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 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffdce184148 EFLAGS: 00000246 ORIG_RAX: 0000000000000029 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441e29 RDX: 0000000000000073 RSI: 0000000000000002 RDI: 0000000000000002 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000402c30 R14: 0000000000000000 R15: 0000000000000000 Modules linked in: ---[ end trace 23b6578228ce553e ]--- RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600 Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e dd 04 00 00 48 8d 7d 08 44 8b 73 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 55 05 00 00 48 8d 7d 14 4c 8b 6d 08 48 b8 00 00 RSP: 0018:ffffc90001777d30 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff88809a6df940 RCX: ffffffff8697c242 RDX: 0000000000000001 RSI: ffffffff8697c251 RDI: 0000000000000008 RBP: 0000000000000000 R08: ffff88809f3ae1c0 R09: fffffbfff1514cc1 R10: ffffffff8a8a6607 R11: fffffbfff1514cc0 R12: ffff88809a6df9b0 R13: 0000000000000007 R14: 0000000000000000 R15: ffffffff873a4d00 FS: 0000000001d2b880(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000006cd090 CR3: 000000009403a000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Fixes: 0d76751f ("l2tp: Add L2TPv3 IP encapsulation (no UDP) support") Signed-off-by:
-
Yang Yingliang authored
[ Upstream commit 1b49cd71 ] When devinet_sysctl_register() failed, the memory allocated in neigh_parms_alloc() should be freed. Fixes: 20e61da7 ("ipv4: fail early when creating netdev named all or default") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Acked-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Dan Carpenter authored
commit 11e7a919 upstream. The problem is that we always copy a minimum of ETH_ZLEN (60) bytes from skb->data even when skb->len is less than ETH_ZLEN so it leads to a read overflow. The fix is to pad skb->data to at least ETH_ZLEN bytes. Cc: <stable@vger.kernel.org> Reported-by:
Hu Jiahui <kirin.say@gmail.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200527184830.GA1164846@mwandaSigned-off-by:
-
Can Guo authored
commit 17c7d35f upstream. In queuecommand path, if DMA map fails, it bails out with clock held. In this case, release the clock to keep its usage paired. [mkp: applied by hand] Link: https://lore.kernel.org/r/0101016ed3d66395-1b7e7fce-b74d-42ca-a88a-4db78b795d3b-000000@us-west-2.amazonses.comReviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> [EB: resolved cherry-pick conflict caused by newer kernels not having the clear_bit_unlock() line] Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
yangerkun authored
commit f596c870 upstream. As the description before netdev_run_todo, we cannot call free_netdev before rtnl_unlock, fix it by reorder the code. Signed-off-by:
yangerkun <yangerkun@huawei.com> Reviewed-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Ben Hutchings authored
Commit 9ebd796e ("can: slcan: Fix use-after-free Read in slcan_open") was incorrectly backported to 4.4 and 4.9 stable branches. Since they do not have commit cf124db5 ("net: Fix inconsistent teardown and release of private netdev state."), the destructor function slc_free_netdev() is already responsible for calling free_netdev() and slcan_open() must not call both of them. yangerkun previously fixed the same bug in slip. Fixes: ce624b2089ea ("can: slcan: Fix use-after-free Read in slcan_open") # 4.4 Fixes: f59604a80fa4 ("slcan: not call free_netdev before rtnl_unlock ...") # 4.4 Fixes: 56635a1e ("can: slcan: Fix use-after-free Read in slcan_open") # 4.9 Fixes: a1c9b231 ("slcan: not call free_netdev before rtnl_unlock ...") # 4.9 Cc: yangerkun <yangerkun@huawei.com> Signed-off-by:
-
Jérôme Pouiller authored
commit 83fc5dd5 upstream. The definitions of MMC_IOC_CMD and of MMC_IOC_MULTI_CMD rely on MMC_BLOCK_MAJOR: #define MMC_IOC_CMD _IOWR(MMC_BLOCK_MAJOR, 0, struct mmc_ioc_cmd) #define MMC_IOC_MULTI_CMD _IOWR(MMC_BLOCK_MAJOR, 1, struct mmc_ioc_multi_cmd) However, MMC_BLOCK_MAJOR is defined in linux/major.h and linux/mmc/ioctl.h did not include it. Signed-off-by:
Jérôme Pouiller <jerome.pouiller@silabs.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200511161902.191405-1-Jerome.Pouiller@silabs.comSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Daniel Axtens authored
commit 54e200ab upstream. alloc_percpu() may return NULL, which means chan->buf may be set to NULL. In that case, when we do *per_cpu_ptr(chan->buf, ...), we dereference an invalid pointer: BUG: Unable to handle kernel data access at 0x7dae0000 Faulting instruction address: 0xc0000000003f3fec ... NIP relay_open+0x29c/0x600 LR relay_open+0x270/0x600 Call Trace: relay_open+0x264/0x600 (unreliable) __blk_trace_setup+0x254/0x600 blk_trace_setup+0x68/0xa0 sg_ioctl+0x7bc/0x2e80 do_vfs_ioctl+0x13c/0x1300 ksys_ioctl+0x94/0x130 sys_ioctl+0x48/0xb0 system_call+0x5c/0x68 Check if alloc_percpu returns NULL. This was found by syzkaller both on x86 and powerpc, and the reproducer it found on powerpc is capable of hitting the issue as an unprivileged user. Fixes: 017c59c0 ("relay: Use per CPU constructs for the relay channel buffer pointers") Reported-by: syzbot+1e925b4b836afe85a1c6@syzkaller-ppc64.appspotmail.com Reported-by: syzbot+587b2421926808309d21@syzkaller-ppc64.appspotmail.com Reported-by: syzbot+58320b7171734bf79d26@syzkaller.appspotmail.com Reported-by: syzbot+d6074fb08bdb2e010520@syzkaller.appspotmail.com Signed-off-by:
Daniel Axtens <dja@axtens.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Reviewed-by:
Michael Ellerman <mpe@ellerman.id.au> Reviewed-by:
Andrew Donnellan <ajd@linux.ibm.com> Acked-by:
David Rientjes <rientjes@google.com> Cc: Akash Goel <akash.goel@intel.com> Cc: Andrew Donnellan <ajd@linux.ibm.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Salvatore Bonaccorso <carnil@debian.org> Cc: <stable@vger.kernel.org> [4.10+] Link: http://lkml.kernel.org/r/20191219121256.26480-1-dja@axtens.netSigned-off-by:
-
Giuseppe Marco Randazzo authored
commit 63e49a9f upstream. This patch adds the AirVasT USB wireless devices 124a:4026 to the list of supported devices. It's using the ISL3886 usb firmware. Without this modification, the wiki adapter is not recognized. Cc: <stable@vger.kernel.org> Signed-off-by:
Giuseppe Marco Randazzo <gmrandazzo@gmail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> [formatted, reworded] Signed-off-by:
-
Julian Sax authored
commit 6507ef10 upstream. This device uses the SIPODEV SP1064 touchpad, which does not supply descriptors, so it has to be added to the override list. Cc: stable@vger.kernel.org Signed-off-by:
Julian Sax <jsbc@gmx.de> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Fan Yang authored
commit 5bfea2d9 upstream. The original code in mm/mremap.c checks huge pmd by: if (is_swap_pmd(*old_pmd) || pmd_trans_huge(*old_pmd)) { However, a DAX mapped nvdimm is mapped as huge page (by default) but it is not transparent huge page (_PAGE_PSE | PAGE_DEVMAP). This commit changes the condition to include the case. This addresses CVE-2020-10757. Fixes: 5c7fb56e ("mm, dax: dax-pmd vs thp-pmd vs hugetlbfs-pmd") Cc: <stable@vger.kernel.org> Reported-by:
Fan Yang <Fan_Yang@sjtu.edu.cn> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
-
Guillaume Nault authored
We don't want to disconnect a session because of a stray PADT arriving while the interface is in promiscuous mode. Furthermore, multicast and broadcast packets make no sense here, so only PACKET_HOST is accepted. Reported-by:
David Balažic <xerces9@gmail.com> Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Dinghao Liu authored
[ Upstream commit 539d39ad ] Remove runtime PM usage counter decrement when the increment function has not been called to keep the counter balanced. Signed-off-by:
-
Jonathan McDowell authored
[ Upstream commit a96ac8a0 ] The ipq806x_gmac_probe() function enables the PTP clock but not the appropriate interface clocks. This means that if the bootloader hasn't done so attempting to bring up the interface will fail with an error like: [ 59.028131] ipq806x-gmac-dwmac 37600000.ethernet: Failed to reset the dma [ 59.028196] ipq806x-gmac-dwmac 37600000.ethernet eth1: stmmac_hw_setup: DMA engine initialization failed [ 59.034056] ipq806x-gmac-dwmac 37600000.ethernet eth1: stmmac_open: Hw setup failed This patch, a slightly cleaned up version of one posted by Sergey Sergeev in: https://forum.openwrt.org/t/support-for-mikrotik-rb3011uias-rm/4064/257 correctly enables the clock; we have already configured the source just before this. Tested on a MikroTik RB3011. Signed-off-by:
Jonathan McDowell <noodles@earth.li> Signed-off-by:
-
Valentin Longchamp authored
[ Upstream commit 79dde73c ] ugeth_quiesce/activate are used to halt the controller when there is a link change that requires to reconfigure the mac. The previous implementation called netif_device_detach(). This however causes the initial activation of the netdevice to fail precisely because it's detached. For details, see [1]. A possible workaround was the revert of commit net: linkwatch: add check for netdevice being present to linkwatch_do_dev However, the check introduced in the above commit is correct and shall be kept. The netif_device_detach() is thus replaced with netif_tx_stop_all_queues() that prevents any tranmission. This allows to perform mac config change required by the link change, without detaching the corresponding netdevice and thus not preventing its initial activation. [1] https://lists.openwall.net/netdev/2020/01/08/201Signed-off-by:
Valentin Longchamp <valentin@longchamp.me> Acked-by:
Matteo Ghidoni <matteo.ghidoni@ch.abb.com> Signed-off-by:
-
Jeremy Kerr authored
[ Upstream commit ef01cee2 ] In bmac_get_station_address, We're reading two bytes at a time from ROM, but we do that six times, resulting in 12 bytes of read & writes. This means we will write off the end of the six-byte destination buffer. This change fixes the for-loop to only read/write six bytes. Based on a proposed fix from Finn Thain <fthain@telegraphics.com.au>. Signed-off-by:
Jeremy Kerr <jk@ozlabs.org> Reported-by:
Stan Johnson <userm57@yahoo.com> Tested-by:
Finn Thain <fthain@telegraphics.com.au> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit d7110a26 ] When building with Clang + -Wtautological-compare and CONFIG_CPUMASK_OFFSTACK unset: arch/x86/mm/mmio-mod.c:375:6: warning: comparison of array 'downed_cpus' equal to a null pointer is always false [-Wtautological-pointer-compare] if (downed_cpus == NULL && ^~~~~~~~~~~ ~~~~ arch/x86/mm/mmio-mod.c:405:6: warning: comparison of array 'downed_cpus' equal to a null pointer is always false [-Wtautological-pointer-compare] if (downed_cpus == NULL || cpumask_weight(downed_cpus) == 0) ^~~~~~~~~~~ ~~~~ 2 warnings generated. Commit f7e30f01 ("cpumask: Add helper cpumask_available()") added cpumask_available() to fix warnings of this nature. Use that here so that clang does not warn regardless of CONFIG_CPUMASK_OFFSTACK's value. Reported-by:
Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Acked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://github.com/ClangBuiltLinux/linux/issues/982 Link: https://lkml.kernel.org/r/20200408205323.44490-1-natechancellor@gmail.comSigned-off-by:
-
Eugeniy Paltsev authored
[ Upstream commit 43900edf ] As of today the ICCM and DCCM size checks are incorrectly using mismatched units (KiB checked against bytes). The CONFIG_ARC_DCCM_SZ and CONFIG_ARC_ICCM_SZ are in KiB, but the size calculated in runtime and stored in cpu->dccm.sz and cpu->iccm.sz is in bytes. Fix that. Reported-by:
Paul Greco <pmgreco@us.ibm.com> Signed-off-by:
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Vasily Gorbik authored
[ Upstream commit b4adfe55 ] A typical backtrace acquired from ftraced function currently looks like the following (e.g. for "path_openat"): arch_stack_walk+0x15c/0x2d8 stack_trace_save+0x50/0x68 stack_trace_call+0x15a/0x3b8 ftrace_graph_caller+0x0/0x1c 0x3e0007e3c98 <- ftraced function caller (should be do_filp_open+0x7c/0xe8) do_open_execat+0x70/0x1b8 __do_execve_file.isra.0+0x7d8/0x860 __s390x_sys_execve+0x56/0x68 system_call+0xdc/0x2d8 Note random "0x3e0007e3c98" stack value as ftraced function caller. This value causes either imprecise unwinder result or unwinding failure. That "0x3e0007e3c98" comes from r14 of ftraced function stack frame, which it haven't had a chance to initialize since the very first instruction calls ftrace code ("ftrace_caller"). (ftraced function might never save r14 as well). Nevertheless according to s390 ABI any function is called with stack frame allocated for it and r14 contains return address. "ftrace_caller" itself is called with "brasl %r0,ftrace_caller". So, to fix this issue simply always save traced function caller onto ftraced function stack frame. Reported-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
-
