summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-01-19Merge tag 'asoc-v4.16-3' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next ASoC: Updates for v4.16 Some final updates for the merge window, this brings in some improvements to the ACPI GPIO handling for Intel and a bunch of fixes.
2018-01-19xfrm: fix error flow in case of add state failsAviad Yehezkel
If add state fails in case of device offload, netdev refcount will be negative since gc task is attempting to dev_free this state. This is fixed by putting NULL in state dev field. Signed-off-by: Aviad Yehezkel <aviadye@mellanox.com> Signed-off-by: Boris Pismeny <borisp@mellanox.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2018-01-19KVM: PPC: Book3S: Provide information about hardware/firmware CVE workaroundsPaul Mackerras
This adds a new ioctl, KVM_PPC_GET_CPU_CHAR, that gives userspace information about the underlying machine's level of vulnerability to the recently announced vulnerabilities CVE-2017-5715, CVE-2017-5753 and CVE-2017-5754, and whether the machine provides instructions to assist software to work around the vulnerabilities. The ioctl returns two u64 words describing characteristics of the CPU and required software behaviour respectively, plus two mask words which indicate which bits have been filled in by the kernel, for extensibility. The bit definitions are the same as for the new H_GET_CPU_CHARACTERISTICS hypercall. There is also a new capability, KVM_CAP_PPC_GET_CPU_CHAR, which indicates whether the new ioctl is available. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2018-01-19Merge tag 'drm-intel-fixes-2018-01-18' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Display corruption regression bugfix with both a prep patch and a follow-up fix * tag 'drm-intel-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-intel: drm/i915: Fix deadlock in i830_disable_pipe() drm/i915: Redo plane sanitation during readout drm/i915: Add .get_hw_state() method for planes
2018-01-18ibmvnic: Fix IPv6 packet descriptorsThomas Falcon
Packet descriptor generation for IPv6 is broken. Properly set L3 and L4 protocol flags for IPv6 descriptors. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18ibmvnic: Fix IP offload control bufferThomas Falcon
Set some missing fields in the IP control offload buffer. This buffer is used to enable checksum and TCP segmentation offload in the VNIC server. The buffer length field and the checksum offloading bits were not set properly, so fix that here. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18Merge tag 'linux-can-fixes-for-4.15-20180118' of ↵David S. Miller
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2018-01-18 ==================== this is a pull reqeust of two patches for net/master: The syzkaller project triggered two WARN_ONCE() in the af_can code from userspace and we decided to replace it by a pr_warn_once(). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18ipv6: don't let tb6_root node share routes with other nodeWei Wang
After commit 4512c43eac7e, if we add a route to the subtree of tb6_root which does not have any route attached to it yet, the current code will let tb6_root and the node in the subtree share the same route. This could cause problem cause tb6_root has RTN_INFO flag marked and the tree repair and clean up code will not work properly. This commit makes sure tb6_root->leaf points back to null_entry instead of sharing route with other node. It fixes the following syzkaller reported issue: BUG: KASAN: use-after-free in ipv6_prefix_equal include/net/ipv6.h:540 [inline] BUG: KASAN: use-after-free in fib6_add_1+0x165f/0x1790 net/ipv6/ip6_fib.c:618 Read of size 8 at addr ffff8801bc043498 by task syz-executor5/19819 CPU: 1 PID: 19819 Comm: syz-executor5 Not tainted 4.15.0-rc7+ #186 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 print_address_description+0x73/0x250 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x25b/0x340 mm/kasan/report.c:409 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430 ipv6_prefix_equal include/net/ipv6.h:540 [inline] fib6_add_1+0x165f/0x1790 net/ipv6/ip6_fib.c:618 fib6_add+0x5fa/0x1540 net/ipv6/ip6_fib.c:1214 __ip6_ins_rt+0x6c/0x90 net/ipv6/route.c:1003 ip6_route_add+0x141/0x190 net/ipv6/route.c:2790 ipv6_route_ioctl+0x4db/0x6b0 net/ipv6/route.c:3299 inet6_ioctl+0xef/0x1e0 net/ipv6/af_inet6.c:520 sock_do_ioctl+0x65/0xb0 net/socket.c:958 sock_ioctl+0x2c2/0x440 net/socket.c:1055 vfs_ioctl fs/ioctl.c:46 [inline] do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686 SYSC_ioctl fs/ioctl.c:701 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692 entry_SYSCALL_64_fastpath+0x23/0x9a RIP: 0033:0x452ac9 RSP: 002b:00007fd42b321c58 EFLAGS: 00000212 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000452ac9 RDX: 0000000020fd7000 RSI: 000000000000890b RDI: 0000000000000013 RBP: 000000000000049e R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f4f70 R13: 00000000ffffffff R14: 00007fd42b3226d4 R15: 0000000000000000 Fixes: 4512c43eac7e ("ipv6: remove null_entry before adding default route") Signed-off-by: Wei Wang <weiwan@google.com> Acked-by: Eric Dumazet <edumazet@google.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-19Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixesDave Airlie
Thought I'd try my luck getting one more in: - Two fixes for Tegra (one is to common code, but our userspace doesn't hit it). - One for NV5x-class MCPs * 'linux-4.15' of git://github.com/skeggsb/linux: drm/nouveau/mmu/mcp77: fix regressions in stolen memory handling drm/nouveau/bar/gk20a: Avoid bar teardown during init drm/nouveau/drm/nouveau: Pass the proper arguments to nvif_object_map_handle()
2018-01-18ip6_gre: init dev->mtu and dev->hard_header_len correctlyAlexey Kodanev
Commit b05229f44228 ("gre6: Cleanup GREv6 transmit path, call common GRE functions") moved dev->mtu initialization from ip6gre_tunnel_setup() to ip6gre_tunnel_init(), as a result, the previously set values, before ndo_init(), are reset in the following cases: * rtnl_create_link() can update dev->mtu from IFLA_MTU parameter. * ip6gre_tnl_link_config() is invoked before ndo_init() in netlink and ioctl setup, so ndo_init() can reset MTU adjustments with the lower device MTU as well, dev->mtu and dev->hard_header_len. Not applicable for ip6gretap because it has one more call to ip6gre_tnl_link_config(tunnel, 1) in ip6gre_tap_init(). Fix the first case by updating dev->mtu with 'tb[IFLA_MTU]' parameter if a user sets it manually on a device creation, and fix the second one by moving ip6gre_tnl_link_config() call after register_netdevice(). Fixes: b05229f44228 ("gre6: Cleanup GREv6 transmit path, call common GRE functions") Fixes: db2ec95d1ba4 ("ip6_gre: Fix MTU setting") Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18mlxsw: spectrum_router: Free LPM tree upon failureIdo Schimmel
When a new LPM tree is created, we try to replace the trees in the existing virtual routers with it. If we fail, the tree needs to be freed. Currently, this does not happen in the unlikely case where we fail to bind the tree to the first virtual router, since its reference count never transitions from 1 to 0. Fix that by taking a reference before binding the tree. Fixes: fc922bb0dd94 ("mlxsw: spectrum_router: Use one LPM tree for all virtual routers") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-19drm/nouveau/mmu/mcp77: fix regressions in stolen memory handlingBen Skeggs
- Fixes addition of stolen memory base address to PTEs. - Removes support for compression. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Tested-by: Pierre Moreau <pierre.morrow@free.fr>
2018-01-19drm/nouveau/bar/gk20a: Avoid bar teardown during initJon Hunter
Commit bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown") introduced add a teardown helper function for BAR1. During initialisation of the Nouveau, initially all the teardown helpers are called once, before calling their init counterparts. For gk20a, after the BAR1 teardown function is called, the device is hanging during the initialisation of the FB sub-device. At this point it is unclear why this is happening and this is still under investigation. However, this change is preventing Tegra124 devices from booting when Nouveau is enabled. To allow Tegra124 to boot, remove the teardown helper for gk20a. This is based upon a previous patch by Guillaume Tucker but limits the workaround to only gk20a GPUs. Fixes: bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown") Reported-by: Guillaume Tucker <guillaume.tucker@collabora.com> Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-01-19drm/nouveau/drm/nouveau: Pass the proper arguments to nvif_object_map_handle()Thierry Reding
This is obviously wrong in the current code. Make sure to record the correct size of the arguments and pass the actual arguments to the nvif_object_map_handle() function. Suggested-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-01-18flow_dissector: properly cap thoff fieldEric Dumazet
syzbot reported yet another crash [1] that is caused by insufficient validation of DODGY packets. Two bugs are happening here to trigger the crash. 1) Flow dissection leaves with incorrect thoff field. 2) skb_probe_transport_header() sets transport header to this invalid thoff, even if pointing after skb valid data. 3) qdisc_pkt_len_init() reads out-of-bound data because it trusts tcp_hdrlen(skb) Possible fixes : - Full flow dissector validation before injecting bad DODGY packets in the stack. This approach was attempted here : https://patchwork.ozlabs.org/patch/ 861874/ - Have more robust functions in the core. This might be needed anyway for stable versions. This patch fixes the flow dissection issue. [1] CPU: 1 PID: 3144 Comm: syzkaller271204 Not tainted 4.15.0-rc4-mm1+ #49 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 print_address_description+0x73/0x250 mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:355 [inline] kasan_report+0x23b/0x360 mm/kasan/report.c:413 __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:432 __tcp_hdrlen include/linux/tcp.h:35 [inline] tcp_hdrlen include/linux/tcp.h:40 [inline] qdisc_pkt_len_init net/core/dev.c:3160 [inline] __dev_queue_xmit+0x20d3/0x2200 net/core/dev.c:3465 dev_queue_xmit+0x17/0x20 net/core/dev.c:3554 packet_snd net/packet/af_packet.c:2943 [inline] packet_sendmsg+0x3ad5/0x60a0 net/packet/af_packet.c:2968 sock_sendmsg_nosec net/socket.c:628 [inline] sock_sendmsg+0xca/0x110 net/socket.c:638 sock_write_iter+0x31a/0x5d0 net/socket.c:907 call_write_iter include/linux/fs.h:1776 [inline] new_sync_write fs/read_write.c:469 [inline] __vfs_write+0x684/0x970 fs/read_write.c:482 vfs_write+0x189/0x510 fs/read_write.c:544 SYSC_write fs/read_write.c:589 [inline] SyS_write+0xef/0x220 fs/read_write.c:581 entry_SYSCALL_64_fastpath+0x1f/0x96 Fixes: 34fad54c2537 ("net: __skb_flow_dissect() must cap its return value") Fixes: a6e544b0a88b ("flow_dissector: Jump to exit code in __skb_flow_dissect") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18Merge tag 'wireless-drivers-for-davem-2018-01-17' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for 4.15 One last set of fixes for regression submitted during the last few days. bcma & ssb * fix older build problems which (apparently) recently became more frequent in certain MIPS configurations brcmfmac * continue driver initialisation even if CLM blob (firmware) file is not found ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18tracing: Fix converting enum's from the map in trace_event_eval_update()Steven Rostedt (VMware)
Since enums do not get converted by the TRACE_EVENT macro into their values, the event format displaces the enum name and not the value. This breaks tools like perf and trace-cmd that need to interpret the raw binary data. To solve this, an enum map was created to convert these enums into their actual numbers on boot up. This is done by TRACE_EVENTS() adding a TRACE_DEFINE_ENUM() macro. Some enums were not being converted. This was caused by an optization that had a bug in it. All calls get checked against this enum map to see if it should be converted or not, and it compares the call's system to the system that the enum map was created under. If they match, then they call is processed. To cut down on the number of iterations needed to find the maps with a matching system, since calls and maps are grouped by system, when a match is made, the index into the map array is saved, so that the next call, if it belongs to the same system as the previous call, could start right at that array index and not have to scan all the previous arrays. The problem was, the saved index was used as the variable to know if this is a call in a new system or not. If the index was zero, it was assumed that the call is in a new system and would keep incrementing the saved index until it found a matching system. The issue arises when the first matching system was at index zero. The next map, if it belonged to the same system, would then think it was the first match and increment the index to one. If the next call belong to the same system, it would begin its search of the maps off by one, and miss the first enum that should be converted. This left a single enum not converted properly. Also add a comment to describe exactly what that index was for. It took me a bit too long to figure out what I was thinking when debugging this issue. Link: http://lkml.kernel.org/r/717BE572-2070-4C1E-9902-9F2E0FEDA4F8@oracle.com Cc: stable@vger.kernel.org Fixes: 0c564a538aa93 ("tracing: Add TRACE_DEFINE_ENUM() macro to map enums to their values") Reported-by: Chuck Lever <chuck.lever@oracle.com> Teste-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2018-01-18fm10k: mark PM functions as __maybe_unusedArnd Bergmann
A cleanup of the PM code left an incorrect #ifdef in place, leading to a harmless build warning: drivers/net/ethernet/intel/fm10k/fm10k_pci.c:2502:12: error: 'fm10k_suspend' defined but not used [-Werror=unused-function] drivers/net/ethernet/intel/fm10k/fm10k_pci.c:2475:12: error: 'fm10k_resume' defined but not used [-Werror=unused-function] It's easier to use __maybe_unused attributes here, since you can't pick the wrong one. Fixes: 8249c47c6ba4 ("fm10k: use generic PM hooks instead of legacy PCIe power hooks") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18ring-buffer: Fix duplicate results in mapping context to bits in recursive lockSteven Rostedt (VMware)
In bringing back the context checks, the code checks first if its normal (non-interrupt) context, and then for NMI then IRQ then softirq. The final check is redundant. Since the if branch is only hit if the context is one of NMI, IRQ, or SOFTIRQ, if it's not NMI or IRQ there's no reason to check if it is SOFTIRQ. The current code returns the same result even if its not a SOFTIRQ. Which is confusing. pc & SOFTIRQ_OFFSET ? 2 : RB_CTX_SOFTIRQ Is redundant as RB_CTX_SOFTIRQ *is* 2! Fixes: a0e3a18f4baf ("ring-buffer: Bring back context level recursive checks") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2018-01-18MAINTAINERS: Add James as MIPS co-maintainerJames Hogan
I've been taking on some co-maintainer duties already, so lets make it official in the MAINTAINERS file. Link: https://lkml.kernel.org/r/33db77a2-32e4-6b2c-d463-9d116ba55623@imgtec.com Link: https://lkml.kernel.org/r/20171207110549.GM27409@jhogan-linux.mipstec.com Signed-off-by: James Hogan <jhogan@kernel.org> Acked-by: Paul Burton <paul.burton@mips.com> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: David Daney <david.daney@cavium.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Matt Redfearn <matt.redfearn@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: John Crispin <john@phrozen.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/18211/
2018-01-18MIPS: Fix undefined reference to physical_memsizeJames Hogan
Since commit d41e6858ba58 ("MIPS: Kconfig: Set default MIPS system type as generic") switched the default platform to the "generic" platform, allmodconfig has been failing with the following linker error (among other errors): arch/mips/kernel/vpe-mt.o In function `vpe_run': (.text+0x59c): undefined reference to `physical_memsize' The Lantiq platform already worked around the same issue in commit 9050d50e2244 ("MIPS: lantiq: Set physical_memsize") by declaring physical_memsize with the initial value of 0 (on the assumption that the actual memory size will be hard-coded in the loaded VPE firmware), and the Malta platform already provided physical_memsize. Since all other platforms will fail to link with the VPE loader enabled, only allow Lantiq and Malta platforms to enable it, by way of a SYS_SUPPORTS_VPE_LOADER which is selected by those two platforms and which MIPS_VPE_LOADER depends on. SYS_SUPPORTS_MULTITHREADING is now a dependency of SYS_SUPPORTS_VPE_LOADER so that Kconfig emits a warning if SYS_SUPPORTS_VPE_LOADER is selected without SYS_SUPPORTS_MULTITHREADING. Fixes: d41e6858ba58 ("MIPS: Kconfig: Set default MIPS system type as generic") Signed-off-by: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: John Crispin <john@phrozen.org> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Paul Burton <paul.burton@mips.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-mips@linux-mips.org Tested-by: Guenter Roeck <linux@roeck-us.net> Patchwork: https://patchwork.linux-mips.org/patch/18453/
2018-01-18cfg80211: fix station info handling bugsJohannes Berg
Fix two places where the structure isn't initialized to zero, and thus can't be filled properly by the driver. Fixes: 4a4b8169501b ("cfg80211: Accept multiple RSSI thresholds for CQM") Fixes: 9930380f0bd8 ("cfg80211: implement IWRATE") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()Boris Brezillon
When saving BOs in the hang state we skip one entry of the kernel_state->bo[] array, thus leaving it to NULL. This leads to a NULL pointer dereference when, later in this function, we iterate over all BOs to check their ->madv state. Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs") Cc: <stable@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180118145821.22344-1-boris.brezillon@free-electrons.com
2018-01-18drm/vc4: Flush the caches before the bin jobs, as well.Eric Anholt
If the frame samples from a render target that was just written, its cache flush during the binning step may have occurred before the previous frame's RCL was completed. Flush the texture caches again before starting each RCL job to make sure that the sampling of the previous RCL's output is correct. Fixes flickering in the top left of 3DMMES Taiji. Signed-off-by: Eric Anholt <eric@anholt.net> Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs") Link: https://patchwork.freedesktop.org/patch/msgid/20171221221722.23809-1-eric@anholt.net Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2018-01-18netlink: reset extack earlier in netlink_rcv_skbXin Long
Move up the extack reset/initialization in netlink_rcv_skb, so that those 'goto ack' will not skip it. Otherwise, later on netlink_ack may use the uninitialized extack and cause kernel crash. Fixes: cbbdf8433a5f ("netlink: extack needs to be reset each time through loop") Reported-by: syzbot+03bee3680a37466775e7@syzkaller.appspotmail.com Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18Input: synaptics-rmi4 - prevent UAF reported by KASANNick Desaulniers
KASAN found a UAF due to dangling pointer. As the report below says, rmi_f11_attention() accesses drvdata->attn_data.data, which was freed in rmi_irq_fn. [ 311.424062] BUG: KASAN: use-after-free in rmi_f11_attention+0x526/0x5e0 [rmi_core] [ 311.424067] Read of size 27 at addr ffff88041fd610db by task irq/131-i2c_hid/1162 [ 311.424075] CPU: 0 PID: 1162 Comm: irq/131-i2c_hid Not tainted 4.15.0-rc8+ #2 [ 311.424076] Hardware name: Razer Blade Stealth/Razer, BIOS 6.05 01/26/2017 [ 311.424078] Call Trace: [ 311.424086] dump_stack+0xae/0x12d [ 311.424090] ? _atomic_dec_and_lock+0x103/0x103 [ 311.424094] ? show_regs_print_info+0xa/0xa [ 311.424099] ? input_handle_event+0x10b/0x810 [ 311.424104] print_address_description+0x65/0x229 [ 311.424108] kasan_report.cold.5+0xa7/0x281 [ 311.424117] rmi_f11_attention+0x526/0x5e0 [rmi_core] [ 311.424123] ? memcpy+0x1f/0x50 [ 311.424132] ? rmi_f11_attention+0x526/0x5e0 [rmi_core] [ 311.424143] ? rmi_f11_probe+0x1e20/0x1e20 [rmi_core] [ 311.424153] ? rmi_process_interrupt_requests+0x220/0x2a0 [rmi_core] [ 311.424163] ? rmi_irq_fn+0x22c/0x270 [rmi_core] [ 311.424173] ? rmi_process_interrupt_requests+0x2a0/0x2a0 [rmi_core] [ 311.424177] ? free_irq+0xa0/0xa0 [ 311.424180] ? irq_finalize_oneshot.part.39+0xeb/0x180 [ 311.424190] ? rmi_process_interrupt_requests+0x2a0/0x2a0 [rmi_core] [ 311.424193] ? irq_thread_fn+0x3d/0x80 [ 311.424197] ? irq_finalize_oneshot.part.39+0x180/0x180 [ 311.424200] ? irq_thread+0x21d/0x290 [ 311.424203] ? irq_thread_check_affinity+0x170/0x170 [ 311.424207] ? remove_wait_queue+0x150/0x150 [ 311.424212] ? kasan_unpoison_shadow+0x30/0x40 [ 311.424214] ? __init_waitqueue_head+0xa0/0xd0 [ 311.424218] ? task_non_contending.cold.55+0x18/0x18 [ 311.424221] ? irq_forced_thread_fn+0xa0/0xa0 [ 311.424226] ? irq_thread_check_affinity+0x170/0x170 [ 311.424230] ? kthread+0x19e/0x1c0 [ 311.424233] ? kthread_create_worker_on_cpu+0xc0/0xc0 [ 311.424237] ? ret_from_fork+0x32/0x40 [ 311.424244] Allocated by task 899: [ 311.424249] kasan_kmalloc+0xbf/0xe0 [ 311.424252] __kmalloc_track_caller+0xd9/0x1f0 [ 311.424255] kmemdup+0x17/0x40 [ 311.424264] rmi_set_attn_data+0xa4/0x1b0 [rmi_core] [ 311.424269] rmi_raw_event+0x10b/0x1f0 [hid_rmi] [ 311.424278] hid_input_report+0x1a8/0x2c0 [hid] [ 311.424283] i2c_hid_irq+0x146/0x1d0 [i2c_hid] [ 311.424286] irq_thread_fn+0x3d/0x80 [ 311.424288] irq_thread+0x21d/0x290 [ 311.424291] kthread+0x19e/0x1c0 [ 311.424293] ret_from_fork+0x32/0x40 [ 311.424296] Freed by task 1162: [ 311.424300] kasan_slab_free+0x71/0xc0 [ 311.424303] kfree+0x90/0x190 [ 311.424311] rmi_irq_fn+0x1b2/0x270 [rmi_core] [ 311.424319] rmi_irq_fn+0x257/0x270 [rmi_core] [ 311.424322] irq_thread_fn+0x3d/0x80 [ 311.424324] irq_thread+0x21d/0x290 [ 311.424327] kthread+0x19e/0x1c0 [ 311.424330] ret_from_fork+0x32/0x40 [ 311.424334] The buggy address belongs to the object at ffff88041fd610c0 which belongs to the cache kmalloc-64 of size 64 [ 311.424340] The buggy address is located 27 bytes inside of 64-byte region [ffff88041fd610c0, ffff88041fd61100) [ 311.424344] The buggy address belongs to the page: [ 311.424348] page:ffffea00107f5840 count:1 mapcount:0 mapping: (null) index:0x0 [ 311.424353] flags: 0x17ffffc0000100(slab) [ 311.424358] raw: 0017ffffc0000100 0000000000000000 0000000000000000 00000001802a002a [ 311.424363] raw: dead000000000100 dead000000000200 ffff8804228036c0 0000000000000000 [ 311.424366] page dumped because: kasan: bad access detected [ 311.424369] Memory state around the buggy address: [ 311.424373] ffff88041fd60f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 311.424377] ffff88041fd61000: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb [ 311.424381] >ffff88041fd61080: fb fb fb fb fc fc fc fc fb fb fb fb fb fb fb fb [ 311.424384] ^ [ 311.424387] ffff88041fd61100: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc [ 311.424391] ffff88041fd61180: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb Cc: stable@vger.kernel.org Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2018-01-18Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds
Pull ARM fixes from Russell King: "These are the ARM BPF fixes as discussed earlier this week" * 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: net: bpf: clarify tail_call index ARM: net: bpf: fix LDX instructions ARM: net: bpf: fix register saving ARM: net: bpf: correct stack layout documentation ARM: net: bpf: move stack documentation ARM: net: bpf: fix stack alignment ARM: net: bpf: fix tail call jumps ARM: net: bpf: avoid 'bx' instruction on non-Thumb capable CPUs
2018-01-18Merge branch 'for-linus' of git://git.kernel.dk/linux-blockLinus Torvalds
Pull two NVMe fixes from Jens Axboe: "Two important fixes for the sgl support for nvme that is new in this release" * 'for-linus' of git://git.kernel.dk/linux-block: nvme-pci: take sglist coalescing in dma_map_sg into account nvme-pci: check segement valid for SGL use
2018-01-18Merge tag 'mmc-v4.15-rc2-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fix from Ulf Hansson: "sdhci-esdhc-imx: Fixup clock to make i.MX53 Loco (IMX53QSB) boot again" * tag 'mmc-v4.15-rc2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci-esdhc-imx: Fix i.MX53 eSDHCv3 clock
2018-01-18Merge tag 'gpio-v4.15-5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fix from Linus Walleij: "This is the (hopefully) last GPIO fix for v4.15, fixing the bit fiddling in the MMIO GPIO driver. Again the especially endowed screwer-upper who has been open coding bit fiddling is yours truly" * tag 'gpio-v4.15-5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: mmio: Also read bits that are zero
2018-01-18Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller
Daniel Borkmann says: ==================== pull-request: bpf 2018-01-18 The following pull-request contains BPF updates for your *net* tree. The main changes are: 1) Fix a divide by zero due to wrong if (src_reg == 0) check in 64-bit mode. Properly handle this in interpreter and mask it also generically in verifier to guard against similar checks in JITs, from Eric and Alexei. 2) Fix a bug in arm64 JIT when tail calls are involved and progs have different stack sizes, from Daniel. 3) Reject stores into BPF context that are not expected BPF_STX | BPF_MEM variant, from Daniel. 4) Mark dst reg as unknown on {s,u}bounds adjustments when the src reg has derived bounds from dead branches, from Daniel. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-18Merge remote-tracking branches 'asoc/topic/wm8400', 'asoc/topic/wm8903', ↵Mark Brown
'asoc/topic/wm8994', 'asoc/topic/wm8997' and 'asoc/topic/wm8998' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/wm0010', 'asoc/topic/wm2000', ↵Mark Brown
'asoc/topic/wm5102', 'asoc/topic/wm5110' and 'asoc/topic/wm8350' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/twl6040', 'asoc/topic/uda1380', ↵Mark Brown
'asoc/topic/uniphier', 'asoc/topic/utils' and 'asoc/topic/ux500' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/tlv320dac33', ↵Mark Brown
'asoc/topic/ts3a227e', 'asoc/topic/tscs42xx' and 'asoc/topic/twl4030' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/tas6424', 'asoc/topic/tfa9879', ↵Mark Brown
'asoc/topic/tlv320aic31xx', 'asoc/topic/tlv320aic32x4' and 'asoc/topic/tlv320aic3x' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/stm32', 'asoc/topic/sun4i-i2s', ↵Mark Brown
'asoc/topic/sunxi', 'asoc/topic/symmetry' and 'asoc/topic/tas5720' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/sgtl5000', 'asoc/topic/si476x', ↵Mark Brown
'asoc/topic/simple', 'asoc/topic/spdif' and 'asoc/topic/st-dfsdm' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/rl6231', 'asoc/topic/rt5514', ↵Mark Brown
'asoc/topic/rt5645' and 'asoc/topic/samsung' into asoc-next
2018-01-18Merge remote-tracking branch 'asoc/topic/nuc900' into asoc-nextMark Brown
2018-01-18Merge remote-tracking branches 'asoc/topic/mxs', 'asoc/topic/mxs-sgtl5000', ↵Mark Brown
'asoc/topic/nau8540', 'asoc/topic/nau8824' and 'asoc/topic/nau8825' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/max98927', 'asoc/topic/mc13783', ↵Mark Brown
'asoc/topic/msm8916', 'asoc/topic/mt8173' and 'asoc/topic/mtk' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/hisilicon', 'asoc/topic/iio', ↵Mark Brown
'asoc/topic/max98373' and 'asoc/topic/max98926' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/fsl', 'asoc/topic/fsl-ssi', ↵Mark Brown
'asoc/topic/fsl_asrc' and 'asoc/topic/hdac_hdmi' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/davinci', 'asoc/topic/debugfs', ↵Mark Brown
'asoc/topic/disconnect', 'asoc/topic/ep93xx' and 'asoc/topic/eukrea-tlv320' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/cs47l24', 'asoc/topic/cx20442', ↵Mark Brown
'asoc/topic/da7213', 'asoc/topic/da7218' and 'asoc/topic/dai-drv' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/cs35l32', 'asoc/topic/cs35l34', ↵Mark Brown
'asoc/topic/cs42l52', 'asoc/topic/cs42l56' and 'asoc/topic/cs42l73' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/codecs', 'asoc/topic/compress' ↵Mark Brown
and 'asoc/topic/cq93vc' into asoc-next
2018-01-18Merge remote-tracking branches 'asoc/topic/88pm860x', 'asoc/topic/amd', ↵Mark Brown
'asoc/topic/atmel', 'asoc/topic/au1x' and 'asoc/topic/bcm2835' into asoc-next
2018-01-18Merge remote-tracking branch 'asoc/topic/rockchip' into asoc-nextMark Brown