- 01 Apr, 2019 40 commits
-
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 895a5e96 ] syzkaller report this: BUG: memory leak unreferenced object 0xffff88837a71a500 (size 256): comm "syz-executor.2", pid 9770, jiffies 4297825125 (age 17.843s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 20 c0 ef 86 ff ff ff ff ........ ....... backtrace: [<00000000db12624b>] netdev_register_kobject+0x124/0x2e0 net/core/net-sysfs.c:1751 [<00000000dc49a994>] register_netdevice+0xcc1/0x1270 net/core/dev.c:8516 [<00000000e5f3fea0>] tun_set_iff drivers/net/tun.c:2649 [inline] [<00000000e5f3fea0>] __tun_chr_ioctl+0x2218/0x3d20 drivers/net/tun.c:2883 [<000000001b8ac127>] vfs_ioctl fs/ioctl.c:46 [inline] [<000000001b8ac127>] do_vfs_ioctl+0x1a5/0x10e0 fs/ioctl.c:690 [<0000000079b269f8>] ksys_ioctl+0x89/0xa0 fs/ioctl.c:705 [<00000000de649beb>] __do_sys_ioctl fs/ioctl.c:712 [inline] [<00000000de649beb>] __se_sys_ioctl fs/ioctl.c:710 [inline] [<00000000de649beb>] __x64_sys_ioctl+0x74/0xb0 fs/ioctl.c:710 [<000000007ebded1e>] do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290 [<00000000db315d36>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [<00000000115be9bb>] 0xffffffffffffffff It should call kset_unregister to free 'dev->queues_kset' in error path of register_queue_kobjects, otherwise will cause a mem leak. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 1d24eb48 ("xps: Transmit Packet Steering") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Juerg Haefliger <juerg.haefliger@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Dmitry Eremin authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit 9563fe8a upstream. Buffer overflow of string buffer due to non null terminated string. Use strlcpy() when it's justifiable. Use sizeof(var) instead of constants. Signed-off-by:
Dmitry Eremin <dmitry.eremin@intel.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4629 Reviewed-on: http://review.whamcloud.com/9389Reviewed-by:
Andreas Dilger <andreas.dilger@intel.com> Reviewed-by:
Oleg Drokin <oleg.drokin@intel.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1822271 Not upstream as isdn is long deleted. Fix up a strncpy build warning for isdn_tty_suspend() using strscpy. It's not like anyone uses this code anyway, and this gets rid of a build warnings so that we can see real warnings as they pop up over time. Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1822271 Not upstream as ncpfs is long deleted. Fix up two strncpy build warnings in ncp_get_charsets() by using strscpy and the max size of the array. It's not like anyone uses this code anyway, and this gets rid of two build warnings so that we can see real warnings as they pop up over time. Signed-off-by:
-
Andreas Gruenbacher authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit 971df15b upstream. The standard return value for unsupported attribute names is -EOPNOTSUPP, as opposed to undefined but supported attributes (-ENODATA). Also, fail for attribute names like "system.sockprotonameXXX" and simplify the code a bit. Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> [removes a build warning on 4.4.y - gregkh] Signed-off-by:
-
Viresh Kumar authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit 625c85a6 upstream. The cpufreq_global_kobject is created using kobject_create_and_add() helper, which assigns the kobj_type as dynamic_kobj_ktype and show/store routines are set to kobj_attr_show() and kobj_attr_store(). These routines pass struct kobj_attribute as an argument to the show/store callbacks. But all the cpufreq files created using the cpufreq_global_kobject expect the argument to be of type struct attribute. Things work fine currently as no one accesses the "attr" argument. We may not see issues even if the argument is used, as struct kobj_attribute has struct attribute as its first element and so they will both get same address. But this is logically incorrect and we should rather use struct kobj_attribute instead of struct global_attr in the cpufreq core and drivers and the show/store callbacks should take struct kobj_attribute as argument instead. This bug is caught using CFI CLANG builds in android kernel which catches mismatch in function prototypes for such callbacks. Reported-by:
Donghee Han <dh.han@samsung.com> Reported-by:
Sangkyu Kim <skwith.kim@samsung.com> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Mans Rullgard authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit 8d7fa3d4 upstream. This adds the USB ID of the Hjelmslund Electronics USB485 Iso stick. Signed-off-by:
Mans Rullgard <mans@mansr.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Ivan Mironov authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit dd9d3d86 upstream. Here is how this device appears in kernel log: usb 3-1: new full-speed USB device number 18 using xhci_hcd usb 3-1: New USB device found, idVendor=0b00, idProduct=3070 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1: Product: Ingenico 3070 usb 3-1: Manufacturer: Silicon Labs usb 3-1: SerialNumber: 0001 Apparently this is a POS terminal with embedded USB-to-Serial converter. Cc: stable@vger.kernel.org Signed-off-by:
Ivan Mironov <mironov.ivan@gmail.com> Signed-off-by:
-
Daniele Palmas authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit 6431866b upstream. This patch adds Telit ME910 family ECM composition 0x1102. Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Andy Lutomirski authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit 2a418cf3 upstream. When calling __put_user(foo(), ptr), the __put_user() macro would call foo() in between __uaccess_begin() and __uaccess_end(). If that code were buggy, then those bugs would be run without SMAP protection. Fortunately, there seem to be few instances of the problem in the kernel. Nevertheless, __put_user() should be fixed to avoid doing this. Therefore, evaluate __put_user()'s argument before setting AC. This issue was noticed when an objtool hack by Peter Zijlstra complained about genregs_get() and I compared the assembly output to the C source. [ bp: Massage commit message and fixed up whitespace. ] Fixes: 11f1a4b9 ("x86: reorganize SMAP handling in user space accesses") Signed-off-by:
Andy Lutomirski <luto@kernel.org> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Brian Gerst <brgerst@gmail.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20190225125231.845656645@infradead.orgSigned-off-by:
-
Jonathan Neuschäfer authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit c9bd505d upstream. When using the mmc_spi driver with a card-detect pin, I noticed that the card was not detected immediately after probe, but only after it was unplugged and plugged back in (and the CD IRQ fired). The call tree looks something like this: mmc_spi_probe mmc_add_host mmc_start_host _mmc_detect_change mmc_schedule_delayed_work(&host->detect, 0) mmc_rescan host->bus_ops->detect(host) mmc_detect _mmc_detect_card_removed host->ops->get_cd(host) mmc_gpio_get_cd -> -ENOSYS (ctx->cd_gpio not set) mmc_gpiod_request_cd ctx->cd_gpio = desc To fix this issue, call mmc_detect_change after the card-detect GPIO/IRQ is registered. Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Cc: stable@vger.kernel.org Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Seth Forshee authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit 186b8f15 upstream. Several callers to epapr_hypercall() pass an uninitialized stack allocated array for the input arguments, presumably because they have no input arguments. However this can produce errors like this one arch/powerpc/include/asm/epapr_hcalls.h:470:42: error: 'in' may be used uninitialized in this function [-Werror=maybe-uninitialized] unsigned long register r3 asm("r3") = in[0]; ~~^~~ Fix callers to this function to always zero-initialize the input arguments array to prevent this. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Cc: "A. Wilcox" <awilfox@adelielinux.org> Signed-off-by:
-
Christoffer Dall authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit 83091db9 upstream. When the kernel was handling a guest MMIO read access internally, we need to copy the emulation result into the run->mmio structure in order for the kvm_handle_mmio_return() function to pick it up and inject the result back into the guest. Currently the only user of kvm_io_bus for ARM is the VGIC, which did this copying itself, so this was not causing issues so far. But with the upcoming new vgic implementation we need this done properly. Update the kvm_handle_mmio_return description and cleanup the code to only perform a single copying when needed. Code and commit message inspired by Andre Przywara. Reported-by:
Andre Przywara <andre.przywara@arm.com> Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Reviewed-by:
-
Marc Zyngier authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit 1d6a8212 upstream. On an MMIO access, we always copy the on-stack buffer info the shared "run" structure, even if this is a read access. This ends up leaking up to 8 bytes of uninitialized memory into userspace, depending on the size of the access. An obvious fix for this one is to only perform the copy if this is an actual write. Reviewed-by:
-
Vitaly Kuznetsov authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 619ad846 ] kvm-unit-tests' eventinj "NMI failing on IDT" test results in NMI being delivered to the host (L1) when it's running nested. The problem seems to be: svm_complete_interrupts() raises 'nmi_injected' flag but later we decide to reflect EXIT_NPF to L1. The flag remains pending and we do NMI injection upon entry so it got delivered to L1 instead of L2. It seems that VMX code solves the same issue in prepare_vmcs12(), this was introduced with code refactoring in commit 5f3d5799 ("KVM: nVMX: Rework event injection and recovery"). Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Chaitanya Tata authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 93183bdb ] Recently, DMG frequency bands have been extended till 71GHz, so extend the range check till 20GHz (45-71GHZ), else some channels will be marked as disabled. Signed-off-by:
Chaitanya Tata <Chaitanya.Tata@bluwireless.co.uk> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Balaji Pothunoori authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 7ed52853 ] Following call trace is observed while adding TDLS peer entry in driver during TDLS setup. Call Trace: [<c1301476>] dump_stack+0x47/0x61 [<c10537d2>] __warn+0xe2/0x100 [<fa22415f>] ? sta_apply_parameters+0x49f/0x550 [mac80211] [<c1053895>] warn_slowpath_null+0x25/0x30 [<fa22415f>] sta_apply_parameters+0x49f/0x550 [mac80211] [<fa20ad42>] ? sta_info_alloc+0x1c2/0x450 [mac80211] [<fa224623>] ieee80211_add_station+0xe3/0x160 [mac80211] [<c1876fe3>] nl80211_new_station+0x273/0x420 [<c170f6d9>] genl_rcv_msg+0x219/0x3c0 [<c170f4c0>] ? genl_rcv+0x30/0x30 [<c170ee7e>] netlink_rcv_skb+0x8e/0xb0 [<c170f4ac>] genl_rcv+0x1c/0x30 [<c170e8aa>] netlink_unicast+0x13a/0x1d0 [<c170ec18>] netlink_sendmsg+0x2d8/0x390 [<c16c5acd>] sock_sendmsg+0x2d/0x40 [<c16c6369>] ___sys_sendmsg+0x1d9/0x1e0 Fixing this by allowing TDLS setup request only when we have completed association. Signed-off-by:
Balaji Pothunoori <bpothuno@codeaurora.org> Signed-off-by:
-
Thomas Falcon authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit e95d22c6 ] The IBM virtual ethernet driver's polling function continues to process frames after rescheduling NAPI, resulting in a warning if it exhausted its budget. Do not restart polling after calling napi_reschedule. Instead let frames be processed in the following instance. Signed-off-by:
Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by:
-
Atsushi Nemoto authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 17b42a20 ] The connect_local_phy should return NULL (not negative errno) on error, since its caller expects it. Signed-off-by:
Atsushi Nemoto <atsushi.nemoto@sord.co.jp> Acked-by:
Thor Thayer <thor.thayer@linux.intel.com> Signed-off-by:
-
Varun Prakash authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit fe35a40e ] Assign fc_vport to ln->fc_vport before calling csio_fcoe_alloc_vnp() to avoid a NULL pointer dereference in csio_vport_set_state(). ln->fc_vport is dereferenced in csio_vport_set_state(). Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Tomonori Sakita authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 815d835b ] Using over-sampling ratio, lpuart can accept baud rate upto uartclk / 4. Signed-off-by:
Tomonori Sakita <tomonori.sakita@sord.co.jp> Signed-off-by:
-
Bob Copeland authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit a0dc0203 ] In ieee80211_rx_h_mesh_fwding, we increment the 'dropped_frames_ttl' counter when we decrement the ttl to zero. For unicast frames destined for other hosts, we stop processing the frame at that point. For multicast frames, we do not rebroadcast it in this case, but we do pass the frame up the stack to process it on this STA. That doesn't match the usual definition of "dropped," so don't count those as such. With this change, something like `ping6 -i0.2 ff02::1%mesh0` from a peer in a ttl=1 network no longer increments the counter rapidly. Signed-off-by:
Bob Copeland <bobcopeland@fb.com> Signed-off-by:
-
Eugeniy Paltsev authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 4e868f84 ] | CC mm/nobootmem.o |In file included from ./include/asm-generic/bug.h:18:0, | from ./arch/arc/include/asm/bug.h:32, | from ./include/linux/bug.h:5, | from ./include/linux/mmdebug.h:5, | from ./include/linux/gfp.h:5, | from ./include/linux/slab.h:15, | from mm/nobootmem.c:14: |mm/nobootmem.c: In function '__free_pages_memory': |./include/linux/kernel.h:845:29: warning: comparison of distinct pointer types lacks a cast | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^ |./include/linux/kernel.h:859:4: note: in expansion of macro '__typecheck' | (__typecheck(x, y) && __no_side_effects(x, y)) | ^~~~~~~~~~~ |./include/linux/kernel.h:869:24: note: in expansion of macro '__safe_cmp' | __builtin_choose_expr(__safe_cmp(x, y), \ | ^~~~~~~~~~ |./include/linux/kernel.h:878:19: note: in expansion of macro '__careful_cmp' | #define min(x, y) __careful_cmp(x, y, <) | ^~~~~~~~~~~~~ |mm/nobootmem.c:104:11: note: in expansion of macro 'min' | order = min(MAX_ORDER - 1UL, __ffs(start)); Change __ffs return value from 'int' to 'unsigned long' as it is done in other implementations (like asm-generic, x86, etc...) to avoid build-time warnings in places where type is strictly checked. As __ffs may return values in [0-31] interval changing return type to unsigned is valid. Signed-off-by:
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Silvio Cesare authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit c407cd00 ] Change snprintf to scnprintf. There are generally two cases where using snprintf causes problems. 1) Uses of size += snprintf(buf, SIZE - size, fmt, ...) In this case, if snprintf would have written more characters than what the buffer size (SIZE) is, then size will end up larger than SIZE. In later uses of snprintf, SIZE - size will result in a negative number, leading to problems. Note that size might already be too large by using size = snprintf before the code reaches a case of size += snprintf. 2) If size is ultimately used as a length parameter for a copy back to user space, then it will potentially allow for a buffer overflow and information disclosure when size is greater than SIZE. When the size is used to index the buffer directly, we can have memory corruption. This also means when size = snprintf... is used, it may also cause problems since size may become large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel configuration. The solution to these issues is to use scnprintf which returns the number of characters actually written to the buffer, so the size variable will never exceed SIZE. Signed-off-by:
Silvio Cesare <silvio.cesare@gmail.com> Cc: Timur Tabi <timur@kernel.org> Cc: Nicolin Chen <nicoleotsuka@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Xiubo Li <Xiubo.Lee@gmail.com> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Kees Cook <keescook@chromium.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
Willy Tarreau <w@1wt.eu> Acked-by:
Nicolin Chen <nicoleotsuka@gmail.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Silvio Cesare authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit e581e151 ] Change snprintf to scnprintf. There are generally two cases where using snprintf causes problems. 1) Uses of size += snprintf(buf, SIZE - size, fmt, ...) In this case, if snprintf would have written more characters than what the buffer size (SIZE) is, then size will end up larger than SIZE. In later uses of snprintf, SIZE - size will result in a negative number, leading to problems. Note that size might already be too large by using size = snprintf before the code reaches a case of size += snprintf. 2) If size is ultimately used as a length parameter for a copy back to user space, then it will potentially allow for a buffer overflow and information disclosure when size is greater than SIZE. When the size is used to index the buffer directly, we can have memory corruption. This also means when size = snprintf... is used, it may also cause problems since size may become large. Copying to userspace is mitigated by the HARDENED_USERCOPY kernel configuration. The solution to these issues is to use scnprintf which returns the number of characters actually written to the buffer, so the size variable will never exceed SIZE. Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit df28169e ] The source_sink_alloc_func() function is supposed to return error pointers on error. The function is called from usb_get_function() which doesn't check for NULL returns so it would result in an Oops. Of course, in the current kernel, small allocations always succeed so this doesn't affect runtime. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Zeng Tao authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 88b1bb1f ] Currently the link_state is uninitialized and the default value is 0(U0) before the first time we start the udc, and after we start the udc then stop the udc, the link_state will be undefined. We may have the following warnings if we start the udc again with an undefined link_state: WARNING: CPU: 0 PID: 327 at drivers/usb/dwc3/gadget.c:294 dwc3_send_gadget_ep_cmd+0x304/0x308 dwc3 100e0000.hidwc3_0: wakeup failed --> -22 [...] Call Trace: [<c010f270>] (unwind_backtrace) from [<c010b3d8>] (show_stack+0x10/0x14) [<c010b3d8>] (show_stack) from [<c034a4dc>] (dump_stack+0x84/0x98) [<c034a4dc>] (dump_stack) from [<c0118000>] (__warn+0xe8/0x100) [<c0118000>] (__warn) from [<c0118050>](warn_slowpath_fmt+0x38/0x48) [<c0118050>] (warn_slowpath_fmt) from [<c0442ec0>](dwc3_send_gadget_ep_cmd+0x304/0x308) [<c0442ec0>] (dwc3_send_gadget_ep_cmd) from [<c0445e68>](dwc3_ep0_start_trans+0x48/0xf4) [<c0445e68>] (dwc3_ep0_start_trans) from [<c0446750>](dwc3_ep0_out_start+0x64/0x80) [<c0446750>] (dwc3_ep0_out_start) from [<c04451c0>](__dwc3_gadget_start+0x1e0/0x278) [<c04451c0>] (__dwc3_gadget_start) from [<c04452e0>](dwc3_gadget_start+0x88/0x10c) [<c04452e0>] (dwc3_gadget_start) from [<c045ee54>](udc_bind_to_driver+0x88/0xbc) [<c045ee54>] (udc_bind_to_driver) from [<c045f29c>](usb_gadget_probe_driver+0xf8/0x140) [<c045f29c>] (usb_gadget_probe_driver) from [<bf005424>](gadget_dev_desc_UDC_store+0xac/0xc4 [libcomposite]) [<bf005424>] (gadget_dev_desc_UDC_store [libcomposite]) from[<c023d8e0>] (configfs_write_file+0xd4/0x160) [<c023d8e0>] (configfs_write_file) from [<c01d51e8>] (__vfs_write+0x1c/0x114) [<c01d51e8>] (__vfs_write) from [<c01d5ff4>] (vfs_write+0xa4/0x168) [<c01d5ff4>] (vfs_write) from [<c01d6d40>] (SyS_write+0x3c/0x90) [<c01d6d40>] (SyS_write) from [<c0107400>] (ret_fast_syscall+0x0/0x3c) Signed-off-by:
Zeng Tao <prime.zeng@hisilicon.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 3fe931b3 ] The intel_soc_dts_iosf_init() function doesn't return NULL, it returns error pointers. Fixes: 4d0dd6c1 ("Thermal/int340x/processor_thermal: Enable auxiliary DTS for Braswell") Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 678e2b44 ] The problem is seen in the q6asm_dai_compr_set_params() function: ret = q6asm_map_memory_regions(dir, prtd->audio_client, prtd->phys, (prtd->pcm_size / prtd->periods), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ prtd->periods); In this code prtd->pcm_size is the buffer_size and prtd->periods comes from params->buffer.fragments. If we allow the number of fragments to be zero then it results in a divide by zero bug. One possible fix would be to use prtd->pcm_count directly instead of using the division to re-calculate it. But I decided that it doesn't really make sense to allow zero fragments. Signed-off-by:
-
Rander Wang authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 906a9abc ] For some reason this field was set to zero when all other drivers use .dynamic = 1 for front-ends. This change was tested on Dell XPS13 and has no impact with the existing legacy driver. The SOF driver also works with this change which enables it to override the fixed topology. Signed-off-by:
Rander Wang <rander.wang@linux.intel.com> Acked-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
-
Kristian H. Kristensen authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 99c66bc0 ] Prevents deadlock when fifo is full and reader closes file. Signed-off-by:
Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Ilya Dryomov authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit 0fd3fd0a upstream. The authorize reply can be empty, for example when the ticket used to build the authorizer is too old and TAG_BADAUTHORIZER is returned from the service. Calling ->verify_authorizer_reply() results in an attempt to decrypt and validate (somewhat) random data in au->buf (most likely the signature block from calc_signature()), which fails and ends up in con_fault_finish() with !con->auth_retry. The ticket isn't invalidated and the connection is retried again and again until a new ticket is obtained from the monitor: libceph: osd2 192.168.122.1:6809 bad authorize reply libceph: osd2 192.168.122.1:6809 bad authorize reply libceph: osd2 192.168.122.1:6809 bad authorize reply libceph: osd2 192.168.122.1:6809 bad authorize reply Let TAG_BADAUTHORIZER handler kick in and increment con->auth_retry. Cc: stable@vger.kernel.org Fixes: 5c056fdc ("libceph: verify authorize reply on connect") Link: https://tracker.ceph.com/issues/20164Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Reviewed-by:
Sage Weil <sage@redhat.com> [idryomov@gmail.com: backport to 4.4: extra arg, no CEPHX_V2] Signed-off-by:
-
Hangbin Liu authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit 278e2148 upstream. This reverts commit 5a2de63f ("bridge: do not add port to router list when receives query with source 0.0.0.0") and commit 0fe5119e ("net: bridge: remove ipv6 zero address check in mcast queries") The reason is RFC 4541 is not a standard but suggestive. Currently we will elect 0.0.0.0 as Querier if there is no ip address configured on bridge. If we do not add the port which recives query with source 0.0.0.0 to router list, the IGMP reports will not be about to forward to Querier, IGMP data will also not be able to forward to dest. As Nikolay suggested, revert this change first and add a boolopt api to disable none-zero election in future if needed. Reported-by:
Linus Lüssing <linus.luessing@c0d3.blue> Reported-by:
Sebastian Gottschall <s.gottschall@newmedia-net.de> Fixes: 5a2de63f ("bridge: do not add port to router list when receives query with source 0.0.0.0") Fixes: 0fe5119e ("net: bridge: remove ipv6 zero address check in mcast queries") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Acked-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Eugeniy Paltsev authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit 252f6e8e upstream. It is currently done in arc_init_IRQ() which might be too late considering gcc 7.3.1 onwards (GNU 2018.03) generates unaligned memory accesses by default Cc: stable@vger.kernel.org #4.4+ Signed-off-by:
-
Saeed Mahameed authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 29dded89 ] When an ethernet frame is padded to meet the minimum ethernet frame size, the padding octets are not covered by the hardware checksum. Fortunately the padding octets are usually zero's, which don't affect checksum. However, it is not guaranteed. For example, switches might choose to make other use of these octets. This repeatedly causes kernel hardware checksum fault. Prior to the cited commit below, skb checksum was forced to be CHECKSUM_NONE when padding is detected. After it, we need to keep skb->csum updated. However, fixing up CHECKSUM_COMPLETE requires to verify and parse IP headers, it does not worth the effort as the packets are so small that CHECKSUM_COMPLETE has no significant advantage. Future work: when reporting checksum complete is not an option for IP non-TCP/UDP packets, we can actually fallback to report checksum unnecessary, by looking at cqe IPOK bit. Fixes: 88078d98 ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends") Cc: Eric Dumazet <edumazet@google.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Hangbin Liu authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 173656ac ] If we disabled IPv6 from the kernel command line (ipv6.disable=1), we should not call ip6_err_gen_icmpv6_unreach(). This: ip link add sit1 type sit local 192.0.2.1 remote 192.0.2.2 ttl 1 ip link set sit1 up ip addr add 198.51.100.1/24 dev sit1 ping 198.51.100.2 if IPv6 is disabled at boot time, will crash the kernel. v2: there's no need to use in6_dev_get(), use __in6_dev_get() instead, as we only need to check that idev exists and we are under rcu_read_lock() (from netif_receive_skb_internal()). Reported-by:
Jianlin Shi <jishi@redhat.com> Fixes: ca15a078 ("sit: generate icmpv6 error when receiving icmpv4 error") Cc: Oussama Ghorbel <ghorbel@pivasoftware.com> Signed-off-by:
Stefano Brivio <sbrivio@redhat.com> Signed-off-by:
-
Cong Wang authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 2fdeee25 ] The current opt_inst_list operations inside team_nl_cmd_options_set() is too complex to track: LIST_HEAD(opt_inst_list); nla_for_each_nested(...) { list_for_each_entry(opt_inst, &team->option_inst_list, list) { if (__team_option_inst_tmp_find(&opt_inst_list, opt_inst)) continue; list_add(&opt_inst->tmp_list, &opt_inst_list); } } team_nl_send_event_options_get(team, &opt_inst_list); as while we retrieve 'opt_inst' from team->option_inst_list, it could be added to the local 'opt_inst_list' for multiple times. The __team_option_inst_tmp_find() doesn't work, as the setter team_mode_option_set() still calls team->ops.exit() which uses ->tmp_list too in __team_options_change_check(). Simplify the list operations by moving the 'opt_inst_list' and team_nl_send_event_options_get() into the nla_for_each_nested() loop so that it can be guranteed that we won't insert a same list entry for multiple times. Therefore, __team_option_inst_tmp_find() can be removed too. Fixes: 4fb0534f ("team: avoid adding twice the same option to the event list") Fixes: 2fcdb2c9 ("team: allow to send multiple set events in one message") Reported-by: syzbot+4d4af685432dc0e56c91@syzkaller.appspotmail.com Reported-by: syzbot+68ee510075cf64260cc4@syzkaller.appspotmail.com Cc: Jiri Pirko <jiri@resnulli.us> Cc: Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Reviewed-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Kal Conley authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit fc62814d ] When calculating rb->frames_per_block * req->tp_block_nr the result can overflow. Check it for overflow without limiting the total buffer size to UINT_MAX. This change fixes support for packet ring buffers >= UINT_MAX. Fixes: 8f8d28e4 ("net/packet: fix overflow in check for tp_frame_nr") Signed-off-by:
Kal Conley <kal.conley@dectris.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1822271 [ Upstream commit 4ffcbfac ] KMSAN reported batadv_interface_tx() was possibly using a garbage value [1] batadv_get_vid() does have a pskb_may_pull() call but batadv_interface_tx() does not actually make sure this did not fail. [1] BUG: KMSAN: uninit-value in batadv_interface_tx+0x908/0x1e40 net/batman-adv/soft-interface.c:231 CPU: 0 PID: 10006 Comm: syz-executor469 Not tainted 4.20.0-rc7+ #5 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+0x173/0x1d0 lib/dump_stack.c:113 kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613 __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313 batadv_interface_tx+0x908/0x1e40 net/batman-adv/soft-interface.c:231 __netdev_start_xmit include/linux/netdevice.h:4356 [inline] netdev_start_xmit include/linux/netdevice.h:4365 [inline] xmit_one net/core/dev.c:3257 [inline] dev_hard_start_xmit+0x607/0xc40 net/core/dev.c:3273 __dev_queue_xmit+0x2e42/0x3bc0 net/core/dev.c:3843 dev_queue_xmit+0x4b/0x60 net/core/dev.c:3876 packet_snd net/packet/af_packet.c:2928 [inline] packet_sendmsg+0x8306/0x8f30 net/packet/af_packet.c:2953 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg net/socket.c:631 [inline] __sys_sendto+0x8c4/0xac0 net/socket.c:1788 __do_sys_sendto net/socket.c:1800 [inline] __se_sys_sendto+0x107/0x130 net/socket.c:1796 __x64_sys_sendto+0x6e/0x90 net/socket.c:1796 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 RIP: 0033:0x441889 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 bb 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffdda6fd468 EFLAGS: 00000216 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 0000000000441889 RDX: 000000000000000e RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000216 R12: 00007ffdda6fd4c0 R13: 00007ffdda6fd4b0 R14: 0000000000000000 R15: 0000000000000000 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline] kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:158 kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176 kmsan_slab_alloc+0xe/0x10 mm/kmsan/kmsan_hooks.c:185 slab_post_alloc_hook mm/slab.h:446 [inline] slab_alloc_node mm/slub.c:2759 [inline] __kmalloc_node_track_caller+0xe18/0x1030 mm/slub.c:4383 __kmalloc_reserve net/core/skbuff.c:137 [inline] __alloc_skb+0x309/0xa20 net/core/skbuff.c:205 alloc_skb include/linux/skbuff.h:998 [inline] alloc_skb_with_frags+0x1c7/0xac0 net/core/skbuff.c:5220 sock_alloc_send_pskb+0xafd/0x10e0 net/core/sock.c:2083 packet_alloc_skb net/packet/af_packet.c:2781 [inline] packet_snd net/packet/af_packet.c:2872 [inline] packet_sendmsg+0x661a/0x8f30 net/packet/af_packet.c:2953 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg net/socket.c:631 [inline] __sys_sendto+0x8c4/0xac0 net/socket.c:1788 __do_sys_sendto net/socket.c:1800 [inline] __se_sys_sendto+0x107/0x130 net/socket.c:1796 __x64_sys_sendto+0x6e/0x90 net/socket.c:1796 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 Fixes: c6c8fea2 ("net: Add batman-adv meshing protocol") Signed-off-by:
syzbot <syzkaller@googlegroups.com> Cc: Marek Lindner <mareklindner@neomailbox.ch> Cc: Simon Wunderlich <sw@simonwunderlich.de> Cc: Antonio Quartulli <a@unstable.cc> Signed-off-by:
-
Eric Biggers authored
BugLink: https://bugs.launchpad.net/bugs/1822271 commit ede0fa98 upstream. syzbot hit the 'BUG_ON(index_key->desc_len == 0);' in __key_link_begin() called from construct_alloc_key() during sys_request_key(), because the length of the key description was never calculated. The problem is that we rely on ->desc_len being initialized by search_process_keyrings(), specifically by search_nested_keyrings(). But, if the process isn't subscribed to any keyrings that never happens. Fix it by always initializing keyring_index_key::desc_len as soon as the description is set, like we already do in some places. The following program reproduces the BUG_ON() when it's run as root and no session keyring has been installed. If it doesn't work, try removing pam_keyinit.so from /etc/pam.d/login and rebooting. #include <stdlib.h> #include <unistd.h> #include <keyutils.h> int main(void) { int id = add_key("keyring", "syz", NULL, 0, KEY_SPEC_USER_KEYRING); keyctl_setperm(id, KEY_OTH_WRITE); setreuid(5000, 5000); request_key("user", "desc", "", id); } Reported-by: syzbot+ec24e95ea483de0a24da@syzkaller.appspotmail.com Fixes: b2a4df20 ("KEYS: Expand the capacity of a keyring") Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
James Morris <james.morris@microsoft.com> Signed-off-by:
-
