1. 01 Dec, 2018 17 commits
    • Scott Wood's avatar
      KVM: PPC: Move and undef TRACE_INCLUDE_PATH/FILE · 8bb923f5
      Scott Wood authored
      [ Upstream commit 28c5bcf74fa07c25d5bd118d1271920f51ce2a98 ]
      <trace/define_trace.h>, so like that #include, they should
      be outside #ifdef protection.
      They also need to be #undefed before defining, in case multiple trace
      headers are included by the same C file.  This became the case on
      book3e after commit cf4a6085151a ("powerpc/mm: Add missing tracepoint for
      tlbie"), leading to the following build error:
         CC      arch/powerpc/kvm/powerpc.o
      In file included from arch/powerpc/kvm/powerpc.c:51:0:
      arch/powerpc/kvm/trace.h:9:0: error: "TRACE_INCLUDE_PATH" redefined
        #define TRACE_INCLUDE_PATH .
      In file included from arch/powerpc/kvm/../mm/mmu_decl.h:25:0,
                        from arch/powerpc/kvm/powerpc.c:48:
      ./arch/powerpc/include/asm/trace.h:224:0: note: this is the location of
      the previous definition
        #define TRACE_INCLUDE_PATH asm
      cc1: all warnings being treated as errors
      Reported-by: default avatarChristian Zigotzky <chzigotzky@xenosoft.de>
      Signed-off-by: default avatarScott Wood <oss@buserror.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Mathias Nyman's avatar
      usb: xhci: Prevent bus suspend if a port connect change or polling state is detected · cf0f464f
      Mathias Nyman authored
      commit 2f31a67f01a8beb22cae754c53522cb61a005750 upstream.
      USB3 roothub might autosuspend before a plugged USB3 device is detected,
      causing USB3 device enumeration failure.
      USB3 devices don't show up as connected and enabled until USB3 link trainig
      completes. On a fast booting platform with a slow USB3 link training the
      link might reach the connected enabled state just as the bus is suspending.
      If this device is discovered first time by the xhci_bus_suspend() routine
      it will be put to U3 suspended state like the other ports which failed to
      suspend earlier.
      The hub thread will notice the connect change and resume the bus,
      moving the port back to U0
      This U0 -> U3 -> U0 transition right after being connected seems to be
      too much for some devices, causing them to first go to SS.Inactive state,
      and finally end up stuck in a polling state with reset asserted
      Fix this by failing the bus suspend if a port has a connect change or is
      in a polling state in xhci_bus_suspend().
      Don't do any port changes until all ports are checked, buffer all port
      changes and only write them in the end if suspend can proceed
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Marc Kleine-Budde's avatar
      can: dev: __can_get_echo_skb(): print error message, if trying to echo non existing skb · 3583903f
      Marc Kleine-Budde authored
      commit 7da11ba5c5066dadc2e96835a6233d56d7b7764a upstream.
      Prior to echoing a successfully transmitted CAN frame (by calling
      can_get_echo_skb()), CAN drivers have to put the CAN frame (by calling
      can_put_echo_skb() in the transmit function). These put and get function
      take an index as parameter, which is used to identify the CAN frame.
      A driver calling can_get_echo_skb() with a index not pointing to a skb
      is a BUG, so add an appropriate error message.
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Marc Kleine-Budde's avatar
      can: dev: __can_get_echo_skb(): Don't crash the kernel if can_priv::echo_skb... · a48b4b9c
      Marc Kleine-Budde authored
      can: dev: __can_get_echo_skb(): Don't crash the kernel if can_priv::echo_skb is accessed out of bounds
      commit e7a6994d043a1e31d5b17706a22ce33d2a3e4cdc upstream.
      If the "struct can_priv::echo_skb" is accessed out of bounds would lead
      to a kernel crash. Better print a sensible warning message instead and
      try to recover.
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Marc Kleine-Budde's avatar
      can: dev: __can_get_echo_skb(): replace struct can_frame by canfd_frame to access frame length · 385e1c3b
      Marc Kleine-Budde authored
      commit 200f5c49f7a2cd694436bfc6cb0662b794c96736 upstream.
      This patch replaces the use of "struct can_frame::can_dlc" by "struct
      canfd_frame::len" to access the frame's length. As it is ensured that
      both structures have a compatible memory layout for this member this is
      no functional change. Futher, this compatibility is documented in a
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Marc Kleine-Budde's avatar
      can: dev: can_get_echo_skb(): factor out non sending code to __can_get_echo_skb() · 1d801638
      Marc Kleine-Budde authored
      commit a4310fa2f24687888ce80fdb0e88583561a23700 upstream.
      This patch factors out all non sending parts of can_get_echo_skb() into
      a seperate function __can_get_echo_skb(), so that it can be re-used in
      an upcoming patch.
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Y.C. Chen's avatar
      drm/ast: fixed cursor may disappear sometimes · 6c284c9f
      Y.C. Chen authored
      commit 7989b9ee8bafe5cc625381dd0c3c4586de27ca26 upstream.
      Signed-off-by: default avatarY.C. Chen <yc_chen@aspeedtech.com>
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Y.C. Chen's avatar
      drm/ast: change resolution may cause screen blurred · a841f370
      Y.C. Chen authored
      commit 1a37bd823891568f8721989aed0615835632d81a upstream.
      The value of pitches is not correct while calling mode_set.
      The issue we found so far on following system:
      - Debian8 with XFCE Desktop
      - Ubuntu with KDE Desktop
      - SUSE15 with KDE Desktop
      Signed-off-by: default avatarY.C. Chen <yc_chen@aspeedtech.com>
      Cc: <stable@vger.kernel.org>
      Tested-by: default avatarJean Delvare <jdelvare@suse.de>
      Reviewed-by: default avatarJean Delvare <jdelvare@suse.de>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric Dumazet's avatar
      llc: do not use sk_eat_skb() · 6f80fe0d
      Eric Dumazet authored
      commit 604d415e2bd642b7e02c80e719e0396b9d4a77a6 upstream.
      syzkaller triggered a use-after-free [1], caused by a combination of
      skb_get() in llc_conn_state_process() and usage of sk_eat_skb()
      sk_eat_skb() is assuming the skb about to be freed is only used by
      the current thread. TCP/DCCP stacks enforce this because current
      thread holds the socket lock.
      llc_conn_state_process() wants to make sure skb does not disappear,
      and holds a reference on the skb it manipulates. But as soon as this
      skb is added to socket receive queue, another thread can consume it.
      This means that llc must use regular skb_unlink() and kfree_skb()
      so that both producer and consumer can safely work on the same skb.
      BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
      BUG: KASAN: use-after-free in refcount_read include/linux/refcount.h:43 [inline]
      BUG: KASAN: use-after-free in skb_unref include/linux/skbuff.h:967 [inline]
      BUG: KASAN: use-after-free in kfree_skb+0xb7/0x580 net/core/skbuff.c:655
      Read of size 4 at addr ffff8801d1f6fba4 by task ksoftirqd/1/18
      CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.19.0-rc8+ #295
      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+0x1c4/0x2b6 lib/dump_stack.c:113
       print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
       check_memory_region_inline mm/kasan/kasan.c:260 [inline]
       check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
       kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
       atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
       refcount_read include/linux/refcount.h:43 [inline]
       skb_unref include/linux/skbuff.h:967 [inline]
       kfree_skb+0xb7/0x580 net/core/skbuff.c:655
       llc_sap_state_process+0x9b/0x550 net/llc/llc_sap.c:224
       llc_sap_rcv+0x156/0x1f0 net/llc/llc_sap.c:297
       llc_sap_handler+0x65e/0xf80 net/llc/llc_sap.c:438
       llc_rcv+0x79e/0xe20 net/llc/llc_input.c:208
       __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
       __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
       process_backlog+0x218/0x6f0 net/core/dev.c:5829
       napi_poll net/core/dev.c:6249 [inline]
       net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
       __do_softirq+0x30c/0xb03 kernel/softirq.c:292
       run_ksoftirqd+0x94/0x100 kernel/softirq.c:653
       smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164
       kthread+0x35a/0x420 kernel/kthread.c:246
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
      Allocated by task 18:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:448
       set_track mm/kasan/kasan.c:460 [inline]
       kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
       kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
       kmem_cache_alloc_node+0x144/0x730 mm/slab.c:3644
       __alloc_skb+0x119/0x770 net/core/skbuff.c:193
       alloc_skb include/linux/skbuff.h:995 [inline]
       llc_alloc_frame+0xbc/0x370 net/llc/llc_sap.c:54
       llc_station_ac_send_xid_r net/llc/llc_station.c:52 [inline]
       llc_station_rcv+0x1dc/0x1420 net/llc/llc_station.c:111
       llc_rcv+0xc32/0xe20 net/llc/llc_input.c:220
       __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
       __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
       process_backlog+0x218/0x6f0 net/core/dev.c:5829
       napi_poll net/core/dev.c:6249 [inline]
       net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
       __do_softirq+0x30c/0xb03 kernel/softirq.c:292
      Freed by task 16383:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:448
       set_track mm/kasan/kasan.c:460 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
       kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
       __cache_free mm/slab.c:3498 [inline]
       kmem_cache_free+0x83/0x290 mm/slab.c:3756
       kfree_skbmem+0x154/0x230 net/core/skbuff.c:582
       __kfree_skb+0x1d/0x20 net/core/skbuff.c:642
       sk_eat_skb include/net/sock.h:2366 [inline]
       llc_ui_recvmsg+0xec2/0x1610 net/llc/af_llc.c:882
       sock_recvmsg_nosec net/socket.c:794 [inline]
       sock_recvmsg+0xd0/0x110 net/socket.c:801
       ___sys_recvmsg+0x2b6/0x680 net/socket.c:2278
       __sys_recvmmsg+0x303/0xb90 net/socket.c:2390
       do_sys_recvmmsg+0x181/0x1a0 net/socket.c:2466
       __do_sys_recvmmsg net/socket.c:2484 [inline]
       __se_sys_recvmmsg net/socket.c:2480 [inline]
       __x64_sys_recvmmsg+0xbe/0x150 net/socket.c:2480
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
      The buggy address belongs to the object at ffff8801d1f6fac0
       which belongs to the cache skbuff_head_cache of size 232
      The buggy address is located 228 bytes inside of
       232-byte region [ffff8801d1f6fac0, ffff8801d1f6fba8)
      The buggy address belongs to the page:
      page:ffffea000747dbc0 count:1 mapcount:0 mapping:ffff8801d9be7680 index:0xffff8801d1f6fe80
      flags: 0x2fffc0000000100(slab)
      raw: 02fffc0000000100 ffffea0007346e88 ffffea000705b108 ffff8801d9be7680
      raw: ffff8801d1f6fe80 ffff8801d1f6f0c0 000000010000000b 0000000000000000
      page dumped because: kasan: bad access detected
      Memory state around the buggy address:
       ffff8801d1f6fa80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
       ffff8801d1f6fb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff8801d1f6fb80: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
       ffff8801d1f6fc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8801d1f6fc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Andrew Price's avatar
      gfs2: Don't leave s_fs_info pointing to freed memory in init_sbd · b689a81a
      Andrew Price authored
      commit 4c62bd9cea7bcf10292f7e4c57a2bca332942697 upstream.
      When alloc_percpu() fails, sdp gets freed but sb->s_fs_info still points
      to the same address. Move the assignment after that error check so that
      s_fs_info can only point to a valid sdp or NULL, which is checked for
      later in the error path, in gfs2_kill_super().
      Reported-by: syzbot+dcb8b3587445007f5808@syzkaller.appspotmail.com
      Signed-off-by: default avatarAndrew Price <anprice@redhat.com>
      Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Xin Long's avatar
      sctp: clear the transport of some out_chunk_list chunks in sctp_assoc_rm_peer · 8b97e045
      Xin Long authored
      commit df132eff463873e14e019a07f387b4d577d6d1f9 upstream.
      If a transport is removed by asconf but there still are some chunks with
      this transport queuing on out_chunk_list, later an use-after-free issue
      will be caused when accessing this transport from these chunks in
      This is an old bug, we fix it by clearing the transport of these chunks
      in out_chunk_list when removing a transport in sctp_assoc_rm_peer().
      Reported-by: syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Tetsuo Handa's avatar
      bfs: add sanity check at bfs_fill_super() · 9891fda6
      Tetsuo Handa authored
      commit 9f2df09a33aa2c76ce6385d382693f98d7f2f07e upstream.
      syzbot is reporting too large memory allocation at bfs_fill_super() [1].
      Since file system image is corrupted such that bfs_sb->s_start == 0,
      bfs_fill_super() is trying to allocate 8MB of continuous memory. Fix
      this by adding a sanity check on bfs_sb->s_start, __GFP_NOWARN and
      [1] https://syzkaller.appspot.com/bug?id=16a87c236b951351374a84c8a32f40edbc034e96
      Link: http://lkml.kernel.org/r/1525862104-3407-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jpSigned-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reported-by: default avatarsyzbot <syzbot+71c6b5d68e91149fc8a4@syzkaller.appspotmail.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Tigran Aivazian <aivazian.tigran@gmail.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dominique Martinet's avatar
      v9fs_dir_readdir: fix double-free on p9stat_read error · ebd55db3
      Dominique Martinet authored
      commit 81c99089bce693b94b775b6eb888115d2d540086 upstream.
      p9stat_read will call p9stat_free on error, we should only free the
      struct content on success.
      There also is no need to "p9stat_init" st as the read function will
      zero the whole struct for us anyway, so clean up the code a bit while
      we are here.
      Link: http://lkml.kernel.org/r/1535410108-20650-1-git-send-email-asmadeus@codewreck.orgSigned-off-by: default avatarDominique Martinet <dominique.martinet@cea.fr>
      Reported-by: syzbot+d4252148d198410b864f@syzkaller.appspotmail.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Emmanuel Grumbach's avatar
      iwlwifi: mvm: support sta_statistics() even on older firmware · 79faf409
      Emmanuel Grumbach authored
      commit ec484d03ef0df8d34086b95710e355a259cbe1f2 upstream.
      The oldest firmware supported by iwlmvm do support getting
      the average beacon RSSI. Enable the sta_statistics() call
      from mac80211 even on older firmware versions.
      Fixes: 33cef925 ("iwlwifi: mvm: support beacon statistics for BSS client")
      Cc: stable@vger.kernel.org # 4.2+
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Greg Kroah-Hartman's avatar
      MAINTAINERS: Add Sasha as a stable branch maintainer · 9fefd225
      Greg Kroah-Hartman authored
      commit cb5d21946d2a2f4687c482ab4604af1d29dac35a upstream.
      Sasha has somehow been convinced into helping me with the stable kernel
      maintenance.  Codify this slip in good judgement before he realizes what
      he really signed up for :)
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Aaron Ma's avatar
      usb: xhci: fix timeout for transition from RExit to U0 · cb4cb3ea
      Aaron Ma authored
      commit a5baeaeabcca3244782a9b6382ebab6f8a58f583 upstream.
      This definition is used by msecs_to_jiffies in milliseconds.
      According to the comments, max rexit timeout should be 20ms.
      Align with the comments to properly calculate the delay.
      Verified on Sunrise Point-LP and Cannon Lake.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAaron Ma <aaron.ma@canonical.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dennis Wassenberg's avatar
      usb: core: Fix hub port connection events lost · de06a314
      Dennis Wassenberg authored
      commit 22454b79e6de05fa61a2a72d00d2eed798abbb75 upstream.
      This will clear the USB_PORT_FEAT_C_CONNECTION bit in case of a hub port reset
      only if a device is was attached to the hub port before resetting the hub port.
      Using a Lenovo T480s attached to the ultra dock it was not possible to detect
      some usb-c devices at the dock usb-c ports because the hub_port_reset code
      will clear the USB_PORT_FEAT_C_CONNECTION bit after the actual hub port reset.
      Using this device combo the USB_PORT_FEAT_C_CONNECTION bit was set between the
      actual hub port reset and the clear of the USB_PORT_FEAT_C_CONNECTION bit.
      This ends up with clearing the USB_PORT_FEAT_C_CONNECTION bit after the
      new device was attached such that it was not detected.
      This patch will not clear the USB_PORT_FEAT_C_CONNECTION bit if there is
      currently no device attached to the port before the hub port reset.
      This will avoid clearing the connection bit for new attached devices.
      Signed-off-by: default avatarDennis Wassenberg <dennis.wassenberg@secunet.com>
      Acked-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 27 Nov, 2018 23 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.165 · 2757e11b
      Greg Kroah-Hartman authored
    • Mathias Nyman's avatar
      xhci: Fix USB3 NULL pointer dereference at logical disconnect. · d57a6bb2
      Mathias Nyman authored
      commit 2278446e2b7cd33ad894b32e7eb63afc7db6c86e upstream.
      Hub driver will try to disable a USB3 device twice at logical disconnect,
      racing with xhci_free_dev() callback from the first port disable.
      This can be triggered with "udisksctl power-off --block-device <disk>"
      or by writing "1" to the "remove" sysfs file for a USB3 device
      in 4.17-rc4.
      USB3 devices don't have a similar disabled link state as USB2 devices,
      and use a U3 suspended link state instead. In this state the port
      is still enabled and connected.
      hub_port_connect() first disconnects the device, then later it notices
      that device is still enabled (due to U3 states) it will try to disable
      the port again (set to U3).
      The xhci_free_dev() called during device disable is async, so checking
      for existing xhci->devs[i] when setting link state to U3 the second time
      was successful, even if device was being freed.
      The regression was caused by, and whole thing revealed by,
      Commit 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
      which sets xhci->devs[i]->udev to NULL before xhci_virt_dev() returned.
      and causes a NULL pointer dereference the second time we try to set U3.
      Fix this by checking xhci->devs[i]->udev exists before setting link state.
      The original patch went to stable so this fix needs to be applied there as
      Fixes: 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarJordan Glover <Golden_Miller83@protonmail.ch>
      Tested-by: default avatarJordan Glover <Golden_Miller83@protonmail.ch>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric Biggers's avatar
      HID: uhid: forbid UHID_CREATE under KERNEL_DS or elevated privileges · 645cb396
      Eric Biggers authored
      commit 8c01db7619f07c85c5cd81ec5eb83608b56c88f5 upstream.
      When a UHID_CREATE command is written to the uhid char device, a
      copy_from_user() is done from a user pointer embedded in the command.
      When the address limit is KERNEL_DS, e.g. as is the case during
      sys_sendfile(), this can read from kernel memory.  Alternatively,
      information can be leaked from a setuid binary that is tricked to write
      to the file descriptor.  Therefore, forbid UHID_CREATE in these cases.
      No other commands in uhid_char_write() are affected by this bug and
      UHID_CREATE is marked as "obsolete", so apply the restriction to
      UHID_CREATE only rather than to uhid_char_write() entirely.
      Thanks to Dmitry Vyukov for adding uhid definitions to syzkaller and to
      Jann Horn for commit 9da3f2b740544 ("x86/fault: BUG() when uaccess
      helpers fault on kernel addresses"), allowing this bug to be found.
      Reported-by: syzbot+72473edc9bf4eb1c6556@syzkaller.appspotmail.com
      Fixes: d365c6cf ("HID: uhid: add UHID_CREATE and UHID_DESTROY events")
      Cc: <stable@vger.kernel.org> # v3.6+
      Cc: Jann Horn <jannh@google.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Al Viro's avatar
      new helper: uaccess_kernel() · 342bd595
      Al Viro authored
      commit db68ce10 upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      [only take the include/linux/uaccess.h portion - gregkh]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hans de Goede's avatar
      ACPI / platform: Add SMB0001 HID to forbidden_id_list · 7f0052a8
      Hans de Goede authored
      commit 2bbb5fa37475d7aa5fa62f34db1623f3da2dfdfa upstream.
      Many HP AMD based laptops contain an SMB0001 device like this:
      Device (SMBD)
          Name (_HID, "SMB0001")  // _HID: Hardware ID
          Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
              IO (Decode16,
                  0x0B20,             // Range Minimum
                  0x0B20,             // Range Maximum
                  0x20,               // Alignment
                  0x20,               // Length
              IRQ (Level, ActiveLow, Shared, )
      The legacy style IRQ resource here causes acpi_dev_get_irqresource() to
      be called with legacy=true and this message to show in dmesg:
      ACPI: IRQ 7 override to edge, high
      This causes issues when later on the AMD0030 GPIO device gets enumerated:
      Device (GPIO)
          Name (_HID, "AMDI0030")  // _HID: Hardware ID
          Name (_CID, "AMDI0030")  // _CID: Compatible ID
          Name (_UID, Zero)  // _UID: Unique ID
          Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
      	Name (RBUF, ResourceTemplate ()
      	    Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
      	    Memory32Fixed (ReadWrite,
      		0xFED81500,         // Address Base
      		0x00000400,         // Address Length
      	Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */
      Now acpi_dev_get_irqresource() gets called with legacy=false, but because
      of the earlier override of the trigger-type acpi_register_gsi() returns
      -EBUSY (because we try to register the same interrupt with a different
      trigger-type) and we end up setting IORESOURCE_DISABLED in the flags.
      The setting of IORESOURCE_DISABLED causes platform_get_irq() to call
      acpi_irq_get() which is not implemented on x86 and returns -EINVAL.
      resulting in the following in dmesg:
      amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22
      amd_gpio: probe of AMDI0030:00 failed with error -22
      The SMB0001 is a "virtual" device in the sense that the only way the OS
      interacts with it is through calling a couple of methods to do SMBus
      transfers. As such it is weird that it has IO and IRQ resources at all,
      because the driver for it is not expected to ever access the hardware
      The Linux driver for the SMB0001 device directly binds to the acpi_device
      through the acpi_bus, so we do not need to instantiate a platform_device
      for this ACPI device. This commit adds the SMB0001 HID to the
      forbidden_id_list, avoiding the instantiating of a platform_device for it.
      Not instantiating a platform_device means we will no longer call
      acpi_dev_get_irqresource() for the legacy IRQ resource fixing the probe of
      the AMDI0030 device failing.
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1644013
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198715
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199523Reported-by: default avatarLukas Kahnert <openproggerfreak@gmail.com>
      Tested-by: default avatarMarc <suaefar@googlemail.com>
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Gustavo A. R. Silva's avatar
      drivers/misc/sgi-gru: fix Spectre v1 vulnerability · b61865ef
      Gustavo A. R. Silva authored
      commit fee05f455ceb5c670cbe48e2f9454ebc4a388554 upstream.
      req.gid can be indirectly controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      This issue was detected with the help of Smatch:
      vers/misc/sgi-gru/grukdump.c:200 gru_dump_chiplet_request() warn:
      potential spectre issue 'gru_base' [w]
      Fix this by sanitizing req.gid before calling macro GID_TO_GRU, which
      uses it to index gru_base.
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mattias Jacobsson's avatar
      USB: misc: appledisplay: add 20" Apple Cinema Display · 1b44cb3b
      Mattias Jacobsson authored
      commit f6501f49199097b99e4e263644d88c90d1ec1060 upstream.
      Add another Apple Cinema Display to the list of supported displays
      Signed-off-by: default avatarMattias Jacobsson <2pi@mok.nu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Nathan Chancellor's avatar
      misc: atmel-ssc: Fix section annotation on atmel_ssc_get_driver_data · 285745ac
      Nathan Chancellor authored
      commit 7c97301285b62a41d6bceded7d964085fc8cc50f upstream.
      After building the kernel with Clang, the following section mismatch
      warning appears:
      WARNING: vmlinux.o(.text+0x3bf19a6): Section mismatch in reference from
      the function ssc_probe() to the function
      The function ssc_probe() references
      the function __init atmel_ssc_get_driver_data().
      This is often because ssc_probe lacks a __init
      annotation or the annotation of atmel_ssc_get_driver_data is wrong.
      Remove __init from atmel_ssc_get_driver_data to get rid of the mismatch.
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Emmanuel Pescosta's avatar
      usb: quirks: Add delay-init quirk for Corsair K70 LUX RGB · 095ead16
      Emmanuel Pescosta authored
      commit a77112577667cbda7c6292c52d909636aef31fd9 upstream.
      Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
      Corsair K70 LUX RGB keyboards also require the DELAY_INIT quirk to
      start correctly at boot.
      Dmesg output:
      usb 1-6: string descriptor 0 read error: -110
      usb 1-6: New USB device found, idVendor=1b1c, idProduct=1b33
      usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      usb 1-6: can't set config #1, error -110
      Signed-off-by: default avatarEmmanuel Pescosta <emmanuelpescosta099@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Kai-Heng Feng's avatar
      USB: quirks: Add no-lpm quirk for Raydium touchscreens · f88d08ec
      Kai-Heng Feng authored
      commit deefd24228a172d1b27d4a9adbfd2cdacd60ae64 upstream.
      Raydium USB touchscreen fails to set config if LPM is enabled:
      [    2.030658] usb 1-8: New USB device found, idVendor=2386, idProduct=3119
      [    2.030659] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
      [    2.030660] usb 1-8: Product: Raydium Touch System
      [    2.030661] usb 1-8: Manufacturer: Raydium Corporation
      [    7.132209] usb 1-8: can't set config #1, error -110
      Same behavior can be observed on 2386:3114.
      Raydium claims the touchscreen supports LPM under Windows, so I used
      Microsoft USB Test Tools (MUTT) [1] to check its LPM status. MUTT shows
      that the LPM doesn't work under Windows, either. So let's just disable LPM
      for Raydium touchscreens.
      [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-test-toolsSigned-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Maarten Jacobs's avatar
      usb: cdc-acm: add entry for Hiro (Conexant) modem · 7b3bf88e
      Maarten Jacobs authored
      commit 63529eaa6164ef7ab4b907b25ac3648177e5e78f upstream.
      The cdc-acm kernel module currently does not support the Hiro (Conexant)
      H05228 USB modem. The patch below adds the device specific information:
      	idVendor	0x0572
      	idProduct	0x1349
      Signed-off-by: default avatarMaarten Jacobs <maarten256@outlook.com>
      Acked-by: default avatarOliver Neukum <oneukum@suse.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dan Carpenter's avatar
      uio: Fix an Oops on load · 1582f07e
      Dan Carpenter authored
      commit 432798195bbce1f8cd33d1c0284d0538835e25fb upstream.
      I was trying to solve a double free but I introduced a more serious
      NULL dereference bug.  The problem is that if there is an IRQ which
      triggers immediately, then we need "info->uio_dev" but it's not set yet.
      This patch puts the original initialization back to how it was and just
      sets info->uio_dev to NULL on the error path so it should solve both
      the Oops and the double free.
      Fixes: f019f07ecf6a ("uio: potential double frees if __uio_register_device() fails")
      Reported-by: default avatarMathias Thore <Mathias.Thore@infinera.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable <stable@vger.kernel.org>
      Tested-by: default avatarMathias Thore <Mathias.Thore@infinera.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Sakari Ailus's avatar
      media: v4l: event: Add subscription to list before calling "add" operation · 4bda4fd0
      Sakari Ailus authored
      commit 92539d3eda2c090b382699bbb896d4b54e9bdece upstream.
      Patch ad608fbcf166 changed how events were subscribed to address an issue
      elsewhere. As a side effect of that change, the "add" callback was called
      before the event subscription was added to the list of subscribed events,
      causing the first event queued by the add callback (and possibly other
      events arriving soon afterwards) to be lost.
      Fix this by adding the subscription to the list before calling the "add"
      callback, and clean up afterwards if that fails.
      Fixes: ad608fbcf166 ("media: v4l: event: Prevent freeing event subscriptions while accessed")
      Reported-by: default avatarDave Stevenson <dave.stevenson@raspberrypi.org>
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Tested-by: default avatarDave Stevenson <dave.stevenson@raspberrypi.org>
      Reviewed-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Tested-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Cc: stable@vger.kernel.org (for 4.14 and up)
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      [Sakari Ailus: Backported to v4.9 stable]
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Greg Kroah-Hartman's avatar
      Revert "Bluetooth: h5: Fix missing dependency on BT_HCIUART_SERDEV" · 549a22b8
      Greg Kroah-Hartman authored
      This reverts commit 5824d86b which is
      commit 6c3711ec64fd23a9abc8aaf59a9429569a6282df upstream.
      You Ling writes that this config option isn't even in 4.4.y yet, so it
      causes a regression.  Revert the patch because of this.
      Reported-by: default avataryouling 257 <youling257@gmail.com>
      Cc: Johan Hedberg <johan.hedberg@intel.com>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Sasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hans Verkuil's avatar
      Revert "media: videobuf2-core: don't call memop 'finish' when queueing" · 411a5050
      Hans Verkuil authored
      This reverts commit 46431d9c.
      This commit fixes a bug in upstream commit a136f59c ("vb2: Move
      buffer cache synchronisation to prepare from queue") which isn't
      present in 4.4.
      So as a result you get an UNBALANCED message in the kernel log if
      this patch is applied:
      vb2:   counters for queue ffffffc0f3687478, buffer 3: UNBALANCED!
      vb2:     buf_init: 1 buf_cleanup: 1 buf_prepare: 805 buf_finish: 805
      vb2:     buf_queue: 806 buf_done: 806
      vb2:     alloc: 0 put: 0 prepare: 806 finish: 805 mmap: 0
      vb2:     get_userptr: 0 put_userptr: 0
      vb2:     attach_dmabuf: 1 detach_dmabuf: 1 map_dmabuf: 805 unmap_dmabuf: 805
      vb2:     get_dmabuf: 0 num_users: 1609 vaddr: 0 cookie: 805
      Reverting this patch solves this regression.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Lu Fengqi's avatar
      btrfs: fix pinned underflow after transaction aborted · 37944cba
      Lu Fengqi authored
      commit fcd5e74288f7d36991b1f0fb96b8c57079645e38 upstream.
      When running generic/475, we may get the following warning in dmesg:
      [ 6902.102154] WARNING: CPU: 3 PID: 18013 at fs/btrfs/extent-tree.c:9776 btrfs_free_block_groups+0x2af/0x3b0 [btrfs]
      [ 6902.109160] CPU: 3 PID: 18013 Comm: umount Tainted: G        W  O      4.19.0-rc8+ #8
      [ 6902.110971] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
      [ 6902.112857] RIP: 0010:btrfs_free_block_groups+0x2af/0x3b0 [btrfs]
      [ 6902.118921] RSP: 0018:ffffc9000459bdb0 EFLAGS: 00010286
      [ 6902.120315] RAX: ffff880175050bb0 RBX: ffff8801124a8000 RCX: 0000000000170007
      [ 6902.121969] RDX: 0000000000000002 RSI: 0000000000170007 RDI: ffffffff8125fb74
      [ 6902.123716] RBP: ffff880175055d10 R08: 0000000000000000 R09: 0000000000000000
      [ 6902.125417] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880175055d88
      [ 6902.127129] R13: ffff880175050bb0 R14: 0000000000000000 R15: dead000000000100
      [ 6902.129060] FS:  00007f4507223780(0000) GS:ffff88017ba00000(0000) knlGS:0000000000000000
      [ 6902.130996] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 6902.132558] CR2: 00005623599cac78 CR3: 000000014b700001 CR4: 00000000003606e0
      [ 6902.134270] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 6902.135981] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 6902.137836] Call Trace:
      [ 6902.138939]  close_ctree+0x171/0x330 [btrfs]
      [ 6902.140181]  ? kthread_stop+0x146/0x1f0
      [ 6902.141277]  generic_shutdown_super+0x6c/0x100
      [ 6902.142517]  kill_anon_super+0x14/0x30
      [ 6902.143554]  btrfs_kill_super+0x13/0x100 [btrfs]
      [ 6902.144790]  deactivate_locked_super+0x2f/0x70
      [ 6902.146014]  cleanup_mnt+0x3b/0x70
      [ 6902.147020]  task_work_run+0x9e/0xd0
      [ 6902.148036]  do_syscall_64+0x470/0x600
      [ 6902.149142]  ? trace_hardirqs_off_thunk+0x1a/0x1c
      [ 6902.150375]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [ 6902.151640] RIP: 0033:0x7f45077a6a7b
      [ 6902.157324] RSP: 002b:00007ffd589f3e68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
      [ 6902.159187] RAX: 0000000000000000 RBX: 000055e8eec732b0 RCX: 00007f45077a6a7b
      [ 6902.160834] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000055e8eec73490
      [ 6902.162526] RBP: 0000000000000000 R08: 000055e8eec734b0 R09: 00007ffd589f26c0
      [ 6902.164141] R10: 0000000000000000 R11: 0000000000000246 R12: 000055e8eec73490
      [ 6902.165815] R13: 00007f4507ac61a4 R14: 0000000000000000 R15: 00007ffd589f40d8
      [ 6902.167553] irq event stamp: 0
      [ 6902.168998] hardirqs last  enabled at (0): [<0000000000000000>]           (null)
      [ 6902.170731] hardirqs last disabled at (0): [<ffffffff810cd810>] copy_process.part.55+0x3b0/0x1f00
      [ 6902.172773] softirqs last  enabled at (0): [<ffffffff810cd810>] copy_process.part.55+0x3b0/0x1f00
      [ 6902.174671] softirqs last disabled at (0): [<0000000000000000>]           (null)
      [ 6902.176407] ---[ end trace 463138c2986b275c ]---
      [ 6902.177636] BTRFS info (device dm-3): space_info 4 has 273465344 free, is not full
      [ 6902.179453] BTRFS info (device dm-3): space_info total=276824064, used=4685824, pinned=18446744073708158976, reserved=0, may_use=0, readonly=65536
      In the above line there's "pinned=18446744073708158976" which is an
      unsigned u64 value of -1392640, an obvious underflow.
      When transaction_kthread is running cleanup_transaction(), another
      fsstress is running btrfs_commit_transaction(). The
      btrfs_finish_extent_commit() may get the same range as
      btrfs_destroy_pinned_extent() got, which causes the pinned underflow.
      Fixes: d4b450cd ("Btrfs: fix race between transaction commit and empty block group removal")
      CC: stable@vger.kernel.org # 4.4+
      Reviewed-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: default avatarLu Fengqi <lufq.fnst@cn.fujitsu.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Andreas Gruenbacher's avatar
      gfs2: Put bitmap buffers in put_super · 00112fda
      Andreas Gruenbacher authored
      commit 10283ea525d30f2e99828978fd04d8427876a7ad upstream.
      gfs2_put_super calls gfs2_clear_rgrpd to destroy the gfs2_rgrpd objects
      attached to the resource group glocks.  That function should release the
      buffers attached to the gfs2_bitmap objects (bi_bh), but the call to
      gfs2_rgrp_brelse for doing that is missing.
      When gfs2_releasepage later runs across these buffers which are still
      referenced, it refuses to free them.  This causes the pages the buffers
      are attached to to remain referenced as well.  With enough mount/unmount
      cycles, the system will eventually run out of memory.
      Fix this by adding the missing call to gfs2_rgrp_brelse in
      (Also fix a gfs2_rgrp_relse -> gfs2_rgrp_brelse typo in a comment.)
      Fixes: 39b0f1e9 ("GFS2: Don't brelse rgrp buffer_heads every allocation")
      Cc: stable@vger.kernel.org # v4.4
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • YueHaibing's avatar
      SUNRPC: drop pointless static qualifier in xdr_get_next_encode_buffer() · a2b02eb4
      YueHaibing authored
      [ Upstream commit 025911a5f4e36955498ed50806ad1b02f0f76288 ]
      There is no need to have the '__be32 *p' variable static since new value
      always be assigned before use it.
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Minchan Kim's avatar
      zram: close udev startup race condition as default groups · 4036c69b
      Minchan Kim authored
      commit fef912bf860e upstream.
      commit 98af4d4df889 upstream.
      I got a report from Howard Chen that he saw zram and sysfs race(ie,
      zram block device file is created but sysfs for it isn't yet)
      when he tried to create new zram devices via hotadd knob.
      v4.20 kernel fixes it by [1, 2] but it's too large size to merge
      into -stable so this patch fixes the problem by registering defualt
      group by Greg KH's approach[3].
      This patch should be applied to every stable tree [3.16+] currently
      existing from kernel.org because the problem was introduced at 2.6.37
      by [4].
      [1] fef912bf860e, block: genhd: add 'groups' argument to device_add_disk
      [2] 98af4d4df889, zram: register default groups with device_add_disk()
      [3] http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/
      [4] 33863c21, Staging: zram: Replace ioctls with sysfs interface
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Hannes Reinecke <hare@suse.com>
      Tested-by: default avatarHoward Chen <howardsoc@google.com>
      Signed-off-by: default avatarMinchan Kim <minchan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Jeremy Linton's avatar
      lib/raid6: Fix arm64 test build · 971297d2
      Jeremy Linton authored
      [ Upstream commit 313a06e636808387822af24c507cba92703568b1 ]
      The lib/raid6/test fails to build the neon objects
      on arm64 because the correct machine type is 'aarch64'.
      Once this is correctly enabled, the neon recovery objects
      need to be added to the build.
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarJeremy Linton <jeremy.linton@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Geert Uytterhoeven's avatar
      hwmon: (ibmpowernv) Remove bogus __init annotations · e255a9e0
      Geert Uytterhoeven authored
      [ Upstream commit e3e61f01d755188cb6c2dcf5a244b9c0937c258e ]
      If gcc decides not to inline make_sensor_label():
          WARNING: vmlinux.o(.text+0x4df549c): Section mismatch in reference from the function .create_device_attrs() to the function .init.text:.make_sensor_label()
          The function .create_device_attrs() references
          the function __init .make_sensor_label().
          This is often because .create_device_attrs lacks a __init
          annotation or the annotation of .make_sensor_label is wrong.
      As .probe() can be called after freeing of __init memory, all __init
      annotiations in the driver are bogus, and should be removed.
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Taehee Yoo's avatar
      netfilter: xt_IDLETIMER: add sysfs filename checking routine · 1fc4be66
      Taehee Yoo authored
      [ Upstream commit 54451f60c8fa061af9051a53be9786393947367c ]
      When IDLETIMER rule is added, sysfs file is created under
      But some label name shouldn't be used.
      ".", "..", "power", "uevent", "subsystem", etc...
      So that sysfs filename checking routine is needed.
      test commands:
         %iptables -I INPUT -j IDLETIMER --timeout 1 --label "power"
      splat looks like:
      [95765.423132] sysfs: cannot create duplicate filename '/devices/virtual/xt_idletimer/timers/power'
      [95765.433418] CPU: 0 PID: 8446 Comm: iptables Not tainted 4.19.0-rc6+ #20
      [95765.449755] Call Trace:
      [95765.449755]  dump_stack+0xc9/0x16b
      [95765.449755]  ? show_regs_print_info+0x5/0x5
      [95765.449755]  sysfs_warn_dup+0x74/0x90
      [95765.449755]  sysfs_add_file_mode_ns+0x352/0x500
      [95765.449755]  sysfs_create_file_ns+0x179/0x270
      [95765.449755]  ? sysfs_add_file_mode_ns+0x500/0x500
      [95765.449755]  ? idletimer_tg_checkentry+0x3e5/0xb1b [xt_IDLETIMER]
      [95765.449755]  ? rcu_read_lock_sched_held+0x114/0x130
      [95765.449755]  ? __kmalloc_track_caller+0x211/0x2b0
      [95765.449755]  ? memcpy+0x34/0x50
      [95765.449755]  idletimer_tg_checkentry+0x4e2/0xb1b [xt_IDLETIMER]
      [ ... ]
      Fixes: 0902b469 ("netfilter: xtables: idletimer target implementation")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    • Jozsef Kadlecsik's avatar
      netfilter: ipset: Correct rcu_dereference() call in ip_set_put_comment() · b8ad1323
      Jozsef Kadlecsik authored
      [ Upstream commit 17b8b74c0f8dbf9b9e3301f9ca5b65dd1c079951 ]
      The function is called when rcu_read_lock() is held and not
      when rcu_read_lock_bh() is held.
      Signed-off-by: default avatarJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>