commit 7152401aeedd9685fcf1cb58138c868890d9164f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Dec 5 19:41:27 2018 +0100

    Linux 4.14.86

commit 862e7aaa90f63b1e3e3ab498dc3a3ac9a011b8d0
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Thu Sep 27 22:15:31 2018 -0700

    f2fs: fix missing up_read
    
    commit 89d13c38501df730cbb2e02c4499da1b5187119d upstream.
    
    This patch fixes missing up_read call.
    
    Fixes: c9b60788fc76 ("f2fs: fix to do sanity check with block address in main area")
    Cc: <stable@vger.kernel.org> # 4.19+
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c5f2e899241aceab46e6dcba01c6fb2223bdeb5
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Fri Jul 27 19:40:30 2018 +0200

    libceph: check authorizer reply/challenge length before reading
    
    commit 130f52f2b203aa0aec179341916ffb2e905f3afd upstream.
    
    Avoid scribbling over memory if the received reply/challenge is larger
    than the buffer supplied with the authorizer.
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14118df4e7b4738815f222f5b20fceb3957ab206
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Fri Jul 27 19:45:36 2018 +0200

    libceph: weaken sizeof check in ceph_x_verify_authorizer_reply()
    
    commit f1d10e04637924f2b00a0fecdd2ca4565f5cfc3f upstream.
    
    Allow for extending ceph_x_authorize_reply in the future.
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd6cc33d0775b0d902906d88dd05cc1a2a059f8d
Author: Todd Kjos <tkjos@android.com>
Date:   Tue Nov 6 15:55:32 2018 -0800

    binder: fix race that allows malicious free of live buffer
    
    commit 7bada55ab50697861eee6bb7d60b41e68a961a9c upstream.
    
    Malicious code can attempt to free buffers using the BC_FREE_BUFFER
    ioctl to binder. There are protections against a user freeing a buffer
    while in use by the kernel, however there was a window where
    BC_FREE_BUFFER could be used to free a recently allocated buffer that
    was not completely initialized. This resulted in a use-after-free
    detected by KASAN with a malicious test program.
    
    This window is closed by setting the buffer's allow_user_free attribute
    to 0 when the buffer is allocated or when the user has previously freed
    it instead of waiting for the caller to set it. The problem was that
    when the struct buffer was recycled, allow_user_free was stale and set
    to 1 allowing a free to go through.
    
    Signed-off-by: Todd Kjos <tkjos@google.com>
    Acked-by: Arve Hjønnevåg <arve@android.com>
    Cc: stable <stable@vger.kernel.org> # 4.14
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7d33988bd923310934c8481a2e68b53f716df13
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed Nov 14 01:57:03 2018 +0000

    misc: mic/scif: fix copy-paste error in scif_create_remote_lookup
    
    commit 6484a677294aa5d08c0210f2f387ebb9be646115 upstream.
    
    gcc '-Wunused-but-set-variable' warning:
    
    drivers/misc/mic/scif/scif_rma.c: In function 'scif_create_remote_lookup':
    drivers/misc/mic/scif/scif_rma.c:373:25: warning:
     variable 'vmalloc_num_pages' set but not used [-Wunused-but-set-variable]
    
    'vmalloc_num_pages' should be used to determine if the address is
    within the vmalloc range.
    
    Fixes: ba612aa8b487 ("misc: mic: SCIF memory registration and unregistration")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c44b197448dfb8bef4fa9cab92b7a73153a6f76
Author: Dexuan Cui <decui@microsoft.com>
Date:   Mon Nov 26 02:29:56 2018 +0000

    Drivers: hv: vmbus: check the creation_status in vmbus_establish_gpadl()
    
    commit eceb05965489784f24bbf4d61ba60e475a983016 upstream.
    
    This is a longstanding issue: if the vmbus upper-layer drivers try to
    consume too many GPADLs, the host may return with an error
    0xC0000044 (STATUS_QUOTA_EXCEEDED), but currently we forget to check
    the creation_status, and hence we can pass an invalid GPADL handle
    into the OPEN_CHANNEL message, and get an error code 0xc0000225 in
    open_info->response.open_result.status, and finally we hang in
    vmbus_open() -> "goto error_free_info" -> vmbus_teardown_gpadl().
    
    With this patch, we can exit gracefully on STATUS_QUOTA_EXCEEDED.
    
    Cc: Stephen Hemminger <sthemmin@microsoft.com>
    Cc: K. Y. Srinivasan <kys@microsoft.com>
    Cc: Haiyang Zhang <haiyangz@microsoft.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c1ba1a1bb0d1a5dcebc737343f0c45840cf181d
Author: Yu Zhao <yuzhao@google.com>
Date:   Fri Nov 30 14:09:03 2018 -0800

    mm: use swp_offset as key in shmem_replace_page()
    
    commit c1cb20d43728aa9b5393bd8d489bc85c142949b2 upstream.
    
    We changed the key of swap cache tree from swp_entry_t.val to
    swp_offset.  We need to do so in shmem_replace_page() as well.
    
    Hugh said:
     "shmem_replace_page() has been wrong since the day I wrote it: good
      enough to work on swap "type" 0, which is all most people ever use
      (especially those few who need shmem_replace_page() at all), but
      broken once there are any non-0 swp_type bits set in the higher order
      bits"
    
    Link: http://lkml.kernel.org/r/20181121215442.138545-1-yuzhao@google.com
    Fixes: f6ab1f7f6b2d ("mm, swap: use offset of swap entry as key of swap cache")
    Signed-off-by: Yu Zhao <yuzhao@google.com>
    Reviewed-by: Matthew Wilcox <willy@infradead.org>
    Acked-by: Hugh Dickins <hughd@google.com>
    Cc: <stable@vger.kernel.org>    [4.9+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 397dbde6149057b4b84acb37012b57801fbc9221
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Fri Nov 30 14:09:21 2018 -0800

    lib/test_kmod.c: fix rmmod double free
    
    commit 5618cf031fecda63847cafd1091e7b8bd626cdb1 upstream.
    
    We free the misc device string twice on rmmod; fix this.  Without this
    we cannot remove the module without crashing.
    
    Link: http://lkml.kernel.org/r/20181124050500.5257-1-mcgrof@kernel.org
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: <stable@vger.kernel.org>    [4.12+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d08c62878fe2040e2cbc70554f86c54895a9f708
Author: Martin Kelly <martin@martingkelly.com>
Date:   Sun Oct 28 20:18:53 2018 -0700

    iio:st_magn: Fix enable device after trigger
    
    commit fe5192ac81ad0d4dfe1395d11f393f0513c15f7f upstream.
    
    Currently, we enable the device before we enable the device trigger. At
    high frequencies, this can cause interrupts that don't yet have a poll
    function associated with them and are thus treated as spurious. At high
    frequencies with level interrupts, this can even cause an interrupt storm
    of repeated spurious interrupts (~100,000 on my Beagleboard with the
    LSM9DS1 magnetometer). If these repeat too much, the interrupt will get
    disabled and the device will stop functioning.
    
    To prevent these problems, enable the device prior to enabling the device
    trigger, and disable the divec prior to disabling the trigger. This means
    there's no window of time during which the device creates interrupts but we
    have no trigger to answer them.
    
    Fixes: 90efe055629 ("iio: st_sensors: harden interrupt handling")
    Signed-off-by: Martin Kelly <martin@martingkelly.com>
    Tested-by: Denis Ciocca <denis.ciocca@st.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1a4876f0435dc43fc55f42bd30763de5e5ef9ec
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
Date:   Mon Nov 19 08:34:04 2018 +0200

    Revert "usb: dwc3: gadget: skip Set/Clear Halt when invalid"
    
    commit 38317f5c0f2faae5110854f36edad810f841d62f upstream.
    
    This reverts commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3.
    
    Turns out that commit is wrong. Host controllers are allowed to use
    Clear Feature HALT as means to sync data toggle between host and
    periperal.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b7456f46ff957a3f04b3658a8d71b645d8cf172
Author: Michael Niewöhner <linux@mniewoehner.de>
Date:   Sun Nov 25 17:57:33 2018 +0100

    usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series
    
    commit effd14f66cc1ef6701a19c5a56e39c35f4d395a5 upstream.
    
    Cherry G230 Stream 2.0 (G85-231) and 3.0 (G85-232) need this quirk to
    function correctly. This fixes a but where double pressing numlock locks
    up the device completely with need to replug the keyboard.
    
    Signed-off-by: Michael Niewöhner <linux@mniewoehner.de>
    Tested-by: Michael Niewöhner <linux@mniewoehner.de>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 403a2001bd795c43f59a5dd6695273fdfe0a3dcf
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Fri Nov 23 08:42:19 2018 +0000

    USB: usb-storage: Add new IDs to ums-realtek
    
    commit a84a1bcc992f0545a51d2e120b8ca2ef20e2ea97 upstream.
    
    There are two new Realtek card readers require ums-realtek to work
    correctly.
    
    Add the new IDs to support them.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74abe400e12b45f871c98c99f0f65521cc0c8ca6
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Thu Nov 8 23:30:09 2018 -0600

    staging: rtl8723bs: Add missing return for cfg80211_rtw_get_station
    
    commit 8561fb31a1f9594e2807681f5c0721894e367f19 upstream.
    
    With Androidx86 8.1, wificond returns "failed to get
    nl80211_sta_info_tx_failed" and wificondControl returns "Invalid signal
    poll result from wificond". The fix is to OR sinfo->filled with
    BIT_ULL(NL80211_STA_INFO_TX_FAILED).
    
    This missing bit is apparently not needed with NetworkManager, but it
    does no harm in that case.
    
    Reported-and-Tested-by: youling257 <youling257@gmail.com>
    Cc: linux-wireless@vger.kernel.org
    Cc: youling257 <youling257@gmail.com>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca0908ddcd303d5e91982c6e5a91ad3d99cc99b6
Author: Ben Wolsieffer <benwolsieffer@gmail.com>
Date:   Sat Nov 3 19:32:20 2018 -0400

    staging: vchiq_arm: fix compat VCHIQ_IOC_AWAIT_COMPLETION
    
    commit 5a96b2d38dc054c0bbcbcd585b116566cbd877fe upstream.
    
    The compatibility ioctl wrapper for VCHIQ_IOC_AWAIT_COMPLETION assumes that
    the native ioctl always uses a message buffer and decrements msgbufcount.
    Certain message types do not use a message buffer and in this case
    msgbufcount is not decremented, and completion->header for the message is
    NULL. Because the wrapper unconditionally decrements msgbufcount, the
    calling process may assume that a message buffer has been used even when
    it has not.
    
    This results in a memory leak in the userspace code that interfaces with
    this driver. When msgbufcount is decremented, the userspace code assumes
    that the buffer can be freed though the reference in completion->header,
    which cannot happen when the reference is NULL.
    
    This patch causes the wrapper to only decrement msgbufcount when the
    native ioctl decrements it. Note that we cannot simply copy the native
    ioctl's value of msgbufcount, because the wrapper only retrieves messages
    from the native ioctl one at a time, while userspace may request multiple
    messages.
    
    See https://github.com/raspberrypi/linux/pull/2703 for more discussion of
    this patch.
    
    Fixes: 5569a1260933 ("staging: vchiq_arm: Add compatibility wrappers for ioctls")
    Signed-off-by: Ben Wolsieffer <benwolsieffer@gmail.com>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85df1f9f8fb0c9c4801f5cc8ab1b25e77c1f06cd
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Mon Dec 3 13:06:57 2018 +0200

    btrfs: release metadata before running delayed refs
    
    We want to release the unused reservation we have since it refills the
    delayed refs reserve, which will make everything go smoother when
    running the delayed refs if we're short on our reservation.
    
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Omar Sandoval <osandov@fb.com>
    Reviewed-by: Liu Bo <bo.liu@linux.alibaba.com>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39c49a757d7c3e27d3bfabd1e102e9544372e103
Author: Richard Genoud <richard.genoud@gmail.com>
Date:   Tue Nov 27 17:06:35 2018 +0100

    dmaengine: at_hdmac: fix module unloading
    
    commit 77e75fda94d2ebb86aa9d35fb1860f6395bf95de upstream.
    
    of_dma_controller_free() was not called on module onloading.
    This lead to a soft lockup:
    watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
    Modules linked in: at_hdmac [last unloaded: at_hdmac]
    when of_dma_request_slave_channel() tried to call ofdma->of_dma_xlate().
    
    Cc: stable@vger.kernel.org
    Fixes: bbe89c8e3d59 ("at_hdmac: move to generic DMA binding")
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e572222d3c9d67581f5409d7dbaf1e0e7b8de19
Author: Richard Genoud <richard.genoud@gmail.com>
Date:   Tue Nov 27 17:06:34 2018 +0100

    dmaengine: at_hdmac: fix memory leak in at_dma_xlate()
    
    commit 98f5f932254b88ce828bc8e4d1642d14e5854caa upstream.
    
    The leak was found when opening/closing a serial port a great number of
    time, increasing kmalloc-32 in slabinfo.
    
    Each time the port was opened, dma_request_slave_channel() was called.
    Then, in at_dma_xlate(), atslave was allocated with devm_kzalloc() and
    never freed. (Well, it was free at module unload, but that's not what we
    want).
    So, here, kzalloc is more suited for the job since it has to be freed in
    atc_free_chan_resources().
    
    Cc: stable@vger.kernel.org
    Fixes: bbe89c8e3d59 ("at_hdmac: move to generic DMA binding")
    Reported-by: Mario Forner <m.forner@be4energy.com>
    Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a9443a9358031c6192c876f3e51e1fa00c4d497
Author: Heiko Stuebner <heiko@sntech.de>
Date:   Sun Nov 18 20:03:02 2018 +0100

    ARM: dts: rockchip: Remove @0 from the veyron memory node
    
    commit 672e60b72bbe7aace88721db55b380b6a51fb8f9 upstream.
    
    The Coreboot version on veyron ChromeOS devices seems to ignore
    memory@0 nodes when updating the available memory and instead
    inserts another memory node without the address.
    
    This leads to 4GB systems only ever be using 2GB as the memory@0
    node takes precedence. So remove the @0 for veyron devices.
    
    Fixes: 0b639b815f15 ("ARM: dts: rockchip: Add missing unit name to memory nodes in rk3288 boards")
    Cc: stable@vger.kernel.org
    Reported-by: Heikki Lindholm <holin@iki.fi>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 086d1f60f874829124ebeaf7d2223a414221ca3b
Author: Pan Bian <bianpan2016@163.com>
Date:   Sun Nov 25 08:58:02 2018 +0800

    ext2: fix potential use after free
    
    commit ecebf55d27a11538ea84aee0be643dd953f830d5 upstream.
    
    The function ext2_xattr_set calls brelse(bh) to drop the reference count
    of bh. After that, bh may be freed. However, following brelse(bh),
    it reads bh->b_data via macro HDR(bh). This may result in a
    use-after-free bug. This patch moves brelse(bh) after reading field.
    
    CC: stable@vger.kernel.org
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2ec0cb4d09277730decd5e1a9c75fb18ccb7d7a
Author: Anisse Astier <anisse@astier.eu>
Date:   Fri Nov 23 17:59:11 2018 +0100

    ALSA: hda/realtek - fix headset mic detection for MSI MS-B171
    
    commit 8cd65271f8e545ddeed10ecc2e417936bdff168e upstream.
    
    MSI Cubi N 8GL (MS-B171) needs the same fixup as its older model, the
    MS-B120, in order for the headset mic to be properly detected.
    
    They both use a single 3-way jack for both mic and headset with an
    ALC283 codec, with the same pins used.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Anisse Astier <anisse@astier.eu>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e50476e9da270e1dfc742187aa1520ac4edb3a74
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu Nov 8 16:36:15 2018 +0800

    ALSA: hda/realtek - Support ALC300
    
    commit 1078bef0cd9291355a20369b21cd823026ab8eaa upstream.
    
    This patch will enable ALC300.
    
    [ It's almost equivalent with other ALC269-compatible ones, and
      apparently has no loopback mixer -- tiwai ]
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46663071adbc33e7b2a299b8e15bf36166101bcf
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Nov 23 18:18:30 2018 +0100

    ALSA: sparc: Fix invalid snd_free_pages() at error path
    
    commit 9a20332ab373b1f8f947e0a9c923652b32dab031 upstream.
    
    Some spurious calls of snd_free_pages() have been overlooked and
    remain in the error paths of sparc cs4231 driver code.  Since
    runtime->dma_area is managed by the PCM core helper, we shouldn't
    release manually.
    
    Drop the superfluous calls.
    
    Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73ce314c172d4f7340b217c08861863665888972
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 22 14:36:17 2018 +0100

    ALSA: control: Fix race between adding and removing a user element
    
    commit e1a7bfe3807974e66f971f2589d4e0197ec0fced upstream.
    
    The procedure for adding a user control element has some window opened
    for race against the concurrent removal of a user element.  This was
    caught by syzkaller, hitting a KASAN use-after-free error.
    
    This patch addresses the bug by wrapping the whole procedure to add a
    user control element with the card->controls_rwsem, instead of only
    around the increment of card->user_ctl_count.
    
    This required a slight code refactoring, too.  The function
    snd_ctl_add() is split to two parts: a core function to add the
    control element and a part calling it.  The former is called from the
    function for adding a user control element inside the controls_rwsem.
    
    One change to be noted is that snd_ctl_notify() for adding a control
    element gets called inside the controls_rwsem as well while it was
    called outside the rwsem.  But this should be OK, as snd_ctl_notify()
    takes another (finer) rwlock instead of rwsem, and the call of
    snd_ctl_notify() inside rwsem is already done in another code path.
    
    Reported-by: syzbot+dc09047bce3820621ba2@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef8944bf5a97557bf0cb7b0da78bc60eb78bff33
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Nov 23 15:44:00 2018 +0100

    ALSA: ac97: Fix incorrect bit shift at AC97-SPSA control write
    
    commit 7194eda1ba0872d917faf3b322540b4f57f11ba5 upstream.
    
    The function snd_ac97_put_spsa() gets the bit shift value from the
    associated private_value, but it extracts too much; the current code
    extracts 8 bit values in bits 8-15, but this is a combination of two
    nibbles (bits 8-11 and bits 12-15) for left and right shifts.
    Due to the incorrect bits extraction, the actual shift may go beyond
    the 32bit value, as spotted recently by UBSAN check:
     UBSAN: Undefined behaviour in sound/pci/ac97/ac97_codec.c:836:7
     shift exponent 68 is too large for 32-bit type 'int'
    
    This patch fixes the shift value extraction by masking the properly
    with 0x0f instead of 0xff.
    
    Reported-and-tested-by: Meelis Roos <mroos@linux.ee>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d542d58b6b5fe01095484c2628e46afe88312a9
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Nov 23 18:16:33 2018 +0100

    ALSA: wss: Fix invalid snd_free_pages() at error path
    
    commit 7b69154171b407844c273ab4c10b5f0ddcd6aa29 upstream.
    
    Some spurious calls of snd_free_pages() have been overlooked and
    remain in the error paths of wss driver code.  Since runtime->dma_area
    is managed by the PCM core helper, we shouldn't release manually.
    
    Drop the superfluous calls.
    
    Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7c769ebd9db6e67a6e01c962f7c92b706fa6acf
Author: Maximilian Heyne <mheyne@amazon.de>
Date:   Fri Nov 30 08:35:14 2018 -0700

    fs: fix lost error code in dio_complete
    
    commit 41e817bca3acd3980efe5dd7d28af0e6f4ab9247 upstream.
    
    commit e259221763a40403d5bb232209998e8c45804ab8 ("fs: simplify the
    generic_write_sync prototype") reworked callers of generic_write_sync(),
    and ended up dropping the error return for the directio path. Prior to
    that commit, in dio_complete(), an error would be bubbled up the stack,
    but after that commit, errors passed on to dio_complete were eaten up.
    
    This was reported on the list earlier, and a fix was proposed in
    https://lore.kernel.org/lkml/20160921141539.GA17898@infradead.org/, but
    never followed up with.  We recently hit this bug in our testing where
    fencing io errors, which were previously erroring out with EIO, were
    being returned as success operations after this commit.
    
    The fix proposed on the list earlier was a little short -- it would have
    still called generic_write_sync() in case `ret` already contained an
    error. This fix ensures generic_write_sync() is only called when there's
    no pending error in the write. Additionally, transferred is replaced
    with ret to bring this code in line with other callers.
    
    Fixes: e259221763a4 ("fs: simplify the generic_write_sync prototype")
    Reported-by: Ravi Nankani <rnankani@amazon.com>
    Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    CC: Torsten Mehlan <tomeh@amazon.de>
    CC: Uwe Dannowski <uwed@amazon.de>
    CC: Amit Shah <aams@amazon.de>
    CC: David Woodhouse <dwmw@amazon.co.uk>
    CC: stable@vger.kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ecef7c1ad46bfdc64c99574488252f4ba029afbc
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Wed Nov 21 11:16:11 2018 +0100

    perf/x86/intel: Add generic branch tracing check to intel_pmu_has_bts()
    
    commit 67266c1080ad56c31af72b9c18355fde8ccc124a upstream.
    
    Currently we check the branch tracing only by checking for the
    PERF_COUNT_HW_BRANCH_INSTRUCTIONS event of PERF_TYPE_HARDWARE
    type. But we can define the same event with the PERF_TYPE_RAW
    type.
    
    Changing the intel_pmu_has_bts() code to check on event's final
    hw config value, so both HW types are covered.
    
    Adding unlikely to intel_pmu_has_bts() condition calls, because
    it was used in the original code in intel_bts_constraints.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: <stable@vger.kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Link: http://lkml.kernel.org/r/20181121101612.16272-2-jolsa@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fae1bec5c2b29e809bd81b2ce8b5ba979ad23a92
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Wed Nov 21 11:16:10 2018 +0100

    perf/x86/intel: Move branch tracing setup to the Intel-specific source file
    
    commit ed6101bbf6266ee83e620b19faa7c6ad56bb41ab upstream.
    
    Moving branch tracing setup to Intel core object into separate
    intel_pmu_bts_config function, because it's Intel specific.
    
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: <stable@vger.kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Link: http://lkml.kernel.org/r/20181121101612.16272-1-jolsa@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8499ab5b93aca271c343786084c000c6f7839b5
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Tue Nov 20 11:26:35 2018 +0100

    x86/fpu: Disable bottom halves while loading FPU registers
    
    commit 68239654acafe6aad5a3c1dc7237e60accfebc03 upstream.
    
    The sequence
    
      fpu->initialized = 1;         /* step A */
      preempt_disable();            /* step B */
      fpu__restore(fpu);
      preempt_enable();
    
    in __fpu__restore_sig() is racy in regard to a context switch.
    
    For 32bit frames, __fpu__restore_sig() prepares the FPU state within
    fpu->state. To ensure that a context switch (switch_fpu_prepare() in
    particular) does not modify fpu->state it uses fpu__drop() which sets
    fpu->initialized to 0.
    
    After fpu->initialized is cleared, the CPU's FPU state is not saved
    to fpu->state during a context switch. The new state is loaded via
    fpu__restore(). It gets loaded into fpu->state from userland and
    ensured it is sane. fpu->initialized is then set to 1 in order to avoid
    fpu__initialize() doing anything (overwrite the new state) which is part
    of fpu__restore().
    
    A context switch between step A and B above would save CPU's current FPU
    registers to fpu->state and overwrite the newly prepared state. This
    looks like a tiny race window but the Kernel Test Robot reported this
    back in 2016 while we had lazy FPU support. Borislav Petkov made the
    link between that report and another patch that has been posted. Since
    the removal of the lazy FPU support, this race goes unnoticed because
    the warning has been removed.
    
    Disable bottom halves around the restore sequence to avoid the race. BH
    need to be disabled because BH is allowed to run (even with preemption
    disabled) and might invoke kernel_fpu_begin() by doing IPsec.
    
     [ bp: massage commit message a bit. ]
    
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
    Cc: kvm ML <kvm@vger.kernel.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: stable@vger.kernel.org
    Cc: x86-ml <x86@kernel.org>
    Link: http://lkml.kernel.org/r/20181120102635.ddv3fvavxajjlfqk@linutronix.de
    Link: https://lkml.kernel.org/r/20160226074940.GA28911@pd.tnic
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 855eefd9124a5a963625c046faca862c9369b37c
Author: Borislav Petkov <bp@suse.de>
Date:   Tue Nov 27 14:41:37 2018 +0100

    x86/MCE/AMD: Fix the thresholding machinery initialization order
    
    commit 60c8144afc287ef09ce8c1230c6aa972659ba1bb upstream.
    
    Currently, the code sets up the thresholding interrupt vector and only
    then goes about initializing the thresholding banks. Which is wrong,
    because an early thresholding interrupt would cause a NULL pointer
    dereference when accessing those banks and prevent the machine from
    booting.
    
    Therefore, set the thresholding interrupt vector only *after* having
    initialized the banks successfully.
    
    Fixes: 18807ddb7f88 ("x86/mce/AMD: Reset Threshold Limit after logging error")
    Reported-by: Rafał Miłecki <rafal@milecki.pl>
    Reported-by: John Clemens <clemej@gmail.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Tested-by: Rafał Miłecki <rafal@milecki.pl>
    Tested-by: John Clemens <john@deater.net>
    Cc: Aravind Gopalakrishnan <aravindksg.lkml@gmail.com>
    Cc: linux-edac@vger.kernel.org
    Cc: stable@vger.kernel.org
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: x86@kernel.org
    Cc: Yazen Ghannam <Yazen.Ghannam@amd.com>
    Link: https://lkml.kernel.org/r/20181127101700.2964-1-zajec5@gmail.com
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=201291
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad953dfdfa9543d224abd18fbf12bcac6454c376
Author: Christoph Muellner <christoph.muellner@theobroma-systems.com>
Date:   Tue Nov 13 11:25:35 2018 +0100

    arm64: dts: rockchip: Fix PCIe reset polarity for rk3399-puma-haikou.
    
    commit c1d91f86a1b4c9c05854d59c6a0abd5d0f75b849 upstream.
    
    This patch fixes the wrong polarity setting for the PCIe host driver's
    pre-reset pin for rk3399-puma-haikou. Without this patch link training
    will most likely fail.
    
    Fixes: 60fd9f72ce8a ("arm64: dts: rockchip: add Haikou baseboard with RK3399-Q7 SoM")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee48a9df170c233b406d49aa8840625a51ee9c0c
Author: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Date:   Wed Nov 7 05:16:49 2018 +0000

    PCI: layerscape: Fix wrong invocation of outbound window disable accessor
    
    commit c6fd6fe9dea44732cdcd970f1130b8cc50ad685a upstream.
    
    The order of parameters is not correct when invoking the outbound
    window disable routine. Fix it.
    
    Fixes: 4a2745d760fa ("PCI: layerscape: Disable outbound windows configured by bootloader")
    Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
    [lorenzo.pieralisi@arm.com: commit log]
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e380f318e63d851607cfc8b288281668aad11d53
Author: Pan Bian <bianpan2016@163.com>
Date:   Fri Nov 23 18:10:15 2018 +0800

    btrfs: relocation: set trans to be NULL after ending transaction
    
    commit 42a657f57628402c73237547f0134e083e2f6764 upstream.
    
    The function relocate_block_group calls btrfs_end_transaction to release
    trans when update_backref_cache returns 1, and then continues the loop
    body. If btrfs_block_rsv_refill fails this time, it will jump out the
    loop and the freed trans will be accessed. This may result in a
    use-after-free bug. The patch assigns NULL to trans after trans is
    released so that it will not be accessed.
    
    Fixes: 0647bf564f1 ("Btrfs: improve forever loop when doing balance relocation")
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52fa8eaac8149594d57bd4fe0cfeaa329037d400
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Nov 14 11:35:24 2018 +0000

    Btrfs: ensure path name is null terminated at btrfs_control_ioctl
    
    commit f505754fd6599230371cb01b9332754ddc104be1 upstream.
    
    We were using the path name received from user space without checking that
    it is null terminated. While btrfs-progs is well behaved and does proper
    validation and null termination, someone could call the ioctl and pass
    a non-null terminated patch, leading to buffer overrun problems in the
    kernel.  The ioctl is protected by CAP_SYS_ADMIN.
    
    So just set the last byte of the path to a null character, similar to what
    we do in other ioctls (add/remove/resize device, snapshot creation, etc).
    
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d36e4ee3b3ce4cf93e8fa145841287bbdb140fec
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Mon Nov 26 18:06:01 2018 -0800

    xtensa: fix coprocessor part of ptrace_{get,set}xregs
    
    commit 38a35a78c5e270cbe53c4fef6b0d3c2da90dd849 upstream.
    
    Layout of coprocessor registers in the elf_xtregs_t and
    xtregs_coprocessor_t may be different due to alignment. Thus it is not
    always possible to copy data between the xtregs_coprocessor_t structure
    and the elf_xtregs_t and get correct values for all registers.
    Use a table of offsets and sizes of individual coprocessor register
    groups to do coprocessor context copying in the ptrace_getxregs and
    ptrace_setxregs.
    This fixes incorrect coprocessor register values reading from the user
    process by the native gdb on an xtensa core with multiple coprocessors
    and registers with high alignment requirements.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b35182226166c03713a10ffebcf2838569c95d57
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Mon Nov 26 15:18:26 2018 -0800

    xtensa: fix coprocessor context offset definitions
    
    commit 03bc996af0cc71c7f30c384d8ce7260172423b34 upstream.
    
    Coprocessor context offsets are used by the assembly code that moves
    coprocessor context between the individual fields of the
    thread_info::xtregs_cp structure and coprocessor registers.
    This fixes coprocessor context clobbering on flushing and reloading
    during normal user code execution and user process debugging in the
    presence of more than one coprocessor in the core configuration.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d039837ab8cb7fb7095ec9746fb04a854987179e
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Mon Nov 26 13:29:41 2018 -0800

    xtensa: enable coprocessors that are being flushed
    
    commit 2958b66694e018c552be0b60521fec27e8d12988 upstream.
    
    coprocessor_flush_all may be called from a context of a thread that is
    different from the thread being flushed. In that case contents of the
    cpenable special register may not match ti->cpenable of the target
    thread, resulting in unhandled coprocessor exception in the kernel
    context.
    Set cpenable special register to the ti->cpenable of the target register
    for the duration of the flush and restore it afterwards.
    This fixes the following crash caused by coprocessor register inspection
    in native gdb:
    
      (gdb) p/x $w0
      Illegal instruction in kernel: sig: 9 [#1] PREEMPT
      Call Trace:
        ___might_sleep+0x184/0x1a4
        __might_sleep+0x41/0xac
        exit_signals+0x14/0x218
        do_exit+0xc9/0x8b8
        die+0x99/0xa0
        do_illegal_instruction+0x18/0x6c
        common_exception+0x77/0x77
        coprocessor_flush+0x16/0x3c
        arch_ptrace+0x46c/0x674
        sys_ptrace+0x2ce/0x3b4
        system_call+0x54/0x80
        common_exception+0x77/0x77
      note: gdb[100] exited with preempt_count 1
      Killed
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83f00ab9a7c03e9f1410727d985b7fe9473002e1
Author: Wanpeng Li <wanpengli@tencent.com>
Date:   Tue Nov 20 16:34:18 2018 +0800

    KVM: X86: Fix scan ioapic use-before-initialization
    
    commit e97f852fd4561e77721bb9a4e0ea9d98305b1e93 upstream.
    
    Reported by syzkaller:
    
     BUG: unable to handle kernel NULL pointer dereference at 00000000000001c8
     PGD 80000003ec4da067 P4D 80000003ec4da067 PUD 3f7bfa067 PMD 0
     Oops: 0000 [#1] PREEMPT SMP PTI
     CPU: 7 PID: 5059 Comm: debug Tainted: G           OE     4.19.0-rc5 #16
     RIP: 0010:__lock_acquire+0x1a6/0x1990
     Call Trace:
      lock_acquire+0xdb/0x210
      _raw_spin_lock+0x38/0x70
      kvm_ioapic_scan_entry+0x3e/0x110 [kvm]
      vcpu_enter_guest+0x167e/0x1910 [kvm]
      kvm_arch_vcpu_ioctl_run+0x35c/0x610 [kvm]
      kvm_vcpu_ioctl+0x3e9/0x6d0 [kvm]
      do_vfs_ioctl+0xa5/0x690
      ksys_ioctl+0x6d/0x80
      __x64_sys_ioctl+0x1a/0x20
      do_syscall_64+0x83/0x6e0
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    The reason is that the testcase writes hyperv synic HV_X64_MSR_SINT6 msr
    and triggers scan ioapic logic to load synic vectors into EOI exit bitmap.
    However, irqchip is not initialized by this simple testcase, ioapic/apic
    objects should not be accessed.
    This can be triggered by the following program:
    
        #define _GNU_SOURCE
    
        #include <endian.h>
        #include <stdint.h>
        #include <stdio.h>
        #include <stdlib.h>
        #include <string.h>
        #include <sys/syscall.h>
        #include <sys/types.h>
        #include <unistd.h>
    
        uint64_t r[3] = {0xffffffffffffffff, 0xffffffffffffffff, 0xffffffffffffffff};
    
        int main(void)
        {
            syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0);
            long res = 0;
            memcpy((void*)0x20000040, "/dev/kvm", 9);
            res = syscall(__NR_openat, 0xffffffffffffff9c, 0x20000040, 0, 0);
            if (res != -1)
                    r[0] = res;
            res = syscall(__NR_ioctl, r[0], 0xae01, 0);
            if (res != -1)
                    r[1] = res;
            res = syscall(__NR_ioctl, r[1], 0xae41, 0);
            if (res != -1)
                    r[2] = res;
            memcpy(
                            (void*)0x20000080,
                            "\x01\x00\x00\x00\x00\x5b\x61\xbb\x96\x00\x00\x40\x00\x00\x00\x00\x01\x00"
                            "\x08\x00\x00\x00\x00\x00\x0b\x77\xd1\x78\x4d\xd8\x3a\xed\xb1\x5c\x2e\x43"
                            "\xaa\x43\x39\xd6\xff\xf5\xf0\xa8\x98\xf2\x3e\x37\x29\x89\xde\x88\xc6\x33"
                            "\xfc\x2a\xdb\xb7\xe1\x4c\xac\x28\x61\x7b\x9c\xa9\xbc\x0d\xa0\x63\xfe\xfe"
                            "\xe8\x75\xde\xdd\x19\x38\xdc\x34\xf5\xec\x05\xfd\xeb\x5d\xed\x2e\xaf\x22"
                            "\xfa\xab\xb7\xe4\x42\x67\xd0\xaf\x06\x1c\x6a\x35\x67\x10\x55\xcb",
                            106);
            syscall(__NR_ioctl, r[2], 0x4008ae89, 0x20000080);
            syscall(__NR_ioctl, r[2], 0xae80, 0);
            return 0;
        }
    
    This patch fixes it by bailing out scan ioapic if ioapic is not initialized in
    kernel.
    
    Reported-by: Wei Wu <ww9210@gmail.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: Wei Wu <ww9210@gmail.com>
    Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08b9a96720a1e67dfed4b22a5192892d556fc5fc
Author: Liran Alon <liran.alon@oracle.com>
Date:   Thu Nov 8 00:43:06 2018 +0200

    KVM: x86: Fix kernel info-leak in KVM_HC_CLOCK_PAIRING hypercall
    
    commit bcbfbd8ec21096027f1ee13ce6c185e8175166f6 upstream.
    
    kvm_pv_clock_pairing() allocates local var
    "struct kvm_clock_pairing clock_pairing" on stack and initializes
    all it's fields besides padding (clock_pairing.pad[]).
    
    Because clock_pairing var is written completely (including padding)
    to guest memory, failure to init struct padding results in kernel
    info-leak.
    
    Fix the issue by making sure to also init the padding with zeroes.
    
    Fixes: 55dd00a73a51 ("KVM: x86: add KVM_HC_CLOCK_PAIRING hypercall")
    Reported-by: syzbot+a8ef68d71211ba264f56@syzkaller.appspotmail.com
    Reviewed-by: Mark Kanda <mark.kanda@oracle.com>
    Signed-off-by: Liran Alon <liran.alon@oracle.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57e972ecad4fdee027a690b64c7d619dae489015
Author: Jim Mattson <jmattson@google.com>
Date:   Tue May 22 09:54:20 2018 -0700

    kvm: svm: Ensure an IBPB on all affected CPUs when freeing a vmcb
    
    commit fd65d3142f734bc4376053c8d75670041903134d upstream.
    
    Previously, we only called indirect_branch_prediction_barrier on the
    logical CPU that freed a vmcb. This function should be called on all
    logical CPUs that last loaded the vmcb in question.
    
    Fixes: 15d45071523d ("KVM/x86: Add IBPB support")
    Reported-by: Neel Natu <neelnatu@google.com>
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a06361526cc71cb0ebef6ab7aa698ec63465b562
Author: Junaid Shahid <junaids@google.com>
Date:   Wed Oct 31 14:53:57 2018 -0700

    kvm: mmu: Fix race in emulated page table writes
    
    commit 0e0fee5c539b61fdd098332e0e2cc375d9073706 upstream.
    
    When a guest page table is updated via an emulated write,
    kvm_mmu_pte_write() is called to update the shadow PTE using the just
    written guest PTE value. But if two emulated guest PTE writes happened
    concurrently, it is possible that the guest PTE and the shadow PTE end
    up being out of sync. Emulated writes do not mark the shadow page as
    unsync-ed, so this inconsistency will not be resolved even by a guest TLB
    flush (unless the page was marked as unsync-ed at some other point).
    
    This is fixed by re-reading the current value of the guest PTE after the
    MMU lock has been acquired instead of just using the value that was
    written prior to calling kvm_mmu_pte_write().
    
    Signed-off-by: Junaid Shahid <junaids@google.com>
    Reviewed-by: Wanpeng Li <wanpengli@tencent.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78085d7e3816606d6aa211245ab2cde3463d7795
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:56 2018 +0100

    x86/speculation: Provide IBPB always command line options
    
    commit 55a974021ec952ee460dc31ca08722158639de72 upstream
    
    Provide the possibility to enable IBPB always in combination with 'prctl'
    and 'seccomp'.
    
    Add the extra command line options and rework the IBPB selection to
    evaluate the command instead of the mode selected by the STIPB switch case.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185006.144047038@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca97dd0009e688a67f6e22ce3fce0b4523741243
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:55 2018 +0100

    x86/speculation: Add seccomp Spectre v2 user space protection mode
    
    commit 6b3e64c237c072797a9ec918654a60e3a46488e2 upstream
    
    If 'prctl' mode of user space protection from spectre v2 is selected
    on the kernel command-line, STIBP and IBPB are applied on tasks which
    restrict their indirect branch speculation via prctl.
    
    SECCOMP enables the SSBD mitigation for sandboxed tasks already, so it
    makes sense to prevent spectre v2 user space to user space attacks as
    well.
    
    The Intel mitigation guide documents how STIPB works:
    
       Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor
       prevents the predicted targets of indirect branches on any logical
       processor of that core from being controlled by software that executes
       (or executed previously) on another logical processor of the same core.
    
    Ergo setting STIBP protects the task itself from being attacked from a task
    running on a different hyper-thread and protects the tasks running on
    different hyper-threads from being attacked.
    
    While the document suggests that the branch predictors are shielded between
    the logical processors, the observed performance regressions suggest that
    STIBP simply disables the branch predictor more or less completely. Of
    course the document wording is vague, but the fact that there is also no
    requirement for issuing IBPB when STIBP is used points clearly in that
    direction. The kernel still issues IBPB even when STIBP is used until Intel
    clarifies the whole mechanism.
    
    IBPB is issued when the task switches out, so malicious sandbox code cannot
    mistrain the branch predictor for the next user space task on the same
    logical processor.
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185006.051663132@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 605b2828ff55471d8b2ab0b405991895a2216e06
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:54 2018 +0100

    x86/speculation: Enable prctl mode for spectre_v2_user
    
    commit 7cc765a67d8e04ef7d772425ca5a2a1e2b894c15 upstream
    
    Now that all prerequisites are in place:
    
     - Add the prctl command line option
    
     - Default the 'auto' mode to 'prctl'
    
     - When SMT state changes, update the static key which controls the
       conditional STIBP evaluation on context switch.
    
     - At init update the static key which controls the conditional IBPB
       evaluation on context switch.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185005.958421388@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a847a6057721011b9534e709e5286c51ea31b9f
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:53 2018 +0100

    x86/speculation: Add prctl() control for indirect branch speculation
    
    commit 9137bb27e60e554dab694eafa4cca241fa3a694f upstream
    
    Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
    PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
    indirect branch speculation via STIBP and IBPB.
    
    Invocations:
     Check indirect branch speculation status with
     - prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
    
     Enable indirect branch speculation with
     - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
    
     Disable indirect branch speculation with
     - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
    
     Force disable indirect branch speculation with
     - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
    
    See Documentation/userspace-api/spec_ctrl.rst.
    
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99f1cb80daab80107c4b7f7f9a9ddf041a8b2137
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:52 2018 +0100

    x86/speculation: Prepare arch_smt_update() for PRCTL mode
    
    commit 6893a959d7fdebbab5f5aa112c277d5a44435ba1 upstream
    
    The upcoming fine grained per task STIBP control needs to be updated on CPU
    hotplug as well.
    
    Split out the code which controls the strict mode so the prctl control code
    can be added later. Mark the SMP function call argument __unused while at it.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185005.759457117@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3f822b628a0d715a46d233e81881f6c2885247b
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Nov 28 10:56:57 2018 +0100

    x86/speculation: Prevent stale SPEC_CTRL msr content
    
    commit 6d991ba509ebcfcc908e009d1db51972a4f7a064 upstream
    
    The seccomp speculation control operates on all tasks of a process, but
    only the current task of a process can update the MSR immediately. For the
    other threads the update is deferred to the next context switch.
    
    This creates the following situation with Process A and B:
    
    Process A task 2 and Process B task 1 are pinned on CPU1. Process A task 2
    does not have the speculation control TIF bit set. Process B task 1 has the
    speculation control TIF bit set.
    
    CPU0                                    CPU1
                                            MSR bit is set
                                            ProcB.T1 schedules out
                                            ProcA.T2 schedules in
                                            MSR bit is cleared
    ProcA.T1
      seccomp_update()
      set TIF bit on ProcA.T2
                                            ProcB.T1 schedules in
                                            MSR is not updated  <-- FAIL
    
    This happens because the context switch code tries to avoid the MSR update
    if the speculation control TIF bits of the incoming and the outgoing task
    are the same. In the worst case ProcB.T1 and ProcA.T2 are the only tasks
    scheduling back and forth on CPU1, which keeps the MSR stale forever.
    
    In theory this could be remedied by IPIs, but chasing the remote task which
    could be migrated is complex and full of races.
    
    The straight forward solution is to avoid the asychronous update of the TIF
    bit and defer it to the next context switch. The speculation control state
    is stored in task_struct::atomic_flags by the prctl and seccomp updates
    already.
    
    Add a new TIF_SPEC_FORCE_UPDATE bit and set this after updating the
    atomic_flags. Check the bit on context switch and force a synchronous
    update of the speculation control if set. Use the same mechanism for
    updating the current task.
    
    Reported-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1811272247140.1875@nanos.tec.linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcb4ac34f9373b1f4365b24ddfac2bcdefd59f6e
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:51 2018 +0100

    x86/speculation: Split out TIF update
    
    commit e6da8bb6f9abb2628381904b24163c770e630bac upstream
    
    The update of the TIF_SSBD flag and the conditional speculation control MSR
    update is done in the ssb_prctl_set() function directly. The upcoming prctl
    support for controlling indirect branch speculation via STIBP needs the
    same mechanism.
    
    Split the code out and make it reusable. Reword the comment about updates
    for other tasks.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185005.652305076@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dae4d59096700703266190f8dff92f9edb82b1b5
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:50 2018 +0100

    ptrace: Remove unused ptrace_may_access_sched() and MODE_IBRS
    
    commit 46f7ecb1e7359f183f5bbd1e08b90e10e52164f9 upstream
    
    The IBPB control code in x86 removed the usage. Remove the functionality
    which was introduced for this.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185005.559149393@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbca99b96f06f540669f07f768e228014e38b3b6
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:49 2018 +0100

    x86/speculation: Prepare for conditional IBPB in switch_mm()
    
    commit 4c71a2b6fd7e42814aa68a6dec88abf3b42ea573 upstream
    
    The IBPB speculation barrier is issued from switch_mm() when the kernel
    switches to a user space task with a different mm than the user space task
    which ran last on the same CPU.
    
    An additional optimization is to avoid IBPB when the incoming task can be
    ptraced by the outgoing task. This optimization only works when switching
    directly between two user space tasks. When switching from a kernel task to
    a user space task the optimization fails because the previous task cannot
    be accessed anymore. So for quite some scenarios the optimization is just
    adding overhead.
    
    The upcoming conditional IBPB support will issue IBPB only for user space
    tasks which have the TIF_SPEC_IB bit set. This requires to handle the
    following cases:
    
      1) Switch from a user space task (potential attacker) which has
         TIF_SPEC_IB set to a user space task (potential victim) which has
         TIF_SPEC_IB not set.
    
      2) Switch from a user space task (potential attacker) which has
         TIF_SPEC_IB not set to a user space task (potential victim) which has
         TIF_SPEC_IB set.
    
    This needs to be optimized for the case where the IBPB can be avoided when
    only kernel threads ran in between user space tasks which belong to the
    same process.
    
    The current check whether two tasks belong to the same context is using the
    tasks context id. While correct, it's simpler to use the mm pointer because
    it allows to mangle the TIF_SPEC_IB bit into it. The context id based
    mechanism requires extra storage, which creates worse code.
    
    When a task is scheduled out its TIF_SPEC_IB bit is mangled as bit 0 into
    the per CPU storage which is used to track the last user space mm which was
    running on a CPU. This bit can be used together with the TIF_SPEC_IB bit of
    the incoming task to make the decision whether IBPB needs to be issued or
    not to cover the two cases above.
    
    As conditional IBPB is going to be the default, remove the dubious ptrace
    check for the IBPB always case and simply issue IBPB always when the
    process changes.
    
    Move the storage to a different place in the struct as the original one
    created a hole.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185005.466447057@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba523588b1bc0b9601e7ef102b56dc246a91d026
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:48 2018 +0100

    x86/speculation: Avoid __switch_to_xtra() calls
    
    commit 5635d99953f04b550738f6f4c1c532667c3fd872 upstream
    
    The TIF_SPEC_IB bit does not need to be evaluated in the decision to invoke
    __switch_to_xtra() when:
    
     - CONFIG_SMP is disabled
    
     - The conditional STIPB mode is disabled
    
    The TIF_SPEC_IB bit still controls IBPB in both cases so the TIF work mask
    checks might invoke __switch_to_xtra() for nothing if TIF_SPEC_IB is the
    only set bit in the work masks.
    
    Optimize it out by masking the bit at compile time for CONFIG_SMP=n and at
    run time when the static key controlling the conditional STIBP mode is
    disabled.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185005.374062201@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fe6a4baff26dc90fa8ebcbb8f844cc8d3fb256f
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:47 2018 +0100

    x86/process: Consolidate and simplify switch_to_xtra() code
    
    commit ff16701a29cba3aafa0bd1656d766813b2d0a811 upstream
    
    Move the conditional invocation of __switch_to_xtra() into an inline
    function so the logic can be shared between 32 and 64 bit.
    
    Remove the handthrough of the TSS pointer and retrieve the pointer directly
    in the bitmap handling function. Use this_cpu_ptr() instead of the
    per_cpu() indirection.
    
    This is a preparatory change so integration of conditional indirect branch
    speculation optimization happens only in one place.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185005.280855518@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fe4e69a5ce7bf36fbd303e64cb63adb14708c0b
Author: Tim Chen <tim.c.chen@linux.intel.com>
Date:   Sun Nov 25 19:33:46 2018 +0100

    x86/speculation: Prepare for per task indirect branch speculation control
    
    commit 5bfbe3ad5840d941b89bcac54b821ba14f50a0ba upstream
    
    To avoid the overhead of STIBP always on, it's necessary to allow per task
    control of STIBP.
    
    Add a new task flag TIF_SPEC_IB and evaluate it during context switch if
    SMT is active and flag evaluation is enabled by the speculation control
    code. Add the conditional evaluation to x86_virt_spec_ctrl() as well so the
    guest/host switch works properly.
    
    This has no effect because TIF_SPEC_IB cannot be set yet and the static key
    which controls evaluation is off. Preparatory patch for adding the control
    code.
    
    [ tglx: Simplify the context switch logic and make the TIF evaluation
            depend on SMP=y and on the static key controlling the conditional
            update. Rename it to TIF_SPEC_IB because it controls both STIBP and
            IBPB ]
    
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185005.176917199@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90f293cc49fa44e24c07e74c89f3d87bc97cf41e
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:45 2018 +0100

    x86/speculation: Add command line control for indirect branch speculation
    
    commit fa1202ef224391b6f5b26cdd44cc50495e8fab54 upstream
    
    Add command line control for user space indirect branch speculation
    mitigations. The new option is: spectre_v2_user=
    
    The initial options are:
    
        -  on:   Unconditionally enabled
        - off:   Unconditionally disabled
        -auto:   Kernel selects mitigation (default off for now)
    
    When the spectre_v2= command line argument is either 'on' or 'off' this
    implies that the application to application control follows that state even
    if a contradicting spectre_v2_user= argument is supplied.
    
    Originally-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185005.082720373@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebd473909994d4ecce8e973f048f06d999f84845
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:44 2018 +0100

    x86/speculation: Unify conditional spectre v2 print functions
    
    commit 495d470e9828500e0155027f230449ac5e29c025 upstream
    
    There is no point in having two functions and a conditional at the call
    site.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185004.986890749@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95d41f1332f78fa6ad19459d1b98ad70407dd88b
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:43 2018 +0100

    x86/speculataion: Mark command line parser data __initdata
    
    commit 30ba72a990f5096ae08f284de17986461efcc408 upstream
    
    No point to keep that around.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185004.893886356@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit caa118cf4c7997a35f6a18f5a16c38c7a9c71e3f
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:42 2018 +0100

    x86/speculation: Mark string arrays const correctly
    
    commit 8770709f411763884535662744a3786a1806afd3 upstream
    
    checkpatch.pl muttered when reshuffling the code:
     WARNING: static const char * array should probably be static const char * const
    
    Fix up all the string arrays.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185004.800018931@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72f90a89be9e125c1dd44a4d70b83055d1c3753e
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:41 2018 +0100

    x86/speculation: Reorder the spec_v2 code
    
    commit 15d6b7aab0793b2de8a05d8a828777dd24db424e upstream
    
    Reorder the code so it is better grouped. No functional change.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185004.707122879@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8345d546238f68e7fe219df25eeecb200f34334b
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:40 2018 +0100

    x86/l1tf: Show actual SMT state
    
    commit 130d6f946f6f2a972ee3ec8540b7243ab99abe97 upstream
    
    Use the now exposed real SMT state, not the SMT sysfs control knob
    state. This reflects the state of the system when the mitigation status is
    queried.
    
    This does not change the warning in the VMX launch code. There the
    dependency on the control knob makes sense because siblings could be
    brought online anytime after launching the VM.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185004.613357354@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36a4c5fc92857711019dc56be2669e19f8c3c86e
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:39 2018 +0100

    x86/speculation: Rework SMT state change
    
    commit a74cfffb03b73d41e08f84c2e5c87dec0ce3db9f upstream
    
    arch_smt_update() is only called when the sysfs SMT control knob is
    changed. This means that when SMT is enabled in the sysfs control knob the
    system is considered to have SMT active even if all siblings are offline.
    
    To allow finegrained control of the speculation mitigations, the actual SMT
    state is more interesting than the fact that siblings could be enabled.
    
    Rework the code, so arch_smt_update() is invoked from each individual CPU
    hotplug function, and simplify the update function while at it.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185004.521974984@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e797117f18573ab31f72aed0924ff7999d860ea
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:38 2018 +0100

    sched/smt: Expose sched_smt_present static key
    
    commit 321a874a7ef85655e93b3206d0f36b4a6097f948 upstream
    
    Make the scheduler's 'sched_smt_present' static key globaly available, so
    it can be used in the x86 speculation control code.
    
    Provide a query function and a stub for the CONFIG_SMP=n case.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185004.430168326@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44ac7cd01544dd12241bc0c0e0eb5604ad77379a
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:37 2018 +0100

    x86/Kconfig: Select SCHED_SMT if SMP enabled
    
    commit dbe733642e01dd108f71436aaea7b328cb28fd87 upstream
    
    CONFIG_SCHED_SMT is enabled by all distros, so there is not a real point to
    have it configurable. The runtime overhead in the core scheduler code is
    minimal because the actual SMT scheduling parts are conditional on a static
    key.
    
    This allows to expose the scheduler's SMT state static key to the
    speculation control code. Alternatively the scheduler's static key could be
    made always available when CONFIG_SMP is enabled, but that's just adding an
    unused static key to every other architecture for nothing.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185004.337452245@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01659361c63fdc91c0af239d08cdd211d590a656
Author: Peter Zijlstra (Intel) <peterz@infradead.org>
Date:   Sun Nov 25 19:33:36 2018 +0100

    sched/smt: Make sched_smt_present track topology
    
    commit c5511d03ec090980732e929c318a7a6374b5550e upstream
    
    Currently the 'sched_smt_present' static key is enabled when at CPU bringup
    SMT topology is observed, but it is never disabled. However there is demand
    to also disable the key when the topology changes such that there is no SMT
    present anymore.
    
    Implement this by making the key count the number of cores that have SMT
    enabled.
    
    In particular, the SMT topology bits are set before interrrupts are enabled
    and similarly, are cleared after interrupts are disabled for the last time
    and the CPU dies.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185004.246110444@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc4aa78e6954bd71295543163271262fede5d46f
Author: Tim Chen <tim.c.chen@linux.intel.com>
Date:   Sun Nov 25 19:33:35 2018 +0100

    x86/speculation: Reorganize speculation control MSRs update
    
    commit 01daf56875ee0cd50ed496a09b20eb369b45dfa5 upstream
    
    The logic to detect whether there's a change in the previous and next
    task's flag relevant to update speculation control MSRs is spread out
    across multiple functions.
    
    Consolidate all checks needed for updating speculation control MSRs into
    the new __speculation_ctrl_update() helper function.
    
    This makes it easy to pick the right speculation control MSR and the bits
    in MSR_IA32_SPEC_CTRL that need updating based on TIF flags changes.
    
    Originally-by: Thomas Lendacky <Thomas.Lendacky@amd.com>
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185004.151077005@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 999b295ad1a9980754c6d63e9f8be109a3574118
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Nov 25 19:33:34 2018 +0100

    x86/speculation: Rename SSBD update functions
    
    commit 26c4d75b234040c11728a8acb796b3a85ba7507c upstream
    
    During context switch, the SSBD bit in SPEC_CTRL MSR is updated according
    to changes of the TIF_SSBD flag in the current and next running task.
    
    Currently, only the bit controlling speculative store bypass disable in
    SPEC_CTRL MSR is updated and the related update functions all have
    "speculative_store" or "ssb" in their names.
    
    For enhanced mitigation control other bits in SPEC_CTRL MSR need to be
    updated as well, which makes the SSB names inadequate.
    
    Rename the "speculative_store*" functions to a more generic name. No
    functional change.
    
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185004.058866968@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aca2ddbc23800652ec2f09c2df76f417823cda77
Author: Tim Chen <tim.c.chen@linux.intel.com>
Date:   Sun Nov 25 19:33:33 2018 +0100

    x86/speculation: Disable STIBP when enhanced IBRS is in use
    
    commit 34bce7c9690b1d897686aac89604ba7adc365556 upstream
    
    If enhanced IBRS is active, STIBP is redundant for mitigating Spectre v2
    user space exploits from hyperthread sibling.
    
    Disable STIBP when enhanced IBRS is used.
    
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185003.966801480@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8588c7d4a487927356a5026982bd89b45a2092fe
Author: Tim Chen <tim.c.chen@linux.intel.com>
Date:   Sun Nov 25 19:33:32 2018 +0100

    x86/speculation: Move STIPB/IBPB string conditionals out of cpu_show_common()
    
    commit a8f76ae41cd633ac00be1b3019b1eb4741be3828 upstream
    
    The Spectre V2 printout in cpu_show_common() handles conditionals for the
    various mitigation methods directly in the sprintf() argument list. That's
    hard to read and will become unreadable if more complex decisions need to
    be made for a particular method.
    
    Move the conditionals for STIBP and IBPB string selection into helper
    functions, so they can be extended later on.
    
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185003.874479208@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05dd5dc4c4fba8a8457b0bcb5336d4fe22d5c013
Author: Tim Chen <tim.c.chen@linux.intel.com>
Date:   Sun Nov 25 19:33:31 2018 +0100

    x86/speculation: Remove unnecessary ret variable in cpu_show_common()
    
    commit b86bda0426853bfe8a3506c7d2a5b332760ae46b upstream
    
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185003.783903657@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4398714cb7d595725a4840da137faeac47c10669
Author: Tim Chen <tim.c.chen@linux.intel.com>
Date:   Sun Nov 25 19:33:30 2018 +0100

    x86/speculation: Clean up spectre_v2_parse_cmdline()
    
    commit 24848509aa55eac39d524b587b051f4e86df3c12 upstream
    
    Remove the unnecessary 'else' statement in spectre_v2_parse_cmdline()
    to save an indentation level.
    
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185003.688010903@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d422ca1950a1f04bc467e706ae6f89840b0bd16
Author: Tim Chen <tim.c.chen@linux.intel.com>
Date:   Sun Nov 25 19:33:29 2018 +0100

    x86/speculation: Update the TIF_SSBD comment
    
    commit 8eb729b77faf83ac4c1f363a9ad68d042415f24c upstream
    
    "Reduced Data Speculation" is an obsolete term. The correct new name is
    "Speculative store bypass disable" - which is abbreviated into SSBD.
    
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Casey Schaufler <casey.schaufler@intel.com>
    Cc: Asit Mallick <asit.k.mallick@intel.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Jon Masters <jcm@redhat.com>
    Cc: Waiman Long <longman9394@gmail.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Dave Stewart <david.c.stewart@intel.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181125185003.593893901@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bbb50b6de99c178acd648a73098009073139f46
Author: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date:   Fri Nov 2 01:45:41 2018 -0700

    x86/retpoline: Remove minimal retpoline support
    
    commit ef014aae8f1cd2793e4e014bbb102bed53f852b7 upstream
    
    Now that CONFIG_RETPOLINE hard depends on compiler support, there is no
    reason to keep the minimal retpoline support around which only provided
    basic protection in the assembly files.
    
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: <srinivas.eeda@oracle.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/f06f0a89-5587-45db-8ed2-0a9d6638d5c0@default
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9c90037af800bcc74bbdac338355c7f331bd913
Author: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date:   Fri Nov 2 01:45:41 2018 -0700

    x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support
    
    commit 4cd24de3a0980bf3100c9dcb08ef65ca7c31af48 upstream
    
    Since retpoline capable compilers are widely available, make
    CONFIG_RETPOLINE hard depend on the compiler capability.
    
    Break the build when CONFIG_RETPOLINE is enabled and the compiler does not
    support it. Emit an error message in that case:
    
     "arch/x86/Makefile:226: *** You are building kernel with non-retpoline
      compiler, please update your compiler..  Stop."
    
    [dwmw: Fail the build with non-retpoline compiler]
    
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
    Cc: Michal Marek <michal.lkml@markovi.net>
    Cc: <srinivas.eeda@oracle.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/cca0cb20-f9e2-4094-840b-fb0f8810cd34@default
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46dfe55fbee9be96f70482f3053b084fad3858d0
Author: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date:   Tue Sep 18 07:45:00 2018 -0700

    x86/speculation: Add RETPOLINE_AMD support to the inline asm CALL_NOSPEC variant
    
    commit 0cbb76d6285794f30953bfa3ab831714b59dd700 upstream
    
    ..so that they match their asm counterpart.
    
    Add the missing ANNOTATE_NOSPEC_ALTERNATIVE in CALL_NOSPEC, while at it.
    
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Wang YanQing <udknight@gmail.com>
    Cc: dhaval.giani@oracle.com
    Cc: srinivas.eeda@oracle.com
    Link: http://lkml.kernel.org/r/c3975665-173e-4d70-8dee-06c926ac26ee@default
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d55dce78a0e96f0909f4b7395887e84ba637254
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Tue Sep 25 14:39:28 2018 +0200

    x86/speculation: Propagate information about RSB filling mitigation to sysfs
    
    commit bb4b3b7762735cdaba5a40fd94c9303d9ffa147a upstream
    
    If spectrev2 mitigation has been enabled, RSB is filled on context switch
    in order to protect from various classes of spectrev2 attacks.
    
    If this mitigation is enabled, say so in sysfs for spectrev2.
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc:  "WoodhouseDavid" <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc:  "SchauflerCasey" <casey.schaufler@intel.com>
    Link: https://lkml.kernel.org/r/nycvar.YFH.7.76.1809251438580.15880@cbobk.fhfr.pm
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4741e31931b27b9eba1e9df02d781a2f808b7d82
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Tue Sep 25 14:38:18 2018 +0200

    x86/speculation: Apply IBPB more strictly to avoid cross-process data leak
    
    commit dbfe2953f63c640463c630746cd5d9de8b2f63ae upstream
    
    Currently, IBPB is only issued in cases when switching into a non-dumpable
    process, the rationale being to protect such 'important and security
    sensitive' processess (such as GPG) from data leaking into a different
    userspace process via spectre v2.
    
    This is however completely insufficient to provide proper userspace-to-userpace
    spectrev2 protection, as any process can poison branch buffers before being
    scheduled out, and the newly scheduled process immediately becomes spectrev2
    victim.
    
    In order to minimize the performance impact (for usecases that do require
    spectrev2 protection), issue the barrier only in cases when switching between
    processess where the victim can't be ptraced by the potential attacker (as in
    such cases, the attacker doesn't have to bother with branch buffers at all).
    
    [ tglx: Split up PTRACE_MODE_NOACCESS_CHK into PTRACE_MODE_SCHED and
      PTRACE_MODE_IBPB to be able to do ptrace() context tracking reasonably
      fine-grained ]
    
    Fixes: 18bf3c3ea8 ("x86/speculation: Use Indirect Branch Prediction Barrier in context switch")
    Originally-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc:  "WoodhouseDavid" <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc:  "SchauflerCasey" <casey.schaufler@intel.com>
    Link: https://lkml.kernel.org/r/nycvar.YFH.7.76.1809251437340.15880@cbobk.fhfr.pm
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 300a6f27dd8277843e39b37cca5e0c5b203743cb
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Tue Sep 25 14:38:55 2018 +0200

    x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation
    
    commit 53c613fe6349994f023245519265999eed75957f upstream
    
    STIBP is a feature provided by certain Intel ucodes / CPUs. This feature
    (once enabled) prevents cross-hyperthread control of decisions made by
    indirect branch predictors.
    
    Enable this feature if
    
    - the CPU is vulnerable to spectre v2
    - the CPU supports SMT and has SMT siblings online
    - spectre_v2 mitigation autoselection is enabled (default)
    
    After some previous discussion, this leaves STIBP on all the time, as wrmsr
    on crossing kernel boundary is a no-no. This could perhaps later be a bit
    more optimized (like disabling it in NOHZ, experiment with disabling it in
    idle, etc) if needed.
    
    Note that the synchronization of the mask manipulation via newly added
    spec_ctrl_mutex is currently not strictly needed, as the only updater is
    already being serialized by cpu_add_remove_lock, but let's make this a
    little bit more future-proof.
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc:  "WoodhouseDavid" <dwmw@amazon.co.uk>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc:  "SchauflerCasey" <casey.schaufler@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/nycvar.YFH.7.76.1809251438240.15880@cbobk.fhfr.pm
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82647e461639a7cae7beaf2391f6b58f69b81110
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date:   Mon Jul 2 16:36:02 2018 -0500

    x86/bugs: Fix the AMD SSBD usage of the SPEC_CTRL MSR
    
    commit 612bc3b3d4be749f73a513a17d9b3ee1330d3487 upstream
    
    On AMD, the presence of the MSR_SPEC_CTRL feature does not imply that the
    SSBD mitigation support should use the SPEC_CTRL MSR. Other features could
    have caused the MSR_SPEC_CTRL feature to be set, while a different SSBD
    mitigation option is in place.
    
    Update the SSBD support to check for the actual SSBD features that will
    use the SPEC_CTRL MSR.
    
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Borislav Petkov <bpetkov@suse.de>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: 6ac2f49edb1e ("x86/bugs: Add AMD's SPEC_CTRL MSR usage")
    Link: http://lkml.kernel.org/r/20180702213602.29202.33151.stgit@tlendack-t1.amdoffice.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0071cdff923922f85a8204fd9bff56a44af2b9a3
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date:   Mon Jul 2 16:35:53 2018 -0500

    x86/bugs: Update when to check for the LS_CFG SSBD mitigation
    
    commit 845d382bb15c6e7dc5026c0ff919c5b13fc7e11b upstream
    
    If either the X86_FEATURE_AMD_SSBD or X86_FEATURE_VIRT_SSBD features are
    present, then there is no need to perform the check for the LS_CFG SSBD
    mitigation support.
    
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Borislav Petkov <bpetkov@suse.de>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20180702213553.29202.21089.stgit@tlendack-t1.amdoffice.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d2533a6818274602ef1a783594f2d6fc65d8fc6
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Jun 1 10:59:21 2018 -0400

    x86/bugs: Switch the selection of mitigation from CPU vendor to CPU features
    
    commit 108fab4b5c8f12064ef86e02cb0459992affb30f upstream
    
    Both AMD and Intel can have SPEC_CTRL_MSR for SSBD.
    
    However AMD also has two more other ways of doing it - which
    are !SPEC_CTRL MSR ways.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: kvm@vger.kernel.org
    Cc: KarimAllah Ahmed <karahmed@amazon.de>
    Cc: andrew.cooper3@citrix.com
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Link: https://lkml.kernel.org/r/20180601145921.9500-4-konrad.wilk@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54b65f8eaf75872052565976f524e91133778c54
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Jun 1 10:59:20 2018 -0400

    x86/bugs: Add AMD's SPEC_CTRL MSR usage
    
    commit 6ac2f49edb1ef5446089c7c660017732886d62d6 upstream
    
    The AMD document outlining the SSBD handling
    124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
    mentions that if CPUID 8000_0008.EBX[24] is set we should be using
    the SPEC_CTRL MSR (0x48) over the VIRT SPEC_CTRL MSR (0xC001_011f)
    for speculative store bypass disable.
    
    This in effect means we should clear the X86_FEATURE_VIRT_SSBD
    flag so that we would prefer the SPEC_CTRL MSR.
    
    See the document titled:
       124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
    
    A copy of this document is available at
       https://bugzilla.kernel.org/show_bug.cgi?id=199889
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
    Cc: kvm@vger.kernel.org
    Cc: KarimAllah Ahmed <karahmed@amazon.de>
    Cc: andrew.cooper3@citrix.com
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Kees Cook <keescook@chromium.org>
    Link: https://lkml.kernel.org/r/20180601145921.9500-3-konrad.wilk@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da06d6d14a0a14d398b1e7c8024b090e40f4ec89
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Jun 1 10:59:19 2018 -0400

    x86/bugs: Add AMD's variant of SSB_NO
    
    commit 24809860012e0130fbafe536709e08a22b3e959e upstream
    
    The AMD document outlining the SSBD handling
    124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
    mentions that the CPUID 8000_0008.EBX[26] will mean that the
    speculative store bypass disable is no longer needed.
    
    A copy of this document is available at:
        https://bugzilla.kernel.org/show_bug.cgi?id=199889
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
    Cc: kvm@vger.kernel.org
    Cc: andrew.cooper3@citrix.com
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Link: https://lkml.kernel.org/r/20180601145921.9500-2-konrad.wilk@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5d981df9a1d3f13dfff083ab0578daedbcd9e8a
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon Jan 22 22:53:28 2018 +0100

    sched/core: Fix cpu.max vs. cpuhotplug deadlock
    
    commit ce48c146495a1a50e48cdbfbfaba3e708be7c07c upstream
    
    Tejun reported the following cpu-hotplug lock (percpu-rwsem) read recursion:
    
      tg_set_cfs_bandwidth()
        get_online_cpus()
          cpus_read_lock()
    
        cfs_bandwidth_usage_inc()
          static_key_slow_inc()
            cpus_read_lock()
    
    Reported-by: Tejun Heo <tj@kernel.org>
    Tested-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20180122215328.GP3397@worktop
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72e5a2bdf753f5ba82ea6bfb7706aabc9587d0cb
Author: Bernd Eckstein <3erndeckstein@gmail.com>
Date:   Fri Nov 23 13:51:26 2018 +0100

    usbnet: ipheth: fix potential recvmsg bug and recvmsg bug 2
    
    [ Upstream commit 45611c61dd503454b2edae00aabe1e429ec49ebe ]
    
    The bug is not easily reproducable, as it may occur very infrequently
    (we had machines with 20minutes heavy downloading before it occurred)
    However, on a virual machine (VMWare on Windows 10 host) it occurred
    pretty frequently (1-2 seconds after a speedtest was started)
    
    dev->tx_skb mab be freed via dev_kfree_skb_irq on a callback
    before it is set.
    
    This causes the following problems:
    - double free of the skb or potential memory leak
    - in dmesg: 'recvmsg bug' and 'recvmsg bug 2' and eventually
      general protection fault
    
    Example dmesg output:
    [  134.841986] ------------[ cut here ]------------
    [  134.841987] recvmsg bug: copied 9C24A555 seq 9C24B557 rcvnxt 9C25A6B3 fl 0
    [  134.841993] WARNING: CPU: 7 PID: 2629 at /build/linux-hwe-On9fm7/linux-hwe-4.15.0/net/ipv4/tcp.c:1865 tcp_recvmsg+0x44d/0xab0
    [  134.841994] Modules linked in: ipheth(OE) kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd vmw_balloon intel_rapl_perf joydev input_leds serio_raw vmw_vsock_vmci_transport vsock shpchp i2c_piix4 mac_hid binfmt_misc vmw_vmci parport_pc ppdev lp parport autofs4 vmw_pvscsi vmxnet3 hid_generic usbhid hid vmwgfx ttm drm_kms_helper syscopyarea sysfillrect mptspi mptscsih sysimgblt ahci psmouse fb_sys_fops pata_acpi mptbase libahci e1000 drm scsi_transport_spi
    [  134.842046] CPU: 7 PID: 2629 Comm: python Tainted: G        W  OE    4.15.0-34-generic #37~16.04.1-Ubuntu
    [  134.842046] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
    [  134.842048] RIP: 0010:tcp_recvmsg+0x44d/0xab0
    [  134.842048] RSP: 0018:ffffa6630422bcc8 EFLAGS: 00010286
    [  134.842049] RAX: 0000000000000000 RBX: ffff997616f4f200 RCX: 0000000000000006
    [  134.842049] RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff9976257d6490
    [  134.842050] RBP: ffffa6630422bd98 R08: 0000000000000001 R09: 000000000004bba4
    [  134.842050] R10: 0000000001e00c6f R11: 000000000004bba4 R12: ffff99760dee3000
    [  134.842051] R13: 0000000000000000 R14: ffff99760dee3514 R15: 0000000000000000
    [  134.842051] FS:  00007fe332347700(0000) GS:ffff9976257c0000(0000) knlGS:0000000000000000
    [  134.842052] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  134.842053] CR2: 0000000001e41000 CR3: 000000020e9b4006 CR4: 00000000003606e0
    [  134.842055] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  134.842055] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  134.842057] Call Trace:
    [  134.842060]  ? aa_sk_perm+0x53/0x1a0
    [  134.842064]  inet_recvmsg+0x51/0xc0
    [  134.842066]  sock_recvmsg+0x43/0x50
    [  134.842070]  SYSC_recvfrom+0xe4/0x160
    [  134.842072]  ? __schedule+0x3de/0x8b0
    [  134.842075]  ? ktime_get_ts64+0x4c/0xf0
    [  134.842079]  SyS_recvfrom+0xe/0x10
    [  134.842082]  do_syscall_64+0x73/0x130
    [  134.842086]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    [  134.842086] RIP: 0033:0x7fe331f5a81d
    [  134.842088] RSP: 002b:00007ffe8da98398 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
    [  134.842090] RAX: ffffffffffffffda RBX: ffffffffffffffff RCX: 00007fe331f5a81d
    [  134.842094] RDX: 00000000000003fb RSI: 0000000001e00874 RDI: 0000000000000003
    [  134.842095] RBP: 00007fe32f642c70 R08: 0000000000000000 R09: 0000000000000000
    [  134.842097] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe332347698
    [  134.842099] R13: 0000000001b7e0a0 R14: 0000000001e00874 R15: 0000000000000000
    [  134.842103] Code: 24 fd ff ff e9 cc fe ff ff 48 89 d8 41 8b 8c 24 10 05 00 00 44 8b 45 80 48 c7 c7 08 bd 59 8b 48 89 85 68 ff ff ff e8 b3 c4 7d ff <0f> 0b 48 8b 85 68 ff ff ff e9 e9 fe ff ff 41 8b 8c 24 10 05 00
    [  134.842126] ---[ end trace b7138fc08c83147f ]---
    [  134.842144] general protection fault: 0000 [#1] SMP PTI
    [  134.842145] Modules linked in: ipheth(OE) kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd vmw_balloon intel_rapl_perf joydev input_leds serio_raw vmw_vsock_vmci_transport vsock shpchp i2c_piix4 mac_hid binfmt_misc vmw_vmci parport_pc ppdev lp parport autofs4 vmw_pvscsi vmxnet3 hid_generic usbhid hid vmwgfx ttm drm_kms_helper syscopyarea sysfillrect mptspi mptscsih sysimgblt ahci psmouse fb_sys_fops pata_acpi mptbase libahci e1000 drm scsi_transport_spi
    [  134.842161] CPU: 7 PID: 2629 Comm: python Tainted: G        W  OE    4.15.0-34-generic #37~16.04.1-Ubuntu
    [  134.842162] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
    [  134.842164] RIP: 0010:tcp_close+0x2c6/0x440
    [  134.842165] RSP: 0018:ffffa6630422bde8 EFLAGS: 00010202
    [  134.842167] RAX: 0000000000000000 RBX: ffff99760dee3000 RCX: 0000000180400034
    [  134.842168] RDX: 5c4afd407207a6c4 RSI: ffffe868495bd300 RDI: ffff997616f4f200
    [  134.842169] RBP: ffffa6630422be08 R08: 0000000016f4d401 R09: 0000000180400034
    [  134.842169] R10: ffffa6630422bd98 R11: 0000000000000000 R12: 000000000000600c
    [  134.842170] R13: 0000000000000000 R14: ffff99760dee30c8 R15: ffff9975bd44fe00
    [  134.842171] FS:  00007fe332347700(0000) GS:ffff9976257c0000(0000) knlGS:0000000000000000
    [  134.842173] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  134.842174] CR2: 0000000001e41000 CR3: 000000020e9b4006 CR4: 00000000003606e0
    [  134.842177] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  134.842178] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  134.842179] Call Trace:
    [  134.842181]  inet_release+0x42/0x70
    [  134.842183]  __sock_release+0x42/0xb0
    [  134.842184]  sock_close+0x15/0x20
    [  134.842187]  __fput+0xea/0x220
    [  134.842189]  ____fput+0xe/0x10
    [  134.842191]  task_work_run+0x8a/0xb0
    [  134.842193]  exit_to_usermode_loop+0xc4/0xd0
    [  134.842195]  do_syscall_64+0xf4/0x130
    [  134.842197]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    [  134.842197] RIP: 0033:0x7fe331f5a560
    [  134.842198] RSP: 002b:00007ffe8da982e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
    [  134.842200] RAX: 0000000000000000 RBX: 00007fe32f642c70 RCX: 00007fe331f5a560
    [  134.842201] RDX: 00000000008f5320 RSI: 0000000001cd4b50 RDI: 0000000000000003
    [  134.842202] RBP: 00007fe32f6500f8 R08: 000000000000003c R09: 00000000009343c0
    [  134.842203] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe32f6500d0
    [  134.842204] R13: 00000000008f5320 R14: 00000000008f5320 R15: 0000000001cd4770
    [  134.842205] Code: c8 00 00 00 45 31 e4 49 39 fe 75 4d eb 50 83 ab d8 00 00 00 01 48 8b 17 48 8b 47 08 48 c7 07 00 00 00 00 48 c7 47 08 00 00 00 00 <48> 89 42 08 48 89 10 0f b6 57 34 8b 47 2c 2b 47 28 83 e2 01 80
    [  134.842226] RIP: tcp_close+0x2c6/0x440 RSP: ffffa6630422bde8
    [  134.842227] ---[ end trace b7138fc08c831480 ]---
    
    The proposed patch eliminates a potential racing condition.
    Before, usb_submit_urb was called and _after_ that, the skb was attached
    (dev->tx_skb). So, on a callback it was possible, however unlikely that the
    skb was freed before it was set. That way (because dev->tx_skb was not set
    to NULL after it was freed), it could happen that a skb from a earlier
    transmission was freed a second time (and the skb we should have freed did
    not get freed at all)
    
    Now we free the skb directly in ipheth_tx(). It is not passed to the
    callback anymore, eliminating the posibility of a double free of the same
    skb. Depending on the retval of usb_submit_urb() we use dev_kfree_skb_any()
    respectively dev_consume_skb_any() to free the skb.
    
    Signed-off-by: Oliver Zweigle <Oliver.Zweigle@faro.com>
    Signed-off-by: Bernd Eckstein <3ernd.Eckstein@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb09c6dbe4bb799ba153c5d729e2d26098a3b410
Author: Julian Wiedmann <jwi@linux.ibm.com>
Date:   Wed Nov 28 16:20:50 2018 +0100

    s390/qeth: fix length check in SNMP processing
    
    [ Upstream commit 9a764c1e59684c0358e16ccaafd870629f2cfe67 ]
    
    The response for a SNMP request can consist of multiple parts, which
    the cmd callback stages into a kernel buffer until all parts have been
    received. If the callback detects that the staging buffer provides
    insufficient space, it bails out with error.
    This processing is buggy for the first part of the response - while it
    initially checks for a length of 'data_len', it later copies an
    additional amount of 'offsetof(struct qeth_snmp_cmd, data)' bytes.
    
    Fix the calculation of 'data_len' for the first part of the response.
    This also nicely cleans up the memcpy code.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
    Reviewed-by: Ursula Braun <ubraun@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47897682fe041a5898cfd30a5f24d3173e856d5a
Author: Pan Bian <bianpan2016@163.com>
Date:   Wed Nov 28 14:53:19 2018 +0800

    rapidio/rionet: do not free skb before reading its length
    
    [ Upstream commit cfc435198f53a6fa1f656d98466b24967ff457d0 ]
    
    skb is freed via dev_kfree_skb_any, however, skb->len is read then. This
    may result in a use-after-free bug.
    
    Fixes: e6161d64263 ("rapidio/rionet: rework driver initialization and removal")
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67f6fba765ef8cb19089d476e3c367212a2fbdfd
Author: Willem de Bruijn <willemb@google.com>
Date:   Tue Nov 20 13:00:18 2018 -0500

    packet: copy user buffers before orphan or clone
    
    [ Upstream commit 5cd8d46ea1562be80063f53c7c6a5f40224de623 ]
    
    tpacket_snd sends packets with user pages linked into skb frags. It
    notifies that pages can be reused when the skb is released by setting
    skb->destructor to tpacket_destruct_skb.
    
    This can cause data corruption if the skb is orphaned (e.g., on
    transmit through veth) or cloned (e.g., on mirror to another psock).
    
    Create a kernel-private copy of data in these cases, same as tun/tap
    zerocopy transmission. Reuse that infrastructure: mark the skb as
    SKBTX_ZEROCOPY_FRAG, which will trigger copy in skb_orphan_frags(_rx).
    
    Unlike other zerocopy packets, do not set shinfo destructor_arg to
    struct ubuf_info. tpacket_destruct_skb already uses that ptr to notify
    when the original skb is released and a timestamp is recorded. Do not
    change this timestamp behavior. The ubuf_info->callback is not needed
    anyway, as no zerocopy notification is expected.
    
    Mark destructor_arg as not-a-uarg by setting the lower bit to 1. The
    resulting value is not a valid ubuf_info pointer, nor a valid
    tpacket_snd frame address. Add skb_zcopy_.._nouarg helpers for this.
    
    The fix relies on features introduced in commit 52267790ef52 ("sock:
    add MSG_ZEROCOPY"), so can be backported as is only to 4.14.
    
    Tested with from `./in_netns.sh ./txring_overwrite` from
    http://github.com/wdebruij/kerneltools/tests
    
    Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap")
    Reported-by: Anand H. Krishnan <anandhkrishnan@gmail.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42412faf1a9356e6967c5c5fc530fe0ab5e32e9f
Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date:   Fri Nov 23 18:28:01 2018 +0100

    net: thunderx: set tso_hdrs pointer to NULL in nicvf_free_snd_queue
    
    [ Upstream commit ef2a7cf1d8831535b8991459567b385661eb4a36 ]
    
    Reset snd_queue tso_hdrs pointer to NULL in nicvf_free_snd_queue routine
    since it is used to check if tso dma descriptor queue has been previously
    allocated. The issue can be triggered with the following reproducer:
    
    $ip link set dev enP2p1s0v0 xdpdrv obj xdp_dummy.o
    $ip link set dev enP2p1s0v0 xdpdrv off
    
    [  341.467649] WARNING: CPU: 74 PID: 2158 at mm/vmalloc.c:1511 __vunmap+0x98/0xe0
    [  341.515010] Hardware name: GIGABYTE H270-T70/MT70-HD0, BIOS T49 02/02/2018
    [  341.521874] pstate: 60400005 (nZCv daif +PAN -UAO)
    [  341.526654] pc : __vunmap+0x98/0xe0
    [  341.530132] lr : __vunmap+0x98/0xe0
    [  341.533609] sp : ffff00001c5db860
    [  341.536913] x29: ffff00001c5db860 x28: 0000000000020000
    [  341.542214] x27: ffff810feb5090b0 x26: ffff000017e57000
    [  341.547515] x25: 0000000000000000 x24: 00000000fbd00000
    [  341.552816] x23: 0000000000000000 x22: ffff810feb5090b0
    [  341.558117] x21: 0000000000000000 x20: 0000000000000000
    [  341.563418] x19: ffff000017e57000 x18: 0000000000000000
    [  341.568719] x17: 0000000000000000 x16: 0000000000000000
    [  341.574020] x15: 0000000000000010 x14: ffffffffffffffff
    [  341.579321] x13: ffff00008985eb27 x12: ffff00000985eb2f
    [  341.584622] x11: ffff0000096b3000 x10: ffff00001c5db510
    [  341.589923] x9 : 00000000ffffffd0 x8 : ffff0000086868e8
    [  341.595224] x7 : 3430303030303030 x6 : 00000000000006ef
    [  341.600525] x5 : 00000000003fffff x4 : 0000000000000000
    [  341.605825] x3 : 0000000000000000 x2 : ffffffffffffffff
    [  341.611126] x1 : ffff0000096b3728 x0 : 0000000000000038
    [  341.616428] Call trace:
    [  341.618866]  __vunmap+0x98/0xe0
    [  341.621997]  vunmap+0x3c/0x50
    [  341.624961]  arch_dma_free+0x68/0xa0
    [  341.628534]  dma_direct_free+0x50/0x80
    [  341.632285]  nicvf_free_resources+0x160/0x2d8 [nicvf]
    [  341.637327]  nicvf_config_data_transfer+0x174/0x5e8 [nicvf]
    [  341.642890]  nicvf_stop+0x298/0x340 [nicvf]
    [  341.647066]  __dev_close_many+0x9c/0x108
    [  341.650977]  dev_close_many+0xa4/0x158
    [  341.654720]  rollback_registered_many+0x140/0x530
    [  341.659414]  rollback_registered+0x54/0x80
    [  341.663499]  unregister_netdevice_queue+0x9c/0xe8
    [  341.668192]  unregister_netdev+0x28/0x38
    [  341.672106]  nicvf_remove+0xa4/0xa8 [nicvf]
    [  341.676280]  nicvf_shutdown+0x20/0x30 [nicvf]
    [  341.680630]  pci_device_shutdown+0x44/0x88
    [  341.684720]  device_shutdown+0x144/0x250
    [  341.688640]  kernel_restart_prepare+0x44/0x50
    [  341.692986]  kernel_restart+0x20/0x68
    [  341.696638]  __se_sys_reboot+0x210/0x238
    [  341.700550]  __arm64_sys_reboot+0x24/0x30
    [  341.704555]  el0_svc_handler+0x94/0x110
    [  341.708382]  el0_svc+0x8/0xc
    [  341.711252] ---[ end trace 3f4019c8439959c9 ]---
    [  341.715874] page:ffff7e0003ef4000 count:0 mapcount:0 mapping:0000000000000000 index:0x4
    [  341.723872] flags: 0x1fffe000000000()
    [  341.727527] raw: 001fffe000000000 ffff7e0003f1a008 ffff7e0003ef4048 0000000000000000
    [  341.735263] raw: 0000000000000004 0000000000000000 00000000ffffffff 0000000000000000
    [  341.742994] page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
    
    where xdp_dummy.c is a simple bpf program that forwards the incoming
    frames to the network stack (available here:
    https://github.com/altoor/xdp_walkthrough_examples/blob/master/sample_1/xdp_dummy.c)
    
    Fixes: 05c773f52b96 ("net: thunderx: Add basic XDP support")
    Fixes: 4863dea3fab0 ("net: Adding support for Cavium ThunderX network controller")
    Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0435cabc0d6a0f0ebb60589a9ad28d1a3aecd748
Author: Jason Wang <jasowang@redhat.com>
Date:   Thu Nov 22 14:36:31 2018 +0800

    virtio-net: fail XDP set if guest csum is negotiated
    
    [ Upstream commit 18ba58e1c234ea1a2d9835ac8c1735d965ce4640 ]
    
    We don't support partial csumed packet since its metadata will be lost
    or incorrect during XDP processing. So fail the XDP set if guest_csum
    feature is negotiated.
    
    Fixes: f600b6905015 ("virtio_net: Add XDP support")
    Reported-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Cc: Jesper Dangaard Brouer <brouer@redhat.com>
    Cc: Pavel Popa <pashinho1990@gmail.com>
    Cc: David Ahern <dsahern@gmail.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5cfda6c5d04a04e9ec9834925e590f7e921c57f
Author: Jason Wang <jasowang@redhat.com>
Date:   Thu Nov 22 14:36:30 2018 +0800

    virtio-net: disable guest csum during XDP set
    
    [ Upstream commit e59ff2c49ae16e1d179de679aca81405829aee6c ]
    
    We don't disable VIRTIO_NET_F_GUEST_CSUM if XDP was set. This means we
    can receive partial csumed packets with metadata kept in the
    vnet_hdr. This may have several side effects:
    
    - It could be overridden by header adjustment, thus is might be not
      correct after XDP processing.
    - There's no way to pass such metadata information through
      XDP_REDIRECT to another driver.
    - XDP does not support checksum offload right now.
    
    So simply disable guest csum if possible in this the case of XDP.
    
    Fixes: 3f93522ffab2d ("virtio-net: switch off offloads on demand if possible on XDP set")
    Reported-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Cc: Jesper Dangaard Brouer <brouer@redhat.com>
    Cc: Pavel Popa <pashinho1990@gmail.com>
    Cc: David Ahern <dsahern@gmail.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44e4f3644934b65c91bc05245a9447dde2c7af40
Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date:   Wed Nov 21 16:32:10 2018 +0100

    net: thunderx: set xdp_prog to NULL if bpf_prog_add fails
    
    [ Upstream commit 6d0f60b0f8588fd4380ea5df9601e12fddd55ce2 ]
    
    Set xdp_prog pointer to NULL if bpf_prog_add fails since that routine
    reports the error code instead of NULL in case of failure and xdp_prog
    pointer value is used in the driver to verify if XDP is currently
    enabled.
    Moreover report the error code to userspace if nicvf_xdp_setup fails
    
    Fixes: 05c773f52b96 ("net: thunderx: Add basic XDP support")
    Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a8a411c927716fad4004a6953a5b2cf988eb2df
Author: Petr Machata <petrm@mellanox.com>
Date:   Tue Nov 20 11:39:56 2018 +0000

    net: skb_scrub_packet(): Scrub offload_fwd_mark
    
    [ Upstream commit b5dd186d10ba59e6b5ba60e42b3b083df56df6f3 ]
    
    When a packet is trapped and the corresponding SKB marked as
    already-forwarded, it retains this marking even after it is forwarded
    across veth links into another bridge. There, since it ingresses the
    bridge over veth, which doesn't have offload_fwd_mark, it triggers a
    warning in nbp_switchdev_frame_mark().
    
    Then nbp_switchdev_allowed_egress() decides not to allow egress from
    this bridge through another veth, because the SKB is already marked, and
    the mark (of 0) of course matches. Thus the packet is incorrectly
    blocked.
    
    Solve by resetting offload_fwd_mark() in skb_scrub_packet(). That
    function is called from tunnels and also from veth, and thus catches the
    cases where traffic is forwarded between bridges and transformed in a
    way that invalidates the marking.
    
    Fixes: 6bc506b4fb06 ("bridge: switchdev: Add forward mark support for stacked devices")
    Fixes: abf4bb6b63d0 ("skbuff: Add the offload_mr_fwd_mark field")
    Signed-off-by: Petr Machata <petrm@mellanox.com>
    Suggested-by: Ido Schimmel <idosch@mellanox.com>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04d269610ea35656fe4d9609f5a5fa043daa866e
Author: Sasha Levin <sashal@kernel.org>
Date:   Sun Dec 2 10:03:24 2018 -0500

    Revert "wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()"
    
    This reverts commit e87efc44dd36ba3db59847c418354711ebad779b which was
    upstream commit 4ec7cece87b3ed21ffcd407c62fb2f151a366bc1.
    
    From Dietmar May's report on the stable mailing list
    (https://www.spinics.net/lists/stable/msg272201.html):
    
    > I've run into some problems which appear due to (a) recent patch(es) on
    > the wlcore wifi driver.
    >
    > 4.4.160 - commit 3fdd34643ffc378b5924941fad40352c04610294
    > 4.9.131 - commit afeeecc764436f31d4447575bb9007732333818c
    >
    > Earlier versions (4.9.130 and 4.4.159 - tested back to 4.4.49) do not
    > exhibit this problem. It is still present in 4.9.141.
    >
    > master as of 4.20.0-rc4 does not exhibit this problem.
    >
    > Basically, during client association when in AP mode (running hostapd),
    > handshake may or may not complete following a noticeable delay. If
    > successful, then the driver fails consistently in warn_slowpath_null
    > during disassociation. If unsuccessful, the wifi client attempts multiple
    > times, sometimes failing repeatedly. I've had clients unable to connect
    > for 3-5 minutes during testing, with the syslog filled with dozens of
    > backtraces. syslog details are below.
    >
    > I'm working on an embedded device with a TI 3352 ARM processor and a
    > murata wl1271 module in sdio mode. We're running a fully patched ubuntu
    > 18.04 ARM build, with a kernel built from kernel.org's stable/linux repo <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.9.y&id=afeeecc764436f31d4447575bb9007732333818c>.
    > Relevant parts of the kernel config are included below.
    >
    > The commit message states:
    >
    > > /I've only seen this few times with the runtime PM patches enabled so
    > > this one is probably not needed before that. This seems to work
    > > currently based on the current PM implementation timer. Let's apply
    > > this separately though in case others are hitting this issue./
    > We're not doing anything explicit with power management. The device is an
    > IoT edge gateway with battery backup, normally running on wall power. The
    > battery is currently used solely to shut down the system cleanly to avoid
    > filesystem corruption.
    >
    > The device tree is configured to keep power in suspend; but the device
    > should never suspend, so in our case, there is no need to call
    > wl1271_ps_elp_wakeup() or wl1271_ps_elp_sleep(), as occurs in the patch.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb7ccb9924bb3596f211badf0d2becf131a979cd
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Tue Apr 17 19:10:15 2018 -0700

    xfs: don't fail when converting shortform attr to long form during ATTR_REPLACE
    
    commit 7b38460dc8e4eafba06c78f8e37099d3b34d473c upstream.
    
    Kanda Motohiro reported that expanding a tiny xattr into a large xattr
    fails on XFS because we remove the tiny xattr from a shortform fork and
    then try to re-add it after converting the fork to extents format having
    not removed the ATTR_REPLACE flag.  This fails because the attr is no
    longer present, causing a fs shutdown.
    
    This is derived from the patch in his bug report, but we really
    shouldn't ignore a nonzero retval from the remove call.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199119
    Reported-by: kanda.motohiro@gmail.com
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30130700acfad8a705c109325379f5bbe21b3ccc
Author: Chao Yu <yuchao0@huawei.com>
Date:   Wed Aug 1 19:16:11 2018 +0800

    f2fs: fix to do sanity check with cp_pack_start_sum
    
    commit e494c2f995d6181d6e29c4927d68e0f295ecf75b upstream.
    
    After fuzzing, cp_pack_start_sum could be corrupted, so current log's
    summary info should be wrong due to loading incorrect summary block.
    Then, if segment's type in current log is exceeded NR_CURSEG_TYPE, it
    can lead accessing invalid dirty_i->dirty_segmap bitmap finally.
    
    Add sanity check for cp_pack_start_sum to fix this issue.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=200419
    
    - Reproduce
    
    - Kernel message (f2fs-dev w/ KASAN)
    [ 3117.578432] F2FS-fs (loop0): Invalid log blocks per segment (8)
    
    [ 3117.578445] F2FS-fs (loop0): Can't find valid F2FS filesystem in 2th superblock
    [ 3117.581364] F2FS-fs (loop0): invalid crc_offset: 30716
    [ 3117.583564] WARNING: CPU: 1 PID: 1225 at fs/f2fs/checkpoint.c:90 __get_meta_page+0x448/0x4b0
    [ 3117.583570] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer joydev input_leds serio_raw snd soundcore mac_hid i2c_piix4 ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi btrfs zstd_decompress zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear 8139too qxl ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel psmouse aes_x86_64 8139cp crypto_simd cryptd mii glue_helper pata_acpi floppy
    [ 3117.584014] CPU: 1 PID: 1225 Comm: mount Not tainted 4.17.0+ #1
    [ 3117.584017] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [ 3117.584022] RIP: 0010:__get_meta_page+0x448/0x4b0
    [ 3117.584023] Code: 00 49 8d bc 24 84 00 00 00 e8 74 54 da ff 41 83 8c 24 84 00 00 00 08 4c 89 f6 4c 89 ef e8 c0 d9 95 00 48 89 ef e8 18 e3 00 00 <0f> 0b f0 80 4d 48 04 e9 0f fe ff ff 0f 0b 48 89 c7 48 89 04 24 e8
    [ 3117.584072] RSP: 0018:ffff88018eb678c0 EFLAGS: 00010286
    [ 3117.584082] RAX: ffff88018f0a6a78 RBX: ffffea0007a46600 RCX: ffffffff9314d1b2
    [ 3117.584085] RDX: ffffffff00000001 RSI: 0000000000000000 RDI: ffff88018f0a6a98
    [ 3117.584087] RBP: ffff88018ebe9980 R08: 0000000000000002 R09: 0000000000000001
    [ 3117.584090] R10: 0000000000000001 R11: ffffed00326e4450 R12: ffff880193722200
    [ 3117.584092] R13: ffff88018ebe9afc R14: 0000000000000206 R15: ffff88018eb67900
    [ 3117.584096] FS:  00007f5694636840(0000) GS:ffff8801f3b00000(0000) knlGS:0000000000000000
    [ 3117.584098] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 3117.584101] CR2: 00000000016f21b8 CR3: 0000000191c22000 CR4: 00000000000006e0
    [ 3117.584112] Call Trace:
    [ 3117.584121]  ? f2fs_set_meta_page_dirty+0x150/0x150
    [ 3117.584127]  ? f2fs_build_segment_manager+0xbf9/0x3190
    [ 3117.584133]  ? f2fs_npages_for_summary_flush+0x75/0x120
    [ 3117.584145]  f2fs_build_segment_manager+0xda8/0x3190
    [ 3117.584151]  ? f2fs_get_valid_checkpoint+0x298/0xa00
    [ 3117.584156]  ? f2fs_flush_sit_entries+0x10e0/0x10e0
    [ 3117.584184]  ? map_id_range_down+0x17c/0x1b0
    [ 3117.584188]  ? __put_user_ns+0x30/0x30
    [ 3117.584206]  ? find_next_bit+0x53/0x90
    [ 3117.584237]  ? cpumask_next+0x16/0x20
    [ 3117.584249]  f2fs_fill_super+0x1948/0x2b40
    [ 3117.584258]  ? f2fs_commit_super+0x1a0/0x1a0
    [ 3117.584279]  ? sget_userns+0x65e/0x690
    [ 3117.584296]  ? set_blocksize+0x88/0x130
    [ 3117.584302]  ? f2fs_commit_super+0x1a0/0x1a0
    [ 3117.584305]  mount_bdev+0x1c0/0x200
    [ 3117.584310]  mount_fs+0x5c/0x190
    [ 3117.584320]  vfs_kern_mount+0x64/0x190
    [ 3117.584330]  do_mount+0x2e4/0x1450
    [ 3117.584343]  ? lockref_put_return+0x130/0x130
    [ 3117.584347]  ? copy_mount_string+0x20/0x20
    [ 3117.584357]  ? kasan_unpoison_shadow+0x31/0x40
    [ 3117.584362]  ? kasan_kmalloc+0xa6/0xd0
    [ 3117.584373]  ? memcg_kmem_put_cache+0x16/0x90
    [ 3117.584377]  ? __kmalloc_track_caller+0x196/0x210
    [ 3117.584383]  ? _copy_from_user+0x61/0x90
    [ 3117.584396]  ? memdup_user+0x3e/0x60
    [ 3117.584401]  ksys_mount+0x7e/0xd0
    [ 3117.584405]  __x64_sys_mount+0x62/0x70
    [ 3117.584427]  do_syscall_64+0x73/0x160
    [ 3117.584440]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 3117.584455] RIP: 0033:0x7f5693f14b9a
    [ 3117.584456] Code: 48 8b 0d 01 c3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ce c2 2b 00 f7 d8 64 89 01 48
    [ 3117.584505] RSP: 002b:00007fff27346488 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
    [ 3117.584510] RAX: ffffffffffffffda RBX: 00000000016e2030 RCX: 00007f5693f14b9a
    [ 3117.584512] RDX: 00000000016e2210 RSI: 00000000016e3f30 RDI: 00000000016ee040
    [ 3117.584514] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000013
    [ 3117.584516] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 00000000016ee040
    [ 3117.584519] R13: 00000000016e2210 R14: 0000000000000000 R15: 0000000000000003
    [ 3117.584523] ---[ end trace a8e0d899985faf31 ]---
    [ 3117.685663] F2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=2, run fsck to fix.
    [ 3117.685673] F2FS-fs (loop0): recover_data: ino = 2 (i_size: recover) recovered = 1, err = 0
    [ 3117.685707] ==================================================================
    [ 3117.685955] BUG: KASAN: slab-out-of-bounds in __remove_dirty_segment+0xdd/0x1e0
    [ 3117.686175] Read of size 8 at addr ffff88018f0a63d0 by task mount/1225
    
    [ 3117.686477] CPU: 0 PID: 1225 Comm: mount Tainted: G        W         4.17.0+ #1
    [ 3117.686481] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [ 3117.686483] Call Trace:
    [ 3117.686494]  dump_stack+0x71/0xab
    [ 3117.686512]  print_address_description+0x6b/0x290
    [ 3117.686517]  kasan_report+0x28e/0x390
    [ 3117.686522]  ? __remove_dirty_segment+0xdd/0x1e0
    [ 3117.686527]  __remove_dirty_segment+0xdd/0x1e0
    [ 3117.686532]  locate_dirty_segment+0x189/0x190
    [ 3117.686538]  f2fs_allocate_new_segments+0xa9/0xe0
    [ 3117.686543]  recover_data+0x703/0x2c20
    [ 3117.686547]  ? f2fs_recover_fsync_data+0x48f/0xd50
    [ 3117.686553]  ? ksys_mount+0x7e/0xd0
    [ 3117.686564]  ? policy_nodemask+0x1a/0x90
    [ 3117.686567]  ? policy_node+0x56/0x70
    [ 3117.686571]  ? add_fsync_inode+0xf0/0xf0
    [ 3117.686592]  ? blk_finish_plug+0x44/0x60
    [ 3117.686597]  ? f2fs_ra_meta_pages+0x38b/0x5e0
    [ 3117.686602]  ? find_inode_fast+0xac/0xc0
    [ 3117.686606]  ? f2fs_is_valid_blkaddr+0x320/0x320
    [ 3117.686618]  ? __radix_tree_lookup+0x150/0x150
    [ 3117.686633]  ? dqget+0x670/0x670
    [ 3117.686648]  ? pagecache_get_page+0x29/0x410
    [ 3117.686656]  ? kmem_cache_alloc+0x176/0x1e0
    [ 3117.686660]  ? f2fs_is_valid_blkaddr+0x11d/0x320
    [ 3117.686664]  f2fs_recover_fsync_data+0xc23/0xd50
    [ 3117.686670]  ? f2fs_space_for_roll_forward+0x60/0x60
    [ 3117.686674]  ? rb_insert_color+0x323/0x3d0
    [ 3117.686678]  ? f2fs_recover_orphan_inodes+0xa5/0x700
    [ 3117.686683]  ? proc_register+0x153/0x1d0
    [ 3117.686686]  ? f2fs_remove_orphan_inode+0x10/0x10
    [ 3117.686695]  ? f2fs_attr_store+0x50/0x50
    [ 3117.686700]  ? proc_create_single_data+0x52/0x60
    [ 3117.686707]  f2fs_fill_super+0x1d06/0x2b40
    [ 3117.686728]  ? f2fs_commit_super+0x1a0/0x1a0
    [ 3117.686735]  ? sget_userns+0x65e/0x690
    [ 3117.686740]  ? set_blocksize+0x88/0x130
    [ 3117.686745]  ? f2fs_commit_super+0x1a0/0x1a0
    [ 3117.686748]  mount_bdev+0x1c0/0x200
    [ 3117.686753]  mount_fs+0x5c/0x190
    [ 3117.686758]  vfs_kern_mount+0x64/0x190
    [ 3117.686762]  do_mount+0x2e4/0x1450
    [ 3117.686769]  ? lockref_put_return+0x130/0x130
    [ 3117.686773]  ? copy_mount_string+0x20/0x20
    [ 3117.686777]  ? kasan_unpoison_shadow+0x31/0x40
    [ 3117.686780]  ? kasan_kmalloc+0xa6/0xd0
    [ 3117.686786]  ? memcg_kmem_put_cache+0x16/0x90
    [ 3117.686790]  ? __kmalloc_track_caller+0x196/0x210
    [ 3117.686795]  ? _copy_from_user+0x61/0x90
    [ 3117.686801]  ? memdup_user+0x3e/0x60
    [ 3117.686804]  ksys_mount+0x7e/0xd0
    [ 3117.686809]  __x64_sys_mount+0x62/0x70
    [ 3117.686816]  do_syscall_64+0x73/0x160
    [ 3117.686824]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 3117.686829] RIP: 0033:0x7f5693f14b9a
    [ 3117.686830] Code: 48 8b 0d 01 c3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ce c2 2b 00 f7 d8 64 89 01 48
    [ 3117.686887] RSP: 002b:00007fff27346488 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
    [ 3117.686892] RAX: ffffffffffffffda RBX: 00000000016e2030 RCX: 00007f5693f14b9a
    [ 3117.686894] RDX: 00000000016e2210 RSI: 00000000016e3f30 RDI: 00000000016ee040
    [ 3117.686896] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000013
    [ 3117.686899] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 00000000016ee040
    [ 3117.686901] R13: 00000000016e2210 R14: 0000000000000000 R15: 0000000000000003
    
    [ 3117.687005] Allocated by task 1225:
    [ 3117.687152]  kasan_kmalloc+0xa6/0xd0
    [ 3117.687157]  kmem_cache_alloc_trace+0xfd/0x200
    [ 3117.687161]  f2fs_build_segment_manager+0x2d09/0x3190
    [ 3117.687165]  f2fs_fill_super+0x1948/0x2b40
    [ 3117.687168]  mount_bdev+0x1c0/0x200
    [ 3117.687171]  mount_fs+0x5c/0x190
    [ 3117.687174]  vfs_kern_mount+0x64/0x190
    [ 3117.687177]  do_mount+0x2e4/0x1450
    [ 3117.687180]  ksys_mount+0x7e/0xd0
    [ 3117.687182]  __x64_sys_mount+0x62/0x70
    [ 3117.687186]  do_syscall_64+0x73/0x160
    [ 3117.687190]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    [ 3117.687285] Freed by task 19:
    [ 3117.687412]  __kasan_slab_free+0x137/0x190
    [ 3117.687416]  kfree+0x8b/0x1b0
    [ 3117.687460]  ttm_bo_man_put_node+0x61/0x80 [ttm]
    [ 3117.687476]  ttm_bo_cleanup_refs+0x15f/0x250 [ttm]
    [ 3117.687492]  ttm_bo_delayed_delete+0x2f0/0x300 [ttm]
    [ 3117.687507]  ttm_bo_delayed_workqueue+0x17/0x50 [ttm]
    [ 3117.687528]  process_one_work+0x2f9/0x740
    [ 3117.687531]  worker_thread+0x78/0x6b0
    [ 3117.687541]  kthread+0x177/0x1c0
    [ 3117.687545]  ret_from_fork+0x35/0x40
    
    [ 3117.687638] The buggy address belongs to the object at ffff88018f0a6300
                    which belongs to the cache kmalloc-192 of size 192
    [ 3117.688014] The buggy address is located 16 bytes to the right of
                    192-byte region [ffff88018f0a6300, ffff88018f0a63c0)
    [ 3117.688382] The buggy address belongs to the page:
    [ 3117.688554] page:ffffea00063c2980 count:1 mapcount:0 mapping:ffff8801f3403180 index:0x0
    [ 3117.688788] flags: 0x17fff8000000100(slab)
    [ 3117.688944] raw: 017fff8000000100 ffffea00063c2840 0000000e0000000e ffff8801f3403180
    [ 3117.689166] raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
    [ 3117.689386] page dumped because: kasan: bad access detected
    
    [ 3117.689653] Memory state around the buggy address:
    [ 3117.689816]  ffff88018f0a6280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [ 3117.690027]  ffff88018f0a6300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [ 3117.690239] >ffff88018f0a6380: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [ 3117.690448]                                                  ^
    [ 3117.690644]  ffff88018f0a6400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [ 3117.690868]  ffff88018f0a6480: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [ 3117.691077] ==================================================================
    [ 3117.691290] Disabling lock debugging due to kernel taint
    [ 3117.693893] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    [ 3117.694120] PGD 80000001f01bc067 P4D 80000001f01bc067 PUD 1d9638067 PMD 0
    [ 3117.694338] Oops: 0002 [#1] SMP KASAN PTI
    [ 3117.694490] CPU: 1 PID: 1225 Comm: mount Tainted: G    B   W         4.17.0+ #1
    [ 3117.694703] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [ 3117.695073] RIP: 0010:__remove_dirty_segment+0xe2/0x1e0
    [ 3117.695246] Code: c4 48 89 c7 e8 cf bb d7 ff 45 0f b6 24 24 41 83 e4 3f 44 88 64 24 07 41 83 e4 3f 4a 8d 7c e3 08 e8 b3 bc d7 ff 4a 8b 4c e3 08 <f0> 4c 0f b3 29 0f 82 94 00 00 00 48 8d bd 20 04 00 00 e8 97 bb d7
    [ 3117.695793] RSP: 0018:ffff88018eb67638 EFLAGS: 00010292
    [ 3117.695969] RAX: 0000000000000000 RBX: ffff88018f0a6300 RCX: 0000000000000000
    [ 3117.696182] RDX: 0000000000000000 RSI: 0000000000000297 RDI: 0000000000000297
    [ 3117.696391] RBP: ffff88018ebe9980 R08: ffffed003e743ebb R09: ffffed003e743ebb
    [ 3117.696604] R10: 0000000000000001 R11: ffffed003e743eba R12: 0000000000000019
    [ 3117.696813] R13: 0000000000000014 R14: 0000000000000320 R15: ffff88018ebe99e0
    [ 3117.697032] FS:  00007f5694636840(0000) GS:ffff8801f3b00000(0000) knlGS:0000000000000000
    [ 3117.697280] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 3117.702357] CR2: 00007fe89bb1a000 CR3: 0000000191c22000 CR4: 00000000000006e0
    [ 3117.707235] Call Trace:
    [ 3117.712077]  locate_dirty_segment+0x189/0x190
    [ 3117.716891]  f2fs_allocate_new_segments+0xa9/0xe0
    [ 3117.721617]  recover_data+0x703/0x2c20
    [ 3117.726316]  ? f2fs_recover_fsync_data+0x48f/0xd50
    [ 3117.730957]  ? ksys_mount+0x7e/0xd0
    [ 3117.735573]  ? policy_nodemask+0x1a/0x90
    [ 3117.740198]  ? policy_node+0x56/0x70
    [ 3117.744829]  ? add_fsync_inode+0xf0/0xf0
    [ 3117.749487]  ? blk_finish_plug+0x44/0x60
    [ 3117.754152]  ? f2fs_ra_meta_pages+0x38b/0x5e0
    [ 3117.758831]  ? find_inode_fast+0xac/0xc0
    [ 3117.763448]  ? f2fs_is_valid_blkaddr+0x320/0x320
    [ 3117.768046]  ? __radix_tree_lookup+0x150/0x150
    [ 3117.772603]  ? dqget+0x670/0x670
    [ 3117.777159]  ? pagecache_get_page+0x29/0x410
    [ 3117.781648]  ? kmem_cache_alloc+0x176/0x1e0
    [ 3117.786067]  ? f2fs_is_valid_blkaddr+0x11d/0x320
    [ 3117.790476]  f2fs_recover_fsync_data+0xc23/0xd50
    [ 3117.794790]  ? f2fs_space_for_roll_forward+0x60/0x60
    [ 3117.799086]  ? rb_insert_color+0x323/0x3d0
    [ 3117.803304]  ? f2fs_recover_orphan_inodes+0xa5/0x700
    [ 3117.807563]  ? proc_register+0x153/0x1d0
    [ 3117.811766]  ? f2fs_remove_orphan_inode+0x10/0x10
    [ 3117.815947]  ? f2fs_attr_store+0x50/0x50
    [ 3117.820087]  ? proc_create_single_data+0x52/0x60
    [ 3117.824262]  f2fs_fill_super+0x1d06/0x2b40
    [ 3117.828367]  ? f2fs_commit_super+0x1a0/0x1a0
    [ 3117.832432]  ? sget_userns+0x65e/0x690
    [ 3117.836500]  ? set_blocksize+0x88/0x130
    [ 3117.840501]  ? f2fs_commit_super+0x1a0/0x1a0
    [ 3117.844420]  mount_bdev+0x1c0/0x200
    [ 3117.848275]  mount_fs+0x5c/0x190
    [ 3117.852053]  vfs_kern_mount+0x64/0x190
    [ 3117.855810]  do_mount+0x2e4/0x1450
    [ 3117.859441]  ? lockref_put_return+0x130/0x130
    [ 3117.862996]  ? copy_mount_string+0x20/0x20
    [ 3117.866417]  ? kasan_unpoison_shadow+0x31/0x40
    [ 3117.869719]  ? kasan_kmalloc+0xa6/0xd0
    [ 3117.872948]  ? memcg_kmem_put_cache+0x16/0x90
    [ 3117.876121]  ? __kmalloc_track_caller+0x196/0x210
    [ 3117.879333]  ? _copy_from_user+0x61/0x90
    [ 3117.882467]  ? memdup_user+0x3e/0x60
    [ 3117.885604]  ksys_mount+0x7e/0xd0
    [ 3117.888700]  __x64_sys_mount+0x62/0x70
    [ 3117.891742]  do_syscall_64+0x73/0x160
    [ 3117.894692]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 3117.897669] RIP: 0033:0x7f5693f14b9a
    [ 3117.900563] Code: 48 8b 0d 01 c3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ce c2 2b 00 f7 d8 64 89 01 48
    [ 3117.906922] RSP: 002b:00007fff27346488 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
    [ 3117.910159] RAX: ffffffffffffffda RBX: 00000000016e2030 RCX: 00007f5693f14b9a
    [ 3117.913469] RDX: 00000000016e2210 RSI: 00000000016e3f30 RDI: 00000000016ee040
    [ 3117.916764] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000013
    [ 3117.920071] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 00000000016ee040
    [ 3117.923393] R13: 00000000016e2210 R14: 0000000000000000 R15: 0000000000000003
    [ 3117.926680] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer joydev input_leds serio_raw snd soundcore mac_hid i2c_piix4 ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi btrfs zstd_decompress zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear 8139too qxl ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel psmouse aes_x86_64 8139cp crypto_simd cryptd mii glue_helper pata_acpi floppy
    [ 3117.949979] CR2: 0000000000000000
    [ 3117.954283] ---[ end trace a8e0d899985faf32 ]---
    [ 3117.958575] RIP: 0010:__remove_dirty_segment+0xe2/0x1e0
    [ 3117.962810] Code: c4 48 89 c7 e8 cf bb d7 ff 45 0f b6 24 24 41 83 e4 3f 44 88 64 24 07 41 83 e4 3f 4a 8d 7c e3 08 e8 b3 bc d7 ff 4a 8b 4c e3 08 <f0> 4c 0f b3 29 0f 82 94 00 00 00 48 8d bd 20 04 00 00 e8 97 bb d7
    [ 3117.971789] RSP: 0018:ffff88018eb67638 EFLAGS: 00010292
    [ 3117.976333] RAX: 0000000000000000 RBX: ffff88018f0a6300 RCX: 0000000000000000
    [ 3117.980926] RDX: 0000000000000000 RSI: 0000000000000297 RDI: 0000000000000297
    [ 3117.985497] RBP: ffff88018ebe9980 R08: ffffed003e743ebb R09: ffffed003e743ebb
    [ 3117.990098] R10: 0000000000000001 R11: ffffed003e743eba R12: 0000000000000019
    [ 3117.994761] R13: 0000000000000014 R14: 0000000000000320 R15: ffff88018ebe99e0
    [ 3117.999392] FS:  00007f5694636840(0000) GS:ffff8801f3b00000(0000) knlGS:0000000000000000
    [ 3118.004096] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 3118.008816] CR2: 00007fe89bb1a000 CR3: 0000000191c22000 CR4: 00000000000006e0
    
    - Location
    https://elixir.bootlin.com/linux/v4.18-rc3/source/fs/f2fs/segment.c#L775
                    if (test_and_clear_bit(segno, dirty_i->dirty_segmap[t]))
                            dirty_i->nr_dirty[t]--;
    Here dirty_i->dirty_segmap[t] can be NULL which leads to crash in test_and_clear_bit()
    
    Reported-by Wen Xu <wen.xu@gatech.edu>
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    [bwh: Backported to 4.14: The function is called sanity_check_ckpt()]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d7d9d29a837358636e12fe09c90a7882b53b2220
Author: Chao Yu <yuchao0@huawei.com>
Date:   Sun Jul 8 22:16:55 2018 +0800

    f2fs: fix to do sanity check with i_extra_isize
    
    commit 18dd6470c2d14d10f5a2dd926925dc80dbd3abfd upstream.
    
    If inode.i_extra_isize was fuzzed to an abnormal value, when
    calculating inline data size, the result will overflow, result
    in accessing invalid memory area when operating inline data.
    
    Let's do sanity check with i_extra_isize during inode loading
    for fixing.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=200421
    
    - Reproduce
    
    - POC (poc.c)
        #define _GNU_SOURCE
        #include <sys/types.h>
        #include <sys/mount.h>
        #include <sys/mman.h>
        #include <sys/stat.h>
        #include <sys/xattr.h>
    
        #include <dirent.h>
        #include <errno.h>
        #include <error.h>
        #include <fcntl.h>
        #include <stdio.h>
        #include <stdlib.h>
        #include <string.h>
        #include <unistd.h>
    
        #include <linux/falloc.h>
        #include <linux/loop.h>
    
        static void activity(char *mpoint) {
    
          char *foo_bar_baz;
          char *foo_baz;
          char *xattr;
          int err;
    
          err = asprintf(&foo_bar_baz, "%s/foo/bar/baz", mpoint);
          err = asprintf(&foo_baz, "%s/foo/baz", mpoint);
          err = asprintf(&xattr, "%s/foo/bar/xattr", mpoint);
    
          rename(foo_bar_baz, foo_baz);
    
          char buf2[113];
          memset(buf2, 0, sizeof(buf2));
          listxattr(xattr, buf2, sizeof(buf2));
          removexattr(xattr, "user.mime_type");
    
        }
    
        int main(int argc, char *argv[]) {
          activity(argv[1]);
          return 0;
        }
    
    - Kernel message
    Umount the image will leave the following message
    [ 2910.995489] F2FS-fs (loop0): Mounted with checkpoint version = 2
    [ 2918.416465] ==================================================================
    [ 2918.416807] BUG: KASAN: slab-out-of-bounds in f2fs_iget+0xcb9/0x1a80
    [ 2918.417009] Read of size 4 at addr ffff88018efc2068 by task a.out/1229
    
    [ 2918.417311] CPU: 1 PID: 1229 Comm: a.out Not tainted 4.17.0+ #1
    [ 2918.417314] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [ 2918.417323] Call Trace:
    [ 2918.417366]  dump_stack+0x71/0xab
    [ 2918.417401]  print_address_description+0x6b/0x290
    [ 2918.417407]  kasan_report+0x28e/0x390
    [ 2918.417411]  ? f2fs_iget+0xcb9/0x1a80
    [ 2918.417415]  f2fs_iget+0xcb9/0x1a80
    [ 2918.417422]  ? f2fs_lookup+0x2e7/0x580
    [ 2918.417425]  f2fs_lookup+0x2e7/0x580
    [ 2918.417433]  ? __recover_dot_dentries+0x400/0x400
    [ 2918.417447]  ? legitimize_path.isra.29+0x5a/0xa0
    [ 2918.417453]  __lookup_slow+0x11c/0x220
    [ 2918.417457]  ? may_delete+0x2a0/0x2a0
    [ 2918.417475]  ? deref_stack_reg+0xe0/0xe0
    [ 2918.417479]  ? __lookup_hash+0xb0/0xb0
    [ 2918.417483]  lookup_slow+0x3e/0x60
    [ 2918.417488]  walk_component+0x3ac/0x990
    [ 2918.417492]  ? generic_permission+0x51/0x1e0
    [ 2918.417495]  ? inode_permission+0x51/0x1d0
    [ 2918.417499]  ? pick_link+0x3e0/0x3e0
    [ 2918.417502]  ? link_path_walk+0x4b1/0x770
    [ 2918.417513]  ? _raw_spin_lock_irqsave+0x25/0x50
    [ 2918.417518]  ? walk_component+0x990/0x990
    [ 2918.417522]  ? path_init+0x2e6/0x580
    [ 2918.417526]  path_lookupat+0x13f/0x430
    [ 2918.417531]  ? trailing_symlink+0x3a0/0x3a0
    [ 2918.417534]  ? do_renameat2+0x270/0x7b0
    [ 2918.417538]  ? __kasan_slab_free+0x14c/0x190
    [ 2918.417541]  ? do_renameat2+0x270/0x7b0
    [ 2918.417553]  ? kmem_cache_free+0x85/0x1e0
    [ 2918.417558]  ? do_renameat2+0x270/0x7b0
    [ 2918.417563]  filename_lookup+0x13c/0x280
    [ 2918.417567]  ? filename_parentat+0x2b0/0x2b0
    [ 2918.417572]  ? kasan_unpoison_shadow+0x31/0x40
    [ 2918.417575]  ? kasan_kmalloc+0xa6/0xd0
    [ 2918.417593]  ? strncpy_from_user+0xaa/0x1c0
    [ 2918.417598]  ? getname_flags+0x101/0x2b0
    [ 2918.417614]  ? path_listxattr+0x87/0x110
    [ 2918.417619]  path_listxattr+0x87/0x110
    [ 2918.417623]  ? listxattr+0xc0/0xc0
    [ 2918.417637]  ? mm_fault_error+0x1b0/0x1b0
    [ 2918.417654]  do_syscall_64+0x73/0x160
    [ 2918.417660]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 2918.417676] RIP: 0033:0x7f2f3a3480d7
    [ 2918.417677] Code: f0 ff ff 73 01 c3 48 8b 0d be dd 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 c2 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91 dd 2b 00 f7 d8 64 89 01 48
    [ 2918.417732] RSP: 002b:00007fff4095b7d8 EFLAGS: 00000206 ORIG_RAX: 00000000000000c2
    [ 2918.417744] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2f3a3480d7
    [ 2918.417746] RDX: 0000000000000071 RSI: 00007fff4095b810 RDI: 000000000126a0c0
    [ 2918.417749] RBP: 00007fff4095b890 R08: 000000000126a010 R09: 0000000000000000
    [ 2918.417751] R10: 00000000000001ab R11: 0000000000000206 R12: 00000000004005e0
    [ 2918.417753] R13: 00007fff4095b990 R14: 0000000000000000 R15: 0000000000000000
    
    [ 2918.417853] Allocated by task 329:
    [ 2918.418002]  kasan_kmalloc+0xa6/0xd0
    [ 2918.418007]  kmem_cache_alloc+0xc8/0x1e0
    [ 2918.418023]  mempool_init_node+0x194/0x230
    [ 2918.418027]  mempool_init+0x12/0x20
    [ 2918.418042]  bioset_init+0x2bd/0x380
    [ 2918.418052]  blk_alloc_queue_node+0xe9/0x540
    [ 2918.418075]  dm_create+0x2c0/0x800
    [ 2918.418080]  dev_create+0xd2/0x530
    [ 2918.418083]  ctl_ioctl+0x2a3/0x5b0
    [ 2918.418087]  dm_ctl_ioctl+0xa/0x10
    [ 2918.418092]  do_vfs_ioctl+0x13e/0x8c0
    [ 2918.418095]  ksys_ioctl+0x66/0x70
    [ 2918.418098]  __x64_sys_ioctl+0x3d/0x50
    [ 2918.418102]  do_syscall_64+0x73/0x160
    [ 2918.418106]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    [ 2918.418204] Freed by task 0:
    [ 2918.418301] (stack is not available)
    
    [ 2918.418521] The buggy address belongs to the object at ffff88018efc0000
                    which belongs to the cache biovec-max of size 8192
    [ 2918.418894] The buggy address is located 104 bytes to the right of
                    8192-byte region [ffff88018efc0000, ffff88018efc2000)
    [ 2918.419257] The buggy address belongs to the page:
    [ 2918.419431] page:ffffea00063bf000 count:1 mapcount:0 mapping:ffff8801f2242540 index:0x0 compound_mapcount: 0
    [ 2918.419702] flags: 0x17fff8000008100(slab|head)
    [ 2918.419879] raw: 017fff8000008100 dead000000000100 dead000000000200 ffff8801f2242540
    [ 2918.420101] raw: 0000000000000000 0000000000030003 00000001ffffffff 0000000000000000
    [ 2918.420322] page dumped because: kasan: bad access detected
    
    [ 2918.420599] Memory state around the buggy address:
    [ 2918.420764]  ffff88018efc1f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [ 2918.420975]  ffff88018efc1f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [ 2918.421194] >ffff88018efc2000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [ 2918.421406]                                                           ^
    [ 2918.421627]  ffff88018efc2080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [ 2918.421838]  ffff88018efc2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [ 2918.422046] ==================================================================
    [ 2918.422264] Disabling lock debugging due to kernel taint
    [ 2923.901641] BUG: unable to handle kernel paging request at ffff88018f0db000
    [ 2923.901884] PGD 22226a067 P4D 22226a067 PUD 222273067 PMD 18e642063 PTE 800000018f0db061
    [ 2923.902120] Oops: 0003 [#1] SMP KASAN PTI
    [ 2923.902274] CPU: 1 PID: 1231 Comm: umount Tainted: G    B             4.17.0+ #1
    [ 2923.902490] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [ 2923.902761] RIP: 0010:__memset+0x24/0x30
    [ 2923.902906] Code: 90 90 90 90 90 90 66 66 90 66 90 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
    [ 2923.903446] RSP: 0018:ffff88018ddf7ae0 EFLAGS: 00010206
    [ 2923.903622] RAX: 0000000000000000 RBX: ffff8801d549d888 RCX: 1ffffffffffdaffb
    [ 2923.903833] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88018f0daffc
    [ 2923.904062] RBP: ffff88018efc206c R08: 1ffff10031df840d R09: ffff88018efc206c
    [ 2923.904273] R10: ffffffffffffe1ee R11: ffffed0031df65fa R12: 0000000000000000
    [ 2923.904485] R13: ffff8801d549dc98 R14: 00000000ffffc3db R15: ffffea00063bec80
    [ 2923.904693] FS:  00007fa8b2f8a840(0000) GS:ffff8801f3b00000(0000) knlGS:0000000000000000
    [ 2923.904937] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 2923.910080] CR2: ffff88018f0db000 CR3: 000000018f892000 CR4: 00000000000006e0
    [ 2923.914930] Call Trace:
    [ 2923.919724]  f2fs_truncate_inline_inode+0x114/0x170
    [ 2923.924487]  f2fs_truncate_blocks+0x11b/0x7c0
    [ 2923.929178]  ? f2fs_truncate_data_blocks+0x10/0x10
    [ 2923.933834]  ? dqget+0x670/0x670
    [ 2923.938437]  ? f2fs_destroy_extent_tree+0xd6/0x270
    [ 2923.943107]  ? __radix_tree_lookup+0x2f/0x150
    [ 2923.947772]  f2fs_truncate+0xd4/0x1a0
    [ 2923.952491]  f2fs_evict_inode+0x5ab/0x610
    [ 2923.957204]  evict+0x15f/0x280
    [ 2923.961898]  __dentry_kill+0x161/0x250
    [ 2923.966634]  shrink_dentry_list+0xf3/0x250
    [ 2923.971897]  shrink_dcache_parent+0xa9/0x100
    [ 2923.976561]  ? shrink_dcache_sb+0x1f0/0x1f0
    [ 2923.981177]  ? wait_for_completion+0x8a/0x210
    [ 2923.985781]  ? migrate_swap_stop+0x2d0/0x2d0
    [ 2923.990332]  do_one_tree+0xe/0x40
    [ 2923.994735]  shrink_dcache_for_umount+0x3a/0xa0
    [ 2923.999077]  generic_shutdown_super+0x3e/0x1c0
    [ 2924.003350]  kill_block_super+0x4b/0x70
    [ 2924.007619]  deactivate_locked_super+0x65/0x90
    [ 2924.011812]  cleanup_mnt+0x5c/0xa0
    [ 2924.015995]  task_work_run+0xce/0xf0
    [ 2924.020174]  exit_to_usermode_loop+0x115/0x120
    [ 2924.024293]  do_syscall_64+0x12f/0x160
    [ 2924.028479]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 2924.032709] RIP: 0033:0x7fa8b2868487
    [ 2924.036888] Code: 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 c9 2b 00 f7 d8 64 89 01 48
    [ 2924.045750] RSP: 002b:00007ffc39824d58 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
    [ 2924.050190] RAX: 0000000000000000 RBX: 00000000008ea030 RCX: 00007fa8b2868487
    [ 2924.054604] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000008f4360
    [ 2924.058940] RBP: 00000000008f4360 R08: 0000000000000000 R09: 0000000000000014
    [ 2924.063186] R10: 00000000000006b2 R11: 0000000000000246 R12: 00007fa8b2d7183c
    [ 2924.067418] R13: 0000000000000000 R14: 00000000008ea210 R15: 00007ffc39824fe0
    [ 2924.071534] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer joydev input_leds serio_raw snd soundcore mac_hid i2c_piix4 ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi btrfs zstd_decompress zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear 8139too qxl ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel psmouse aes_x86_64 8139cp crypto_simd cryptd mii glue_helper pata_acpi floppy
    [ 2924.098044] CR2: ffff88018f0db000
    [ 2924.102520] ---[ end trace a8e0d899985faf31 ]---
    [ 2924.107012] RIP: 0010:__memset+0x24/0x30
    [ 2924.111448] Code: 90 90 90 90 90 90 66 66 90 66 90 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
    [ 2924.120724] RSP: 0018:ffff88018ddf7ae0 EFLAGS: 00010206
    [ 2924.125312] RAX: 0000000000000000 RBX: ffff8801d549d888 RCX: 1ffffffffffdaffb
    [ 2924.129931] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88018f0daffc
    [ 2924.134537] RBP: ffff88018efc206c R08: 1ffff10031df840d R09: ffff88018efc206c
    [ 2924.139175] R10: ffffffffffffe1ee R11: ffffed0031df65fa R12: 0000000000000000
    [ 2924.143825] R13: ffff8801d549dc98 R14: 00000000ffffc3db R15: ffffea00063bec80
    [ 2924.148500] FS:  00007fa8b2f8a840(0000) GS:ffff8801f3b00000(0000) knlGS:0000000000000000
    [ 2924.153247] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 2924.158003] CR2: ffff88018f0db000 CR3: 000000018f892000 CR4: 00000000000006e0
    [ 2924.164641] BUG: Bad rss-counter state mm:00000000fa04621e idx:0 val:4
    [ 2924.170007] BUG: Bad rss-counter
    tate mm:00000000fa04621e idx:1 val:2
    
    - Location
    https://elixir.bootlin.com/linux/v4.18-rc3/source/fs/f2fs/inline.c#L78
            memset(addr + from, 0, MAX_INLINE_DATA(inode) - from);
    Here the length can be negative.
    
    Reported-by Wen Xu <wen.xu@gatech.edu>
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    [bwh: Backported to 4.14: adjust context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad19d1e78fd51f5b4bf3ebbcbf3a133c8c03c49d
Author: Chao Yu <yuchao0@huawei.com>
Date:   Wed Aug 1 19:13:44 2018 +0800

    f2fs: fix to do sanity check with block address in main area
    
    commit c9b60788fc760d136211853f10ce73dc152d1f4a upstream.
    
    This patch add to do sanity check with below field:
    - cp_pack_total_block_count
    - blkaddr of data/node
    - extent info
    
    - Overview
    BUG() in verify_block_addr() when writing to a corrupted f2fs image
    
    - Reproduce (4.18 upstream kernel)
    
    - POC (poc.c)
    
    static void activity(char *mpoint) {
    
      char *foo_bar_baz;
      int err;
    
      static int buf[8192];
      memset(buf, 0, sizeof(buf));
    
      err = asprintf(&foo_bar_baz, "%s/foo/bar/baz", mpoint);
    
      int fd = open(foo_bar_baz, O_RDWR | O_TRUNC, 0777);
      if (fd >= 0) {
        write(fd, (char *)buf, sizeof(buf));
        fdatasync(fd);
        close(fd);
      }
    }
    
    int main(int argc, char *argv[]) {
      activity(argv[1]);
      return 0;
    }
    
    - Kernel message
    [  689.349473] F2FS-fs (loop0): Mounted with checkpoint version = 3
    [  699.728662] WARNING: CPU: 0 PID: 1309 at fs/f2fs/segment.c:2860 f2fs_inplace_write_data+0x232/0x240
    [  699.728670] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd mac_hid i2c_piix4 soundcore ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear 8139too crct10dif_pclmul crc32_pclmul qxl drm_kms_helper syscopyarea aesni_intel sysfillrect sysimgblt fb_sys_fops ttm drm aes_x86_64 crypto_simd cryptd 8139cp glue_helper mii pata_acpi floppy
    [  699.729056] CPU: 0 PID: 1309 Comm: a.out Not tainted 4.18.0-rc1+ #4
    [  699.729064] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  699.729074] RIP: 0010:f2fs_inplace_write_data+0x232/0x240
    [  699.729076] Code: ff e9 cf fe ff ff 49 8d 7d 10 e8 39 45 ad ff 4d 8b 7d 10 be 04 00 00 00 49 8d 7f 48 e8 07 49 ad ff 45 8b 7f 48 e9 fb fe ff ff <0f> 0b f0 41 80 4d 48 04 e9 65 fe ff ff 90 66 66 66 66 90 55 48 8d
    [  699.729130] RSP: 0018:ffff8801f43af568 EFLAGS: 00010202
    [  699.729139] RAX: 000000000000003f RBX: ffff8801f43af7b8 RCX: ffffffffb88c9113
    [  699.729142] RDX: 0000000000000003 RSI: dffffc0000000000 RDI: ffff8802024e5540
    [  699.729144] RBP: ffff8801f43af590 R08: 0000000000000009 R09: ffffffffffffffe8
    [  699.729147] R10: 0000000000000001 R11: ffffed0039b0596a R12: ffff8802024e5540
    [  699.729149] R13: ffff8801f0335500 R14: ffff8801e3e7a700 R15: ffff8801e1ee4450
    [  699.729154] FS:  00007f9bf97f5700(0000) GS:ffff8801f6e00000(0000) knlGS:0000000000000000
    [  699.729156] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  699.729159] CR2: 00007f9bf925d170 CR3: 00000001f0c34000 CR4: 00000000000006f0
    [  699.729171] Call Trace:
    [  699.729192]  f2fs_do_write_data_page+0x2e2/0xe00
    [  699.729203]  ? f2fs_should_update_outplace+0xd0/0xd0
    [  699.729238]  ? memcg_drain_all_list_lrus+0x280/0x280
    [  699.729269]  ? __radix_tree_replace+0xa3/0x120
    [  699.729276]  __write_data_page+0x5c7/0xe30
    [  699.729291]  ? kasan_check_read+0x11/0x20
    [  699.729310]  ? page_mapped+0x8a/0x110
    [  699.729321]  ? page_mkclean+0xe9/0x160
    [  699.729327]  ? f2fs_do_write_data_page+0xe00/0xe00
    [  699.729331]  ? invalid_page_referenced_vma+0x130/0x130
    [  699.729345]  ? clear_page_dirty_for_io+0x332/0x450
    [  699.729351]  f2fs_write_cache_pages+0x4ca/0x860
    [  699.729358]  ? __write_data_page+0xe30/0xe30
    [  699.729374]  ? percpu_counter_add_batch+0x22/0xa0
    [  699.729380]  ? kasan_check_write+0x14/0x20
    [  699.729391]  ? _raw_spin_lock+0x17/0x40
    [  699.729403]  ? f2fs_mark_inode_dirty_sync.part.18+0x16/0x30
    [  699.729413]  ? iov_iter_advance+0x113/0x640
    [  699.729418]  ? f2fs_write_end+0x133/0x2e0
    [  699.729423]  ? balance_dirty_pages_ratelimited+0x239/0x640
    [  699.729428]  f2fs_write_data_pages+0x329/0x520
    [  699.729433]  ? generic_perform_write+0x250/0x320
    [  699.729438]  ? f2fs_write_cache_pages+0x860/0x860
    [  699.729454]  ? current_time+0x110/0x110
    [  699.729459]  ? f2fs_preallocate_blocks+0x1ef/0x370
    [  699.729464]  do_writepages+0x37/0xb0
    [  699.729468]  ? f2fs_write_cache_pages+0x860/0x860
    [  699.729472]  ? do_writepages+0x37/0xb0
    [  699.729478]  __filemap_fdatawrite_range+0x19a/0x1f0
    [  699.729483]  ? delete_from_page_cache_batch+0x4e0/0x4e0
    [  699.729496]  ? __vfs_write+0x2b2/0x410
    [  699.729501]  file_write_and_wait_range+0x66/0xb0
    [  699.729506]  f2fs_do_sync_file+0x1f9/0xd90
    [  699.729511]  ? truncate_partial_data_page+0x290/0x290
    [  699.729521]  ? __sb_end_write+0x30/0x50
    [  699.729526]  ? vfs_write+0x20f/0x260
    [  699.729530]  f2fs_sync_file+0x9a/0xb0
    [  699.729534]  ? f2fs_do_sync_file+0xd90/0xd90
    [  699.729548]  vfs_fsync_range+0x68/0x100
    [  699.729554]  ? __fget_light+0xc9/0xe0
    [  699.729558]  do_fsync+0x3d/0x70
    [  699.729562]  __x64_sys_fdatasync+0x24/0x30
    [  699.729585]  do_syscall_64+0x78/0x170
    [  699.729595]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  699.729613] RIP: 0033:0x7f9bf930d800
    [  699.729615] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 83 3d 49 bf 2c 00 00 75 10 b8 4b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 be 78 01 00 48 89 04 24
    [  699.729668] RSP: 002b:00007ffee3606c68 EFLAGS: 00000246 ORIG_RAX: 000000000000004b
    [  699.729673] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9bf930d800
    [  699.729675] RDX: 0000000000008000 RSI: 00000000006010a0 RDI: 0000000000000003
    [  699.729678] RBP: 00007ffee3606ca0 R08: 0000000001503010 R09: 0000000000000000
    [  699.729680] R10: 00000000000002e8 R11: 0000000000000246 R12: 0000000000400610
    [  699.729683] R13: 00007ffee3606da0 R14: 0000000000000000 R15: 0000000000000000
    [  699.729687] ---[ end trace 4ce02f25ff7d3df5 ]---
    [  699.729782] ------------[ cut here ]------------
    [  699.729785] kernel BUG at fs/f2fs/segment.h:654!
    [  699.731055] invalid opcode: 0000 [#1] SMP KASAN PTI
    [  699.732104] CPU: 0 PID: 1309 Comm: a.out Tainted: G        W         4.18.0-rc1+ #4
    [  699.733684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  699.735611] RIP: 0010:f2fs_submit_page_bio+0x29b/0x730
    [  699.736649] Code: 54 49 8d bd 18 04 00 00 e8 b2 59 af ff 41 8b 8d 18 04 00 00 8b 45 b8 41 d3 e6 44 01 f0 4c 8d 73 14 41 39 c7 0f 82 37 fe ff ff <0f> 0b 65 8b 05 2c 04 77 47 89 c0 48 0f a3 05 52 c1 d5 01 0f 92 c0
    [  699.740524] RSP: 0018:ffff8801f43af508 EFLAGS: 00010283
    [  699.741573] RAX: 0000000000000000 RBX: ffff8801f43af7b8 RCX: ffffffffb88a7cef
    [  699.743006] RDX: 0000000000000007 RSI: dffffc0000000000 RDI: ffff8801e3e7a64c
    [  699.744426] RBP: ffff8801f43af558 R08: ffffed003e066b55 R09: ffffed003e066b55
    [  699.745833] R10: 0000000000000001 R11: ffffed003e066b54 R12: ffffea0007876940
    [  699.747256] R13: ffff8801f0335500 R14: ffff8801e3e7a600 R15: 0000000000000001
    [  699.748683] FS:  00007f9bf97f5700(0000) GS:ffff8801f6e00000(0000) knlGS:0000000000000000
    [  699.750293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  699.751462] CR2: 00007f9bf925d170 CR3: 00000001f0c34000 CR4: 00000000000006f0
    [  699.752874] Call Trace:
    [  699.753386]  ? f2fs_inplace_write_data+0x93/0x240
    [  699.754341]  f2fs_inplace_write_data+0xd2/0x240
    [  699.755271]  f2fs_do_write_data_page+0x2e2/0xe00
    [  699.756214]  ? f2fs_should_update_outplace+0xd0/0xd0
    [  699.757215]  ? memcg_drain_all_list_lrus+0x280/0x280
    [  699.758209]  ? __radix_tree_replace+0xa3/0x120
    [  699.759164]  __write_data_page+0x5c7/0xe30
    [  699.760002]  ? kasan_check_read+0x11/0x20
    [  699.760823]  ? page_mapped+0x8a/0x110
    [  699.761573]  ? page_mkclean+0xe9/0x160
    [  699.762345]  ? f2fs_do_write_data_page+0xe00/0xe00
    [  699.763332]  ? invalid_page_referenced_vma+0x130/0x130
    [  699.764374]  ? clear_page_dirty_for_io+0x332/0x450
    [  699.765347]  f2fs_write_cache_pages+0x4ca/0x860
    [  699.766276]  ? __write_data_page+0xe30/0xe30
    [  699.767161]  ? percpu_counter_add_batch+0x22/0xa0
    [  699.768112]  ? kasan_check_write+0x14/0x20
    [  699.768951]  ? _raw_spin_lock+0x17/0x40
    [  699.769739]  ? f2fs_mark_inode_dirty_sync.part.18+0x16/0x30
    [  699.770885]  ? iov_iter_advance+0x113/0x640
    [  699.771743]  ? f2fs_write_end+0x133/0x2e0
    [  699.772569]  ? balance_dirty_pages_ratelimited+0x239/0x640
    [  699.773680]  f2fs_write_data_pages+0x329/0x520
    [  699.774603]  ? generic_perform_write+0x250/0x320
    [  699.775544]  ? f2fs_write_cache_pages+0x860/0x860
    [  699.776510]  ? current_time+0x110/0x110
    [  699.777299]  ? f2fs_preallocate_blocks+0x1ef/0x370
    [  699.778279]  do_writepages+0x37/0xb0
    [  699.779026]  ? f2fs_write_cache_pages+0x860/0x860
    [  699.779978]  ? do_writepages+0x37/0xb0
    [  699.780755]  __filemap_fdatawrite_range+0x19a/0x1f0
    [  699.781746]  ? delete_from_page_cache_batch+0x4e0/0x4e0
    [  699.782820]  ? __vfs_write+0x2b2/0x410
    [  699.783597]  file_write_and_wait_range+0x66/0xb0
    [  699.784540]  f2fs_do_sync_file+0x1f9/0xd90
    [  699.785381]  ? truncate_partial_data_page+0x290/0x290
    [  699.786415]  ? __sb_end_write+0x30/0x50
    [  699.787204]  ? vfs_write+0x20f/0x260
    [  699.787941]  f2fs_sync_file+0x9a/0xb0
    [  699.788694]  ? f2fs_do_sync_file+0xd90/0xd90
    [  699.789572]  vfs_fsync_range+0x68/0x100
    [  699.790360]  ? __fget_light+0xc9/0xe0
    [  699.791128]  do_fsync+0x3d/0x70
    [  699.791779]  __x64_sys_fdatasync+0x24/0x30
    [  699.792614]  do_syscall_64+0x78/0x170
    [  699.793371]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  699.794406] RIP: 0033:0x7f9bf930d800
    [  699.795134] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 83 3d 49 bf 2c 00 00 75 10 b8 4b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 be 78 01 00 48 89 04 24
    [  699.798960] RSP: 002b:00007ffee3606c68 EFLAGS: 00000246 ORIG_RAX: 000000000000004b
    [  699.800483] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9bf930d800
    [  699.801923] RDX: 0000000000008000 RSI: 00000000006010a0 RDI: 0000000000000003
    [  699.803373] RBP: 00007ffee3606ca0 R08: 0000000001503010 R09: 0000000000000000
    [  699.804798] R10: 00000000000002e8 R11: 0000000000000246 R12: 0000000000400610
    [  699.806233] R13: 00007ffee3606da0 R14: 0000000000000000 R15: 0000000000000000
    [  699.807667] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd mac_hid i2c_piix4 soundcore ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear 8139too crct10dif_pclmul crc32_pclmul qxl drm_kms_helper syscopyarea aesni_intel sysfillrect sysimgblt fb_sys_fops ttm drm aes_x86_64 crypto_simd cryptd 8139cp glue_helper mii pata_acpi floppy
    [  699.817079] ---[ end trace 4ce02f25ff7d3df6 ]---
    [  699.818068] RIP: 0010:f2fs_submit_page_bio+0x29b/0x730
    [  699.819114] Code: 54 49 8d bd 18 04 00 00 e8 b2 59 af ff 41 8b 8d 18 04 00 00 8b 45 b8 41 d3 e6 44 01 f0 4c 8d 73 14 41 39 c7 0f 82 37 fe ff ff <0f> 0b 65 8b 05 2c 04 77 47 89 c0 48 0f a3 05 52 c1 d5 01 0f 92 c0
    [  699.822919] RSP: 0018:ffff8801f43af508 EFLAGS: 00010283
    [  699.823977] RAX: 0000000000000000 RBX: ffff8801f43af7b8 RCX: ffffffffb88a7cef
    [  699.825436] RDX: 0000000000000007 RSI: dffffc0000000000 RDI: ffff8801e3e7a64c
    [  699.826881] RBP: ffff8801f43af558 R08: ffffed003e066b55 R09: ffffed003e066b55
    [  699.828292] R10: 0000000000000001 R11: ffffed003e066b54 R12: ffffea0007876940
    [  699.829750] R13: ffff8801f0335500 R14: ffff8801e3e7a600 R15: 0000000000000001
    [  699.831192] FS:  00007f9bf97f5700(0000) GS:ffff8801f6e00000(0000) knlGS:0000000000000000
    [  699.832793] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  699.833981] CR2: 00007f9bf925d170 CR3: 00000001f0c34000 CR4: 00000000000006f0
    [  699.835556] ==================================================================
    [  699.837029] BUG: KASAN: stack-out-of-bounds in update_stack_state+0x38c/0x3e0
    [  699.838462] Read of size 8 at addr ffff8801f43af970 by task a.out/1309
    
    [  699.840086] CPU: 0 PID: 1309 Comm: a.out Tainted: G      D W         4.18.0-rc1+ #4
    [  699.841603] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  699.843475] Call Trace:
    [  699.843982]  dump_stack+0x7b/0xb5
    [  699.844661]  print_address_description+0x70/0x290
    [  699.845607]  kasan_report+0x291/0x390
    [  699.846351]  ? update_stack_state+0x38c/0x3e0
    [  699.853831]  __asan_load8+0x54/0x90
    [  699.854569]  update_stack_state+0x38c/0x3e0
    [  699.855428]  ? __read_once_size_nocheck.constprop.7+0x20/0x20
    [  699.856601]  ? __save_stack_trace+0x5e/0x100
    [  699.857476]  unwind_next_frame.part.5+0x18e/0x490
    [  699.858448]  ? unwind_dump+0x290/0x290
    [  699.859217]  ? clear_page_dirty_for_io+0x332/0x450
    [  699.860185]  __unwind_start+0x106/0x190
    [  699.860974]  __save_stack_trace+0x5e/0x100
    [  699.861808]  ? __save_stack_trace+0x5e/0x100
    [  699.862691]  ? unlink_anon_vmas+0xba/0x2c0
    [  699.863525]  save_stack_trace+0x1f/0x30
    [  699.864312]  save_stack+0x46/0xd0
    [  699.864993]  ? __alloc_pages_slowpath+0x1420/0x1420
    [  699.865990]  ? flush_tlb_mm_range+0x15e/0x220
    [  699.866889]  ? kasan_check_write+0x14/0x20
    [  699.867724]  ? __dec_node_state+0x92/0xb0
    [  699.868543]  ? lock_page_memcg+0x85/0xf0
    [  699.869350]  ? unlock_page_memcg+0x16/0x80
    [  699.870185]  ? page_remove_rmap+0x198/0x520
    [  699.871048]  ? mark_page_accessed+0x133/0x200
    [  699.871930]  ? _cond_resched+0x1a/0x50
    [  699.872700]  ? unmap_page_range+0xcd4/0xe50
    [  699.873551]  ? rb_next+0x58/0x80
    [  699.874217]  ? rb_next+0x58/0x80
    [  699.874895]  __kasan_slab_free+0x13c/0x1a0
    [  699.875734]  ? unlink_anon_vmas+0xba/0x2c0
    [  699.876563]  kasan_slab_free+0xe/0x10
    [  699.877315]  kmem_cache_free+0x89/0x1e0
    [  699.878095]  unlink_anon_vmas+0xba/0x2c0
    [  699.878913]  free_pgtables+0x101/0x1b0
    [  699.879677]  exit_mmap+0x146/0x2a0
    [  699.880378]  ? __ia32_sys_munmap+0x50/0x50
    [  699.881214]  ? kasan_check_read+0x11/0x20
    [  699.882052]  ? mm_update_next_owner+0x322/0x380
    [  699.882985]  mmput+0x8b/0x1d0
    [  699.883602]  do_exit+0x43a/0x1390
    [  699.884288]  ? mm_update_next_owner+0x380/0x380
    [  699.885212]  ? f2fs_sync_file+0x9a/0xb0
    [  699.885995]  ? f2fs_do_sync_file+0xd90/0xd90
    [  699.886877]  ? vfs_fsync_range+0x68/0x100
    [  699.887694]  ? __fget_light+0xc9/0xe0
    [  699.888442]  ? do_fsync+0x3d/0x70
    [  699.889118]  ? __x64_sys_fdatasync+0x24/0x30
    [  699.889996]  rewind_stack_do_exit+0x17/0x20
    [  699.890860] RIP: 0033:0x7f9bf930d800
    [  699.891585] Code: Bad RIP value.
    [  699.892268] RSP: 002b:00007ffee3606c68 EFLAGS: 00000246 ORIG_RAX: 000000000000004b
    [  699.893781] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9bf930d800
    [  699.895220] RDX: 0000000000008000 RSI: 00000000006010a0 RDI: 0000000000000003
    [  699.896643] RBP: 00007ffee3606ca0 R08: 0000000001503010 R09: 0000000000000000
    [  699.898069] R10: 00000000000002e8 R11: 0000000000000246 R12: 0000000000400610
    [  699.899505] R13: 00007ffee3606da0 R14: 0000000000000000 R15: 0000000000000000
    
    [  699.901241] The buggy address belongs to the page:
    [  699.902215] page:ffffea0007d0ebc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
    [  699.903811] flags: 0x2ffff0000000000()
    [  699.904585] raw: 02ffff0000000000 0000000000000000 ffffffff07d00101 0000000000000000
    [  699.906125] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000
    [  699.907673] page dumped because: kasan: bad access detected
    
    [  699.909108] Memory state around the buggy address:
    [  699.910077]  ffff8801f43af800: 00 f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3 f3 00 00 00
    [  699.911528]  ffff8801f43af880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [  699.912953] >ffff8801f43af900: 00 00 00 00 00 00 00 00 f1 01 f4 f4 f4 f2 f2 f2
    [  699.914392]                                                              ^
    [  699.915758]  ffff8801f43af980: f2 00 f4 f4 00 00 00 00 f2 00 00 00 00 00 00 00
    [  699.917193]  ffff8801f43afa00: 00 00 00 00 00 00 00 00 00 f3 f3 f3 00 00 00 00
    [  699.918634] ==================================================================
    
    - Location
    https://elixir.bootlin.com/linux/v4.18-rc1/source/fs/f2fs/segment.h#L644
    
    Reported-by Wen Xu <wen.xu@gatech.edu>
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    [bwh: Backported to 4.14:
     - Error label is different in validate_checkpoint() due to the earlier
       backport of "f2fs: fix invalid memory access"
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8321ccd045710ee04fd5322c34cadd13a5e58af
Author: Chao Yu <yuchao0@huawei.com>
Date:   Fri Jun 29 13:55:22 2018 +0800

    f2fs: fix to do sanity check with node footer and iblocks
    
    commit e34438c903b653daca2b2a7de95aed46226f8ed3 upstream.
    
    This patch adds to do sanity check with below fields of inode to
    avoid reported panic.
    - node footer
    - iblocks
    
    https://bugzilla.kernel.org/show_bug.cgi?id=200223
    
    - Overview
    BUG() triggered in f2fs_truncate_inode_blocks() when un-mounting a mounted f2fs image after writing to it
    
    - Reproduce
    
    - POC (poc.c)
    
    static void activity(char *mpoint) {
    
      char *foo_bar_baz;
      int err;
    
      static int buf[8192];
      memset(buf, 0, sizeof(buf));
    
      err = asprintf(&foo_bar_baz, "%s/foo/bar/baz", mpoint);
    
      // open / write / read
      int fd = open(foo_bar_baz, O_RDWR | O_TRUNC, 0777);
      if (fd >= 0) {
        write(fd, (char *)buf, 517);
        write(fd, (char *)buf, sizeof(buf));
        close(fd);
      }
    
    }
    
    int main(int argc, char *argv[]) {
      activity(argv[1]);
      return 0;
    }
    
    - Kernel meesage
    [  552.479723] F2FS-fs (loop0): Mounted with checkpoint version = 2
    [  556.451891] ------------[ cut here ]------------
    [  556.451899] kernel BUG at fs/f2fs/node.c:987!
    [  556.452920] invalid opcode: 0000 [#1] SMP KASAN PTI
    [  556.453936] CPU: 1 PID: 1310 Comm: umount Not tainted 4.18.0-rc1+ #4
    [  556.455213] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  556.457140] RIP: 0010:f2fs_truncate_inode_blocks+0x4a7/0x6f0
    [  556.458280] Code: e8 ae ea ff ff 41 89 c7 c1 e8 1f 84 c0 74 0a 41 83 ff fe 0f 85 35 ff ff ff 81 85 b0 fe ff ff fb 03 00 00 e9 f7 fd ff ff 0f 0b <0f> 0b e8 62 b7 9a 00 48 8b bd a0 fe ff ff e8 56 54 ae ff 48 8b b5
    [  556.462015] RSP: 0018:ffff8801f292f808 EFLAGS: 00010286
    [  556.463068] RAX: ffffed003e73242d RBX: ffff8801f292f958 RCX: ffffffffb88b81bc
    [  556.464479] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff8801f3992164
    [  556.465901] RBP: ffff8801f292f980 R08: ffffed003e73242d R09: ffffed003e73242d
    [  556.467311] R10: 0000000000000001 R11: ffffed003e73242c R12: 00000000fffffc64
    [  556.468706] R13: ffff8801f3992000 R14: 0000000000000058 R15: 00000000ffff8801
    [  556.470117] FS:  00007f8029297840(0000) GS:ffff8801f6f00000(0000) knlGS:0000000000000000
    [  556.471702] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  556.472838] CR2: 000055f5f57305d8 CR3: 00000001f18b0000 CR4: 00000000000006e0
    [  556.474265] Call Trace:
    [  556.474782]  ? f2fs_alloc_nid_failed+0xf0/0xf0
    [  556.475686]  ? truncate_nodes+0x980/0x980
    [  556.476516]  ? pagecache_get_page+0x21f/0x2f0
    [  556.477412]  ? __asan_loadN+0xf/0x20
    [  556.478153]  ? __get_node_page+0x331/0x5b0
    [  556.478992]  ? reweight_entity+0x1e6/0x3b0
    [  556.479826]  f2fs_truncate_blocks+0x55e/0x740
    [  556.480709]  ? f2fs_truncate_data_blocks+0x20/0x20
    [  556.481689]  ? __radix_tree_lookup+0x34/0x160
    [  556.482630]  ? radix_tree_lookup+0xd/0x10
    [  556.483445]  f2fs_truncate+0xd4/0x1a0
    [  556.484206]  f2fs_evict_inode+0x5ce/0x630
    [  556.485032]  evict+0x16f/0x290
    [  556.485664]  iput+0x280/0x300
    [  556.486300]  dentry_unlink_inode+0x165/0x1e0
    [  556.487169]  __dentry_kill+0x16a/0x260
    [  556.487936]  dentry_kill+0x70/0x250
    [  556.488651]  shrink_dentry_list+0x125/0x260
    [  556.489504]  shrink_dcache_parent+0xc1/0x110
    [  556.490379]  ? shrink_dcache_sb+0x200/0x200
    [  556.491231]  ? bit_wait_timeout+0xc0/0xc0
    [  556.492047]  do_one_tree+0x12/0x40
    [  556.492743]  shrink_dcache_for_umount+0x3f/0xa0
    [  556.493656]  generic_shutdown_super+0x43/0x1c0
    [  556.494561]  kill_block_super+0x52/0x80
    [  556.495341]  kill_f2fs_super+0x62/0x70
    [  556.496105]  deactivate_locked_super+0x6f/0xa0
    [  556.497004]  deactivate_super+0x5e/0x80
    [  556.497785]  cleanup_mnt+0x61/0xa0
    [  556.498492]  __cleanup_mnt+0x12/0x20
    [  556.499218]  task_work_run+0xc8/0xf0
    [  556.499949]  exit_to_usermode_loop+0x125/0x130
    [  556.500846]  do_syscall_64+0x138/0x170
    [  556.501609]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  556.502659] RIP: 0033:0x7f8028b77487
    [  556.503384] Code: 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 c9 2b 00 f7 d8 64 89 01 48
    [  556.507137] RSP: 002b:00007fff9f2e3598 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
    [  556.508637] RAX: 0000000000000000 RBX: 0000000000ebd030 RCX: 00007f8028b77487
    [  556.510069] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000ec41e0
    [  556.511481] RBP: 0000000000ec41e0 R08: 0000000000000000 R09: 0000000000000014
    [  556.512892] R10: 00000000000006b2 R11: 0000000000000246 R12: 00007f802908083c
    [  556.514320] R13: 0000000000000000 R14: 0000000000ebd210 R15: 00007fff9f2e3820
    [  556.515745] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd mac_hid i2c_piix4 soundcore ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear 8139too crct10dif_pclmul crc32_pclmul qxl drm_kms_helper syscopyarea aesni_intel sysfillrect sysimgblt fb_sys_fops ttm drm aes_x86_64 crypto_simd cryptd 8139cp glue_helper mii pata_acpi floppy
    [  556.529276] ---[ end trace 4ce02f25ff7d3df5 ]---
    [  556.530340] RIP: 0010:f2fs_truncate_inode_blocks+0x4a7/0x6f0
    [  556.531513] Code: e8 ae ea ff ff 41 89 c7 c1 e8 1f 84 c0 74 0a 41 83 ff fe 0f 85 35 ff ff ff 81 85 b0 fe ff ff fb 03 00 00 e9 f7 fd ff ff 0f 0b <0f> 0b e8 62 b7 9a 00 48 8b bd a0 fe ff ff e8 56 54 ae ff 48 8b b5
    [  556.535330] RSP: 0018:ffff8801f292f808 EFLAGS: 00010286
    [  556.536395] RAX: ffffed003e73242d RBX: ffff8801f292f958 RCX: ffffffffb88b81bc
    [  556.537824] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff8801f3992164
    [  556.539290] RBP: ffff8801f292f980 R08: ffffed003e73242d R09: ffffed003e73242d
    [  556.540709] R10: 0000000000000001 R11: ffffed003e73242c R12: 00000000fffffc64
    [  556.542131] R13: ffff8801f3992000 R14: 0000000000000058 R15: 00000000ffff8801
    [  556.543579] FS:  00007f8029297840(0000) GS:ffff8801f6f00000(0000) knlGS:0000000000000000
    [  556.545180] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  556.546338] CR2: 000055f5f57305d8 CR3: 00000001f18b0000 CR4: 00000000000006e0
    [  556.547809] ==================================================================
    [  556.549248] BUG: KASAN: stack-out-of-bounds in arch_tlb_gather_mmu+0x52/0x170
    [  556.550672] Write of size 8 at addr ffff8801f292fd10 by task umount/1310
    
    [  556.552338] CPU: 1 PID: 1310 Comm: umount Tainted: G      D           4.18.0-rc1+ #4
    [  556.553886] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  556.555756] Call Trace:
    [  556.556264]  dump_stack+0x7b/0xb5
    [  556.556944]  print_address_description+0x70/0x290
    [  556.557903]  kasan_report+0x291/0x390
    [  556.558649]  ? arch_tlb_gather_mmu+0x52/0x170
    [  556.559537]  __asan_store8+0x57/0x90
    [  556.560268]  arch_tlb_gather_mmu+0x52/0x170
    [  556.561110]  tlb_gather_mmu+0x12/0x40
    [  556.561862]  exit_mmap+0x123/0x2a0
    [  556.562555]  ? __ia32_sys_munmap+0x50/0x50
    [  556.563384]  ? exit_aio+0x98/0x230
    [  556.564079]  ? __x32_compat_sys_io_submit+0x260/0x260
    [  556.565099]  ? taskstats_exit+0x1f4/0x640
    [  556.565925]  ? kasan_check_read+0x11/0x20
    [  556.566739]  ? mm_update_next_owner+0x322/0x380
    [  556.567652]  mmput+0x8b/0x1d0
    [  556.568260]  do_exit+0x43a/0x1390
    [  556.568937]  ? mm_update_next_owner+0x380/0x380
    [  556.569855]  ? deactivate_super+0x5e/0x80
    [  556.570668]  ? cleanup_mnt+0x61/0xa0
    [  556.571395]  ? __cleanup_mnt+0x12/0x20
    [  556.572156]  ? task_work_run+0xc8/0xf0
    [  556.572917]  ? exit_to_usermode_loop+0x125/0x130
    [  556.573861]  rewind_stack_do_exit+0x17/0x20
    [  556.574707] RIP: 0033:0x7f8028b77487
    [  556.575428] Code: Bad RIP value.
    [  556.576106] RSP: 002b:00007fff9f2e3598 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
    [  556.577599] RAX: 0000000000000000 RBX: 0000000000ebd030 RCX: 00007f8028b77487
    [  556.579020] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000ec41e0
    [  556.580422] RBP: 0000000000ec41e0 R08: 0000000000000000 R09: 0000000000000014
    [  556.581833] R10: 00000000000006b2 R11: 0000000000000246 R12: 00007f802908083c
    [  556.583252] R13: 0000000000000000 R14: 0000000000ebd210 R15: 00007fff9f2e3820
    
    [  556.584983] The buggy address belongs to the page:
    [  556.585961] page:ffffea0007ca4bc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
    [  556.587540] flags: 0x2ffff0000000000()
    [  556.588296] raw: 02ffff0000000000 0000000000000000 dead000000000200 0000000000000000
    [  556.589822] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
    [  556.591359] page dumped because: kasan: bad access detected
    
    [  556.592786] Memory state around the buggy address:
    [  556.593753]  ffff8801f292fc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [  556.595191]  ffff8801f292fc80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
    [  556.596613] >ffff8801f292fd00: 00 00 f3 00 00 00 00 f3 f3 00 00 00 00 f4 f4 f4
    [  556.598044]                          ^
    [  556.598797]  ffff8801f292fd80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
    [  556.600225]  ffff8801f292fe00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4
    [  556.601647] ==================================================================
    
    - Location
    https://elixir.bootlin.com/linux/v4.18-rc1/source/fs/f2fs/node.c#L987
                    case NODE_DIND_BLOCK:
                            err = truncate_nodes(&dn, nofs, offset[1], 3);
                            cont = 0;
                            break;
    
                    default:
                            BUG(); <---
                    }
    
    Reported-by Wen Xu <wen.xu@gatech.edu>
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f9cf5462b51d98026275cc51437fc531e808b64a
Author: Chao Yu <yuchao0@huawei.com>
Date:   Wed Jun 27 18:05:54 2018 +0800

    f2fs: fix to do sanity check with user_block_count
    
    commit 9dc956b2c8523aed39d1e6508438be9fea28c8fc upstream.
    
    This patch fixs to do sanity check with user_block_count.
    
    - Overview
    Divide zero in utilization when mount() a corrupted f2fs image
    
    - Reproduce (4.18 upstream kernel)
    
    - Kernel message
    [  564.099503] F2FS-fs (loop0): invalid crc value
    [  564.101991] divide error: 0000 [#1] SMP KASAN PTI
    [  564.103103] CPU: 1 PID: 1298 Comm: f2fs_discard-7: Not tainted 4.18.0-rc1+ #4
    [  564.104584] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  564.106624] RIP: 0010:issue_discard_thread+0x248/0x5c0
    [  564.107692] Code: ff ff 48 8b bd e8 fe ff ff 41 8b 9d 4c 04 00 00 e8 cd b8 ad ff 41 8b 85 50 04 00 00 31 d2 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <48> f7 f3 83 f8 50 7e 16 41 c7 86 7c ff ff ff 01 00 00 00 41 c7 86
    [  564.111686] RSP: 0018:ffff8801f3117dc0 EFLAGS: 00010206
    [  564.112775] RAX: 0000000000000384 RBX: 0000000000000000 RCX: ffffffffb88c1e03
    [  564.114250] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffff8801e3aa4850
    [  564.115706] RBP: ffff8801f3117f00 R08: 1ffffffff751a1d0 R09: fffffbfff751a1d0
    [  564.117177] R10: 0000000000000001 R11: fffffbfff751a1d0 R12: 00000000fffffffc
    [  564.118634] R13: ffff8801e3aa4400 R14: ffff8801f3117ed8 R15: ffff8801e2050000
    [  564.120094] FS:  0000000000000000(0000) GS:ffff8801f6f00000(0000) knlGS:0000000000000000
    [  564.121748] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  564.122923] CR2: 000000000202b078 CR3: 00000001f11ac000 CR4: 00000000000006e0
    [  564.124383] Call Trace:
    [  564.124924]  ? __issue_discard_cmd+0x480/0x480
    [  564.125882]  ? __sched_text_start+0x8/0x8
    [  564.126756]  ? __kthread_parkme+0xcb/0x100
    [  564.127620]  ? kthread_blkcg+0x70/0x70
    [  564.128412]  kthread+0x180/0x1d0
    [  564.129105]  ? __issue_discard_cmd+0x480/0x480
    [  564.130029]  ? kthread_associate_blkcg+0x150/0x150
    [  564.131033]  ret_from_fork+0x35/0x40
    [  564.131794] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd mac_hid i2c_piix4 soundcore ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear 8139too crct10dif_pclmul crc32_pclmul qxl drm_kms_helper syscopyarea aesni_intel sysfillrect sysimgblt fb_sys_fops ttm drm aes_x86_64 crypto_simd cryptd 8139cp glue_helper mii pata_acpi floppy
    [  564.141798] ---[ end trace 4ce02f25ff7d3df5 ]---
    [  564.142773] RIP: 0010:issue_discard_thread+0x248/0x5c0
    [  564.143885] Code: ff ff 48 8b bd e8 fe ff ff 41 8b 9d 4c 04 00 00 e8 cd b8 ad ff 41 8b 85 50 04 00 00 31 d2 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <48> f7 f3 83 f8 50 7e 16 41 c7 86 7c ff ff ff 01 00 00 00 41 c7 86
    [  564.147776] RSP: 0018:ffff8801f3117dc0 EFLAGS: 00010206
    [  564.148856] RAX: 0000000000000384 RBX: 0000000000000000 RCX: ffffffffb88c1e03
    [  564.150424] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffff8801e3aa4850
    [  564.151906] RBP: ffff8801f3117f00 R08: 1ffffffff751a1d0 R09: fffffbfff751a1d0
    [  564.153463] R10: 0000000000000001 R11: fffffbfff751a1d0 R12: 00000000fffffffc
    [  564.154915] R13: ffff8801e3aa4400 R14: ffff8801f3117ed8 R15: ffff8801e2050000
    [  564.156405] FS:  0000000000000000(0000) GS:ffff8801f6f00000(0000) knlGS:0000000000000000
    [  564.158070] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  564.159279] CR2: 000000000202b078 CR3: 00000001f11ac000 CR4: 00000000000006e0
    [  564.161043] ==================================================================
    [  564.162587] BUG: KASAN: stack-out-of-bounds in from_kuid_munged+0x1d/0x50
    [  564.163994] Read of size 4 at addr ffff8801f3117c84 by task f2fs_discard-7:/1298
    
    [  564.165852] CPU: 1 PID: 1298 Comm: f2fs_discard-7: Tainted: G      D           4.18.0-rc1+ #4
    [  564.167593] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  564.169522] Call Trace:
    [  564.170057]  dump_stack+0x7b/0xb5
    [  564.170778]  print_address_description+0x70/0x290
    [  564.171765]  kasan_report+0x291/0x390
    [  564.172540]  ? from_kuid_munged+0x1d/0x50
    [  564.173408]  __asan_load4+0x78/0x80
    [  564.174148]  from_kuid_munged+0x1d/0x50
    [  564.174962]  do_notify_parent+0x1f5/0x4f0
    [  564.175808]  ? send_sigqueue+0x390/0x390
    [  564.176639]  ? css_set_move_task+0x152/0x340
    [  564.184197]  do_exit+0x1290/0x1390
    [  564.184950]  ? __issue_discard_cmd+0x480/0x480
    [  564.185884]  ? mm_update_next_owner+0x380/0x380
    [  564.186829]  ? __sched_text_start+0x8/0x8
    [  564.187672]  ? __kthread_parkme+0xcb/0x100
    [  564.188528]  ? kthread_blkcg+0x70/0x70
    [  564.189333]  ? kthread+0x180/0x1d0
    [  564.190052]  ? __issue_discard_cmd+0x480/0x480
    [  564.190983]  rewind_stack_do_exit+0x17/0x20
    
    [  564.192190] The buggy address belongs to the page:
    [  564.193213] page:ffffea0007cc45c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
    [  564.194856] flags: 0x2ffff0000000000()
    [  564.195644] raw: 02ffff0000000000 0000000000000000 dead000000000200 0000000000000000
    [  564.197247] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
    [  564.198826] page dumped because: kasan: bad access detected
    
    [  564.200299] Memory state around the buggy address:
    [  564.201306]  ffff8801f3117b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [  564.202779]  ffff8801f3117c00: 00 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3
    [  564.204252] >ffff8801f3117c80: f3 f3 f3 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
    [  564.205742]                    ^
    [  564.206424]  ffff8801f3117d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [  564.207908]  ffff8801f3117d80: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
    [  564.209389] ==================================================================
    [  564.231795] F2FS-fs (loop0): Mounted with checkpoint version = 2
    
    - Location
    https://elixir.bootlin.com/linux/v4.18-rc1/source/fs/f2fs/segment.h#L586
            return div_u64((u64)valid_user_blocks(sbi) * 100,
                                            sbi->user_block_count);
    Missing checks on sbi->user_block_count.
    
    Reported-by: Wen Xu <wen.xu@gatech.edu>
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0081c90ebacebb3a82d0d24bf0f42273ce2d902e
Author: Chao Yu <yuchao0@huawei.com>
Date:   Mon Jun 25 23:29:49 2018 +0800

    f2fs: fix to do sanity check with extra_attr feature
    
    commit 76d56d4ab4f2a9e4f085c7d77172194ddaccf7d2 upstream.
    
    If FI_EXTRA_ATTR is set in inode by fuzzing, inode.i_addr[0] will be
    parsed as inode.i_extra_isize, then in __recover_inline_status, inline
    data address will beyond boundary of page, result in accessing invalid
    memory.
    
    So in this condition, during reading inode page, let's do sanity check
    with EXTRA_ATTR feature of fs and extra_attr bit of inode, if they're
    inconsistent, deny to load this inode.
    
    - Overview
    Out-of-bound access in f2fs_iget() when mounting a corrupted f2fs image
    
    - Reproduce
    
    The following message will be got in KASAN build of 4.18 upstream kernel.
    [  819.392227] ==================================================================
    [  819.393901] BUG: KASAN: slab-out-of-bounds in f2fs_iget+0x736/0x1530
    [  819.395329] Read of size 4 at addr ffff8801f099c968 by task mount/1292
    
    [  819.397079] CPU: 1 PID: 1292 Comm: mount Not tainted 4.18.0-rc1+ #4
    [  819.397082] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  819.397088] Call Trace:
    [  819.397124]  dump_stack+0x7b/0xb5
    [  819.397154]  print_address_description+0x70/0x290
    [  819.397159]  kasan_report+0x291/0x390
    [  819.397163]  ? f2fs_iget+0x736/0x1530
    [  819.397176]  check_memory_region+0x139/0x190
    [  819.397182]  __asan_loadN+0xf/0x20
    [  819.397185]  f2fs_iget+0x736/0x1530
    [  819.397197]  f2fs_fill_super+0x1b4f/0x2b40
    [  819.397202]  ? f2fs_fill_super+0x1b4f/0x2b40
    [  819.397208]  ? f2fs_commit_super+0x1b0/0x1b0
    [  819.397227]  ? set_blocksize+0x90/0x140
    [  819.397241]  mount_bdev+0x1c5/0x210
    [  819.397245]  ? f2fs_commit_super+0x1b0/0x1b0
    [  819.397252]  f2fs_mount+0x15/0x20
    [  819.397256]  mount_fs+0x60/0x1a0
    [  819.397267]  ? alloc_vfsmnt+0x309/0x360
    [  819.397272]  vfs_kern_mount+0x6b/0x1a0
    [  819.397282]  do_mount+0x34a/0x18c0
    [  819.397300]  ? lockref_put_or_lock+0xcf/0x160
    [  819.397306]  ? copy_mount_string+0x20/0x20
    [  819.397318]  ? memcg_kmem_put_cache+0x1b/0xa0
    [  819.397324]  ? kasan_check_write+0x14/0x20
    [  819.397334]  ? _copy_from_user+0x6a/0x90
    [  819.397353]  ? memdup_user+0x42/0x60
    [  819.397359]  ksys_mount+0x83/0xd0
    [  819.397365]  __x64_sys_mount+0x67/0x80
    [  819.397388]  do_syscall_64+0x78/0x170
    [  819.397403]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  819.397422] RIP: 0033:0x7f54c667cb9a
    [  819.397424] Code: 48 8b 0d 01 c3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ce c2 2b 00 f7 d8 64 89 01 48
    [  819.397483] RSP: 002b:00007ffd8f46cd08 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
    [  819.397496] RAX: ffffffffffffffda RBX: 0000000000dfa030 RCX: 00007f54c667cb9a
    [  819.397498] RDX: 0000000000dfa210 RSI: 0000000000dfbf30 RDI: 0000000000e02ec0
    [  819.397501] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000013
    [  819.397503] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000000000e02ec0
    [  819.397505] R13: 0000000000dfa210 R14: 0000000000000000 R15: 0000000000000003
    
    [  819.397866] Allocated by task 139:
    [  819.398702]  save_stack+0x46/0xd0
    [  819.398705]  kasan_kmalloc+0xad/0xe0
    [  819.398709]  kasan_slab_alloc+0x11/0x20
    [  819.398713]  kmem_cache_alloc+0xd1/0x1e0
    [  819.398717]  dup_fd+0x50/0x4c0
    [  819.398740]  copy_process.part.37+0xbed/0x32e0
    [  819.398744]  _do_fork+0x16e/0x590
    [  819.398748]  __x64_sys_clone+0x69/0x80
    [  819.398752]  do_syscall_64+0x78/0x170
    [  819.398756]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    [  819.399097] Freed by task 159:
    [  819.399743]  save_stack+0x46/0xd0
    [  819.399747]  __kasan_slab_free+0x13c/0x1a0
    [  819.399750]  kasan_slab_free+0xe/0x10
    [  819.399754]  kmem_cache_free+0x89/0x1e0
    [  819.399757]  put_files_struct+0x132/0x150
    [  819.399761]  exit_files+0x62/0x70
    [  819.399766]  do_exit+0x47b/0x1390
    [  819.399770]  do_group_exit+0x86/0x130
    [  819.399774]  __x64_sys_exit_group+0x2c/0x30
    [  819.399778]  do_syscall_64+0x78/0x170
    [  819.399782]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    [  819.400115] The buggy address belongs to the object at ffff8801f099c680
                    which belongs to the cache files_cache of size 704
    [  819.403234] The buggy address is located 40 bytes to the right of
                    704-byte region [ffff8801f099c680, ffff8801f099c940)
    [  819.405689] The buggy address belongs to the page:
    [  819.406709] page:ffffea0007c26700 count:1 mapcount:0 mapping:ffff8801f69a3340 index:0xffff8801f099d380 compound_mapcount: 0
    [  819.408984] flags: 0x2ffff0000008100(slab|head)
    [  819.409932] raw: 02ffff0000008100 ffffea00077fb600 0000000200000002 ffff8801f69a3340
    [  819.411514] raw: ffff8801f099d380 0000000080130000 00000001ffffffff 0000000000000000
    [  819.413073] page dumped because: kasan: bad access detected
    
    [  819.414539] Memory state around the buggy address:
    [  819.415521]  ffff8801f099c800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  819.416981]  ffff8801f099c880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  819.418454] >ffff8801f099c900: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [  819.419921]                                                           ^
    [  819.421265]  ffff8801f099c980: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
    [  819.422745]  ffff8801f099ca00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  819.424206] ==================================================================
    [  819.425668] Disabling lock debugging due to kernel taint
    [  819.457463] F2FS-fs (loop0): Mounted with checkpoint version = 3
    
    The kernel still mounts the image. If you run the following program on the mounted folder mnt,
    
    (poc.c)
    
    static void activity(char *mpoint) {
    
      char *foo_bar_baz;
      int err;
    
      static int buf[8192];
      memset(buf, 0, sizeof(buf));
    
      err = asprintf(&foo_bar_baz, "%s/foo/bar/baz", mpoint);
        int fd = open(foo_bar_baz, O_RDONLY, 0);
      if (fd >= 0) {
          read(fd, (char *)buf, 11);
          close(fd);
      }
    }
    
    int main(int argc, char *argv[]) {
      activity(argv[1]);
      return 0;
    }
    
    You can get kernel crash:
    [  819.457463] F2FS-fs (loop0): Mounted with checkpoint version = 3
    [  918.028501] BUG: unable to handle kernel paging request at ffffed0048000d82
    [  918.044020] PGD 23ffee067 P4D 23ffee067 PUD 23fbef067 PMD 0
    [  918.045207] Oops: 0000 [#1] SMP KASAN PTI
    [  918.046048] CPU: 0 PID: 1309 Comm: poc Tainted: G    B             4.18.0-rc1+ #4
    [  918.047573] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  918.049552] RIP: 0010:check_memory_region+0x5e/0x190
    [  918.050565] Code: f8 49 c1 e8 03 49 89 db 49 c1 eb 03 4d 01 cb 4d 01 c1 4d 8d 63 01 4c 89 c8 4d 89 e2 4d 29 ca 49 83 fa 10 7f 3d 4d 85 d2 74 32 <41> 80 39 00 75 23 48 b8 01 00 00 00 00 fc ff df 4d 01 d1 49 01 c0
    [  918.054322] RSP: 0018:ffff8801e3a1f258 EFLAGS: 00010202
    [  918.055400] RAX: ffffed0048000d82 RBX: ffff880240006c11 RCX: ffffffffb8867d14
    [  918.056832] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff880240006c10
    [  918.058253] RBP: ffff8801e3a1f268 R08: 1ffff10048000d82 R09: ffffed0048000d82
    [  918.059717] R10: 0000000000000001 R11: ffffed0048000d82 R12: ffffed0048000d83
    [  918.061159] R13: ffff8801e3a1f390 R14: 0000000000000000 R15: ffff880240006c08
    [  918.062614] FS:  00007fac9732c700(0000) GS:ffff8801f6e00000(0000) knlGS:0000000000000000
    [  918.064246] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  918.065412] CR2: ffffed0048000d82 CR3: 00000001df77a000 CR4: 00000000000006f0
    [  918.066882] Call Trace:
    [  918.067410]  __asan_loadN+0xf/0x20
    [  918.068149]  f2fs_find_target_dentry+0xf4/0x270
    [  918.069083]  ? __get_node_page+0x331/0x5b0
    [  918.069925]  f2fs_find_in_inline_dir+0x24b/0x310
    [  918.070881]  ? f2fs_recover_inline_data+0x4c0/0x4c0
    [  918.071905]  ? unwind_next_frame.part.5+0x34f/0x490
    [  918.072901]  ? unwind_dump+0x290/0x290
    [  918.073695]  ? is_bpf_text_address+0xe/0x20
    [  918.074566]  __f2fs_find_entry+0x599/0x670
    [  918.075408]  ? kasan_unpoison_shadow+0x36/0x50
    [  918.076315]  ? kasan_kmalloc+0xad/0xe0
    [  918.077100]  ? memcg_kmem_put_cache+0x55/0xa0
    [  918.077998]  ? f2fs_find_target_dentry+0x270/0x270
    [  918.079006]  ? d_set_d_op+0x30/0x100
    [  918.079749]  ? __d_lookup_rcu+0x69/0x2e0
    [  918.080556]  ? __d_alloc+0x275/0x450
    [  918.081297]  ? kasan_check_write+0x14/0x20
    [  918.082135]  ? memset+0x31/0x40
    [  918.082820]  ? fscrypt_setup_filename+0x1ec/0x4c0
    [  918.083782]  ? d_alloc_parallel+0x5bb/0x8c0
    [  918.084640]  f2fs_find_entry+0xe9/0x110
    [  918.085432]  ? __f2fs_find_entry+0x670/0x670
    [  918.086308]  ? kasan_check_write+0x14/0x20
    [  918.087163]  f2fs_lookup+0x297/0x590
    [  918.087902]  ? f2fs_link+0x2b0/0x2b0
    [  918.088646]  ? legitimize_path.isra.29+0x61/0xa0
    [  918.089589]  __lookup_slow+0x12e/0x240
    [  918.090371]  ? may_delete+0x2b0/0x2b0
    [  918.091123]  ? __nd_alloc_stack+0xa0/0xa0
    [  918.091944]  lookup_slow+0x44/0x60
    [  918.092642]  walk_component+0x3ee/0xa40
    [  918.093428]  ? is_bpf_text_address+0xe/0x20
    [  918.094283]  ? pick_link+0x3e0/0x3e0
    [  918.095047]  ? in_group_p+0xa5/0xe0
    [  918.095771]  ? generic_permission+0x53/0x1e0
    [  918.096666]  ? security_inode_permission+0x1d/0x70
    [  918.097646]  ? inode_permission+0x7a/0x1f0
    [  918.098497]  link_path_walk+0x2a2/0x7b0
    [  918.099298]  ? apparmor_capget+0x3d0/0x3d0
    [  918.100140]  ? walk_component+0xa40/0xa40
    [  918.100958]  ? path_init+0x2e6/0x580
    [  918.101695]  path_openat+0x1bb/0x2160
    [  918.102471]  ? __save_stack_trace+0x92/0x100
    [  918.103352]  ? save_stack+0xb5/0xd0
    [  918.104070]  ? vfs_unlink+0x250/0x250
    [  918.104822]  ? save_stack+0x46/0xd0
    [  918.105538]  ? kasan_slab_alloc+0x11/0x20
    [  918.106370]  ? kmem_cache_alloc+0xd1/0x1e0
    [  918.107213]  ? getname_flags+0x76/0x2c0
    [  918.107997]  ? getname+0x12/0x20
    [  918.108677]  ? do_sys_open+0x14b/0x2c0
    [  918.109450]  ? __x64_sys_open+0x4c/0x60
    [  918.110255]  ? do_syscall_64+0x78/0x170
    [  918.111083]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  918.112148]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  918.113204]  ? f2fs_empty_inline_dir+0x1e0/0x1e0
    [  918.114150]  ? timespec64_trunc+0x5c/0x90
    [  918.114993]  ? wb_io_lists_depopulated+0x1a/0xc0
    [  918.115937]  ? inode_io_list_move_locked+0x102/0x110
    [  918.116949]  do_filp_open+0x12b/0x1d0
    [  918.117709]  ? may_open_dev+0x50/0x50
    [  918.118475]  ? kasan_kmalloc+0xad/0xe0
    [  918.119246]  do_sys_open+0x17c/0x2c0
    [  918.119983]  ? do_sys_open+0x17c/0x2c0
    [  918.120751]  ? filp_open+0x60/0x60
    [  918.121463]  ? task_work_run+0x4d/0xf0
    [  918.122237]  __x64_sys_open+0x4c/0x60
    [  918.123001]  do_syscall_64+0x78/0x170
    [  918.123759]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  918.124802] RIP: 0033:0x7fac96e3e040
    [  918.125537] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 83 3d 09 27 2d 00 00 75 10 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 7e e0 01 00 48 89 04 24
    [  918.129341] RSP: 002b:00007fff1b37f848 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
    [  918.130870] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fac96e3e040
    [  918.132295] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000122d080
    [  918.133748] RBP: 00007fff1b37f9b0 R08: 00007fac9710bbd8 R09: 0000000000000001
    [  918.135209] R10: 000000000000069d R11: 0000000000000246 R12: 0000000000400c20
    [  918.136650] R13: 00007fff1b37fab0 R14: 0000000000000000 R15: 0000000000000000
    [  918.138093] Modules linked in: snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd mac_hid i2c_piix4 soundcore ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear 8139too crct10dif_pclmul crc32_pclmul qxl drm_kms_helper syscopyarea aesni_intel sysfillrect sysimgblt fb_sys_fops ttm drm aes_x86_64 crypto_simd cryptd 8139cp glue_helper mii pata_acpi floppy
    [  918.147924] CR2: ffffed0048000d82
    [  918.148619] ---[ end trace 4ce02f25ff7d3df5 ]---
    [  918.149563] RIP: 0010:check_memory_region+0x5e/0x190
    [  918.150576] Code: f8 49 c1 e8 03 49 89 db 49 c1 eb 03 4d 01 cb 4d 01 c1 4d 8d 63 01 4c 89 c8 4d 89 e2 4d 29 ca 49 83 fa 10 7f 3d 4d 85 d2 74 32 <41> 80 39 00 75 23 48 b8 01 00 00 00 00 fc ff df 4d 01 d1 49 01 c0
    [  918.154360] RSP: 0018:ffff8801e3a1f258 EFLAGS: 00010202
    [  918.155411] RAX: ffffed0048000d82 RBX: ffff880240006c11 RCX: ffffffffb8867d14
    [  918.156833] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff880240006c10
    [  918.158257] RBP: ffff8801e3a1f268 R08: 1ffff10048000d82 R09: ffffed0048000d82
    [  918.159722] R10: 0000000000000001 R11: ffffed0048000d82 R12: ffffed0048000d83
    [  918.161149] R13: ffff8801e3a1f390 R14: 0000000000000000 R15: ffff880240006c08
    [  918.162587] FS:  00007fac9732c700(0000) GS:ffff8801f6e00000(0000) knlGS:0000000000000000
    [  918.164203] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  918.165356] CR2: ffffed0048000d82 CR3: 00000001df77a000 CR4: 00000000000006f0
    
    Reported-by: Wen Xu <wen.xu@gatech.edu>
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    [bwh: Backported to 4.14: adjust context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2598fc56ed65f69e303ccee6d5fe756a56f87779
Author: Ben Hutchings <ben.hutchings@codethink.co.uk>
Date:   Thu Nov 29 19:17:34 2018 +0000

    f2fs: Add sanity_check_inode() function
    
    This was done as part of commit 5d64600d4f33 "f2fs: avoid bug_on on
    corrupted inode" upstream, but the specific check that commit added is
    not applicable to 4.14.
    
    Cc: Jaegeuk Kim <jaegeuk@kernel.org>
    Cc: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3d6361a96a455c8ba12226a04efa67a0ada4966
Author: Chao Yu <yuchao0@huawei.com>
Date:   Sat Jun 23 00:12:36 2018 +0800

    f2fs: fix to do sanity check with secs_per_zone
    
    commit 42bf546c1fe3f3654bdf914e977acbc2b80a5be5 upstream.
    
    As Wen Xu reported in below link:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=200183
    
    - Overview
    Divide zero in reset_curseg() when mounting a crafted f2fs image
    
    - Reproduce
    
    - Kernel message
    [  588.281510] divide error: 0000 [#1] SMP KASAN PTI
    [  588.282701] CPU: 0 PID: 1293 Comm: mount Not tainted 4.18.0-rc1+ #4
    [  588.284000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  588.286178] RIP: 0010:reset_curseg+0x94/0x1a0
    [  588.298166] RSP: 0018:ffff8801e88d7940 EFLAGS: 00010246
    [  588.299360] RAX: 0000000000000014 RBX: ffff8801e1d46d00 RCX: ffffffffb88bf60b
    [  588.300809] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffff8801e1d46d64
    [  588.305272] R13: 0000000000000000 R14: 0000000000000014 R15: 0000000000000000
    [  588.306822] FS:  00007fad85008840(0000) GS:ffff8801f6e00000(0000) knlGS:0000000000000000
    [  588.308456] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  588.309623] CR2: 0000000001705078 CR3: 00000001f30f8000 CR4: 00000000000006f0
    [  588.311085] Call Trace:
    [  588.311637]  f2fs_build_segment_manager+0x103f/0x3410
    [  588.316136]  ? f2fs_commit_super+0x1b0/0x1b0
    [  588.317031]  ? set_blocksize+0x90/0x140
    [  588.319473]  f2fs_mount+0x15/0x20
    [  588.320166]  mount_fs+0x60/0x1a0
    [  588.320847]  ? alloc_vfsmnt+0x309/0x360
    [  588.321647]  vfs_kern_mount+0x6b/0x1a0
    [  588.322432]  do_mount+0x34a/0x18c0
    [  588.323175]  ? strndup_user+0x46/0x70
    [  588.323937]  ? copy_mount_string+0x20/0x20
    [  588.324793]  ? memcg_kmem_put_cache+0x1b/0xa0
    [  588.325702]  ? kasan_check_write+0x14/0x20
    [  588.326562]  ? _copy_from_user+0x6a/0x90
    [  588.327375]  ? memdup_user+0x42/0x60
    [  588.328118]  ksys_mount+0x83/0xd0
    [  588.328808]  __x64_sys_mount+0x67/0x80
    [  588.329607]  do_syscall_64+0x78/0x170
    [  588.330400]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  588.331461] RIP: 0033:0x7fad848e8b9a
    [  588.336022] RSP: 002b:00007ffd7c5b6be8 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
    [  588.337547] RAX: ffffffffffffffda RBX: 00000000016f8030 RCX: 00007fad848e8b9a
    [  588.338999] RDX: 00000000016f8210 RSI: 00000000016f9f30 RDI: 0000000001700ec0
    [  588.340442] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000013
    [  588.341887] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000000001700ec0
    [  588.343341] R13: 00000000016f8210 R14: 0000000000000000 R15: 0000000000000003
    [  588.354891] ---[ end trace 4ce02f25ff7d3df5 ]---
    [  588.355862] RIP: 0010:reset_curseg+0x94/0x1a0
    [  588.360742] RSP: 0018:ffff8801e88d7940 EFLAGS: 00010246
    [  588.361812] RAX: 0000000000000014 RBX: ffff8801e1d46d00 RCX: ffffffffb88bf60b
    [  588.363485] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffff8801e1d46d64
    [  588.365213] RBP: ffff8801e88d7968 R08: ffffed003c32266f R09: ffffed003c32266f
    [  588.366661] R10: 0000000000000001 R11: ffffed003c32266e R12: ffff8801f0337700
    [  588.368110] R13: 0000000000000000 R14: 0000000000000014 R15: 0000000000000000
    [  588.370057] FS:  00007fad85008840(0000) GS:ffff8801f6e00000(0000) knlGS:0000000000000000
    [  588.372099] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  588.373291] CR2: 0000000001705078 CR3: 00000001f30f8000 CR4: 00000000000006f0
    
    - Location
    https://elixir.bootlin.com/linux/latest/source/fs/f2fs/segment.c#L2147
            curseg->zone = GET_ZONE_FROM_SEG(sbi, curseg->segno);
    
    If secs_per_zone is corrupted due to fuzzing test, it will cause divide
    zero operation when using GET_ZONE_FROM_SEG macro, so we should do more
    sanity check with secs_per_zone during mount to avoid this issue.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eea715704673314769f2613b1ead310306b7de05
Author: Chao Yu <yuchao0@huawei.com>
Date:   Tue Jun 5 17:44:11 2018 +0800

    f2fs: introduce and spread verify_blkaddr
    
    commit e1da7872f6eda977bd812346bf588c35e4495a1e upstream.
    
    This patch introduces verify_blkaddr to check meta/data block address
    with valid range to detect bug earlier.
    
    In addition, once we encounter an invalid blkaddr, notice user to run
    fsck to fix, and let the kernel panic.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    [bwh: Backported to 4.14: I skipped an earlier renaming of
     is_valid_meta_blkaddr() to f2fs_is_valid_meta_blkaddr()]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e6c4a8557e27c4f074a47e27ce981edfb1f8b91
Author: Chao Yu <yuchao0@huawei.com>
Date:   Wed May 23 22:25:08 2018 +0800

    f2fs: clean up with is_valid_blkaddr()
    
    commit 7b525dd01365c6764018e374d391c92466be1b7a upstream.
    
    - rename is_valid_blkaddr() to is_valid_meta_blkaddr() for readability.
    - introduce is_valid_blkaddr() for cleanup.
    
    No logic change in this patch.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e60b97231950fb5b55d2a981b080e3a6f7516a00
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Fri Apr 27 19:03:22 2018 -0700

    f2fs: enhance sanity_check_raw_super() to avoid potential overflow
    
    commit 0cfe75c5b011994651a4ca6d74f20aa997bfc69a upstream.
    
    In order to avoid the below overflow issue, we should have checked the
    boundaries in superblock before reaching out to allocation. As Linus suggested,
    the right place should be sanity_check_raw_super().
    
    Dr Silvio Cesare of InfoSect reported:
    
    There are integer overflows with using the cp_payload superblock field in the
    f2fs filesystem potentially leading to memory corruption.
    
    include/linux/f2fs_fs.h
    
    struct f2fs_super_block {
    ...
            __le32 cp_payload;
    
    fs/f2fs/f2fs.h
    
    typedef u32 block_t;    /*
                             * should not change u32, since it is the on-disk block
                             * address format, __le32.
                             */
    ...
    
    static inline block_t __cp_payload(struct f2fs_sb_info *sbi)
    {
            return le32_to_cpu(F2FS_RAW_SUPER(sbi)->cp_payload);
    }
    
    fs/f2fs/checkpoint.c
    
            block_t start_blk, orphan_blocks, i, j;
    ...
            start_blk = __start_cp_addr(sbi) + 1 + __cp_payload(sbi);
            orphan_blocks = __start_sum_addr(sbi) - 1 - __cp_payload(sbi);
    
    +++ integer overflows
    
    ...
            unsigned int cp_blks = 1 + __cp_payload(sbi);
    ...
            sbi->ckpt = kzalloc(cp_blks * blk_size, GFP_KERNEL);
    
    +++ integer overflow leading to incorrect heap allocation.
    
            int cp_payload_blks = __cp_payload(sbi);
    ...
            ckpt->cp_pack_start_sum = cpu_to_le32(1 + cp_payload_blks +
                            orphan_blocks);
    
    +++ sign bug and integer overflow
    
    ...
            for (i = 1; i < 1 + cp_payload_blks; i++)
    
    +++ integer overflow
    
    ...
    
          sbi->max_orphans = (sbi->blocks_per_seg - F2FS_CP_PACKS -
                            NR_CURSEG_TYPE - __cp_payload(sbi)) *
                                    F2FS_ORPHANS_PER_BLOCK;
    
    +++ integer overflow
    
    Reported-by: Greg KH <greg@kroah.com>
    Reported-by: Silvio Cesare <silvio.cesare@gmail.com>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    [bwh: Backported to 4.14: No hot file extension support]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8f40be69f80c7c5f969ae5cd93497dc7a764358
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Tue Apr 24 15:44:16 2018 -0600

    f2fs: sanity check on sit entry
    
    commit b2ca374f33bd33fd822eb871876e4888cf79dc97 upstream.
    
    syzbot hit the following crash on upstream commit
    87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +0000)
    Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client
    syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=83699adeb2d13579c31e
    
    C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5805208181407744
    syzkaller reproducer: https://syzkaller.appspot.com/x/repro.syz?id=6005073343676416
    Raw console output: https://syzkaller.appspot.com/x/log.txt?id=6555047731134464
    Kernel config: https://syzkaller.appspot.com/x/.config?id=1808800213120130118
    compiler: gcc (GCC) 8.0.1 20180413 (experimental)
    
    IMPORTANT: if you fix the bug, please add the following tag to the commit:
    Reported-by: syzbot+83699adeb2d13579c31e@syzkaller.appspotmail.com
    It will help syzbot understand when the bug is fixed. See footer for details.
    If you forward the report, please keep this part and the footer.
    
    F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0x0)
    F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
    F2FS-fs (loop0): invalid crc value
    BUG: unable to handle kernel paging request at ffffed006b2a50c0
    PGD 21ffee067 P4D 21ffee067 PUD 21fbeb067 PMD 0
    Oops: 0000 [#1] SMP KASAN
    Dumping ftrace buffer:
       (ftrace buffer empty)
    Modules linked in:
    CPU: 0 PID: 4514 Comm: syzkaller989480 Not tainted 4.17.0-rc1+ #8
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:build_sit_entries fs/f2fs/segment.c:3653 [inline]
    RIP: 0010:build_segment_manager+0x7ef7/0xbf70 fs/f2fs/segment.c:3852
    RSP: 0018:ffff8801b102e5b0 EFLAGS: 00010a06
    RAX: 1ffff1006b2a50c0 RBX: 0000000000000004 RCX: 0000000000000001
    RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8801ac74243e
    RBP: ffff8801b102f410 R08: ffff8801acbd46c0 R09: fffffbfff14d9af8
    R10: fffffbfff14d9af8 R11: ffff8801acbd46c0 R12: ffff8801ac742a80
    R13: ffff8801d9519100 R14: dffffc0000000000 R15: ffff880359528600
    FS:  0000000001e04880(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffed006b2a50c0 CR3: 00000001ac6ac000 CR4: 00000000001406f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     f2fs_fill_super+0x4095/0x7bf0 fs/f2fs/super.c:2803
     mount_bdev+0x30c/0x3e0 fs/super.c:1165
     f2fs_mount+0x34/0x40 fs/f2fs/super.c:3020
     mount_fs+0xae/0x328 fs/super.c:1268
     vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
     vfs_kern_mount fs/namespace.c:1027 [inline]
     do_new_mount fs/namespace.c:2517 [inline]
     do_mount+0x564/0x3070 fs/namespace.c:2847
     ksys_mount+0x12d/0x140 fs/namespace.c:3063
     __do_sys_mount fs/namespace.c:3077 [inline]
     __se_sys_mount fs/namespace.c:3074 [inline]
     __x64_sys_mount+0xbe/0x150 fs/namespace.c:3074
     do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x443d6a
    RSP: 002b:00007ffd312813c8 EFLAGS: 00000297 ORIG_RAX: 00000000000000a5
    RAX: ffffffffffffffda RBX: 0000000020000c00 RCX: 0000000000443d6a
    RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd312813d0
    RBP: 0000000000000003 R08: 0000000020016a00 R09: 000000000000000a
    R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000004
    R13: 0000000000402c60 R14: 0000000000000000 R15: 0000000000000000
    RIP: build_sit_entries fs/f2fs/segment.c:3653 [inline] RSP: ffff8801b102e5b0
    RIP: build_segment_manager+0x7ef7/0xbf70 fs/f2fs/segment.c:3852 RSP: ffff8801b102e5b0
    CR2: ffffed006b2a50c0
    ---[ end trace a2034989e196ff17 ]---
    
    Reported-and-tested-by: syzbot+83699adeb2d13579c31e@syzkaller.appspotmail.com
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aec6ccb3dcc1ad9b8cfe12d086430ffcce887dda
Author: Yunlei He <heyunlei@huawei.com>
Date:   Thu Mar 8 16:29:13 2018 +0800

    f2fs: check blkaddr more accuratly before issue a bio
    
    commit 0833721ec3658a4e9d5e58b6fa82cf9edc431e59 upstream.
    
    This patch check blkaddr more accuratly before issue a
    write or read bio.
    
    Signed-off-by: Yunlei He <heyunlei@huawei.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b356df11ba2b44627e2fad7441e05abee46a628
Author: Shaokun Zhang <zhangshaokun@hisilicon.com>
Date:   Mon Nov 5 18:49:09 2018 +0800

    btrfs: tree-checker: Fix misleading group system information
    
    commit 761333f2f50ccc887aa9957ae829300262c0d15b upstream.
    
    block_group_err shows the group system as a decimal value with a '0x'
    prefix, which is somewhat misleading.
    
    Fix it to print hexadecimal, as was intended.
    
    Fixes: fce466eab7ac6 ("btrfs: tree-checker: Verify block_group_item")
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cf968bbccba9860eef9480ae560711fbc5cbc1b5
Author: Qu Wenruo <wqu@suse.com>
Date:   Fri Sep 28 07:59:34 2018 +0800

    btrfs: tree-checker: Check level for leaves and nodes
    
    commit f556faa46eb4e96d0d0772e74ecf66781e132f72 upstream.
    
    Although we have tree level check at tree read runtime, it's completely
    based on its parent level.
    We still need to do accurate level check to avoid invalid tree blocks
    sneak into kernel space.
    
    The check itself is simple, for leaf its level should always be 0.
    For nodes its level should be in range [1, BTRFS_MAX_LEVEL - 1].
    
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Su Yue <suy.fnst@cn.fujitsu.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    [bwh: Backported to 4.14:
     - Pass root instead of fs_info to generic_err()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34407a175a59b668a1a2bbf0d0e495d87a7777d8
Author: Qu Wenruo <wqu@suse.com>
Date:   Wed Aug 1 10:37:16 2018 +0800

    btrfs: Check that each block group has corresponding chunk at mount time
    
    commit 514c7dca85a0bf40be984dab0b477403a6db901f upstream.
    
    A crafted btrfs image with incorrect chunk<->block group mapping will
    trigger a lot of unexpected things as the mapping is essential.
    
    Although the problem can be caught by block group item checker
    added in "btrfs: tree-checker: Verify block_group_item", it's still not
    sufficient.  A sufficiently valid block group item can pass the check
    added by the mentioned patch but could fail to match the existing chunk.
    
    This patch will add extra block group -> chunk mapping check, to ensure
    we have a completely matching (start, len, flags) chunk for each block
    group at mount time.
    
    Here we reuse the original helper find_first_block_group(), which is
    already doing the basic bg -> chunk checks, adding further checks of the
    start/len and type flags.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199837
    Reported-by: Xu Wen <wen.xu@gatech.edu>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Su Yue <suy.fnst@cn.fujitsu.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0dfb99847851fb830d1e8ea7d5e0571f50c325a
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Jul 3 17:10:06 2018 +0800

    btrfs: tree-checker: Detect invalid and empty essential trees
    
    commit ba480dd4db9f1798541eb2d1c423fc95feee8d36 upstream.
    
    A crafted image has empty root tree block, which will later cause NULL
    pointer dereference.
    
    The following trees should never be empty:
    1) Tree root
       Must contain at least root items for extent tree, device tree and fs
       tree
    
    2) Chunk tree
       Or we can't even bootstrap as it contains the mapping.
    
    3) Fs tree
       At least inode item for top level inode (.).
    
    4) Device tree
       Dev extents for chunks
    
    5) Extent tree
       Must have corresponding extent for each chunk.
    
    If any of them is empty, we are sure the fs is corrupted and no need to
    mount it.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199847
    Reported-by: Xu Wen <wen.xu@gatech.edu>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Tested-by: Gu Jinxiang <gujx@cn.fujitsu.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    [bwh: Backported to 4.14: Pass root instead of fs_info to generic_err()]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f268b5cf2d6a716779dfe11f4bc02d6461db693
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Jul 3 17:10:05 2018 +0800

    btrfs: tree-checker: Verify block_group_item
    
    commit fce466eab7ac6baa9d2dcd88abcf945be3d4a089 upstream.
    
    A crafted image with invalid block group items could make free space cache
    code to cause panic.
    
    We could detect such invalid block group item by checking:
    1) Item size
       Known fixed value.
    2) Block group size (key.offset)
       We have an upper limit on block group item (10G)
    3) Chunk objectid
       Known fixed value.
    4) Type
       Only 4 valid type values, DATA, METADATA, SYSTEM and DATA|METADATA.
       No more than 1 bit set for profile type.
    5) Used space
       No more than the block group size.
    
    This should allow btrfs to detect and refuse to mount the crafted image.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199849
    Reported-by: Xu Wen <wen.xu@gatech.edu>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Gu Jinxiang <gujx@cn.fujitsu.com>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Tested-by: Gu Jinxiang <gujx@cn.fujitsu.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    [bwh: Backported to 4.14:
     - In check_leaf_item(), pass root->fs_info to check_block_group_item()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e07e1c7561a7e087a5e512c972aa7d3e1388c057
Author: David Sterba <dsterba@suse.com>
Date:   Wed Jan 10 15:13:07 2018 +0100

    btrfs: tree-check: reduce stack consumption in check_dir_item
    
    commit e2683fc9d219430f5b78889b50cde7f40efeba7b upstream.
    
    I've noticed that the updated item checker stack consumption increased
    dramatically in 542f5385e20cf97447 ("btrfs: tree-checker: Add checker
    for dir item")
    
    tree-checker.c:check_leaf                    +552 (176 -> 728)
    
    The array is 255 bytes long, dynamic allocation would slow down the
    sanity checks so it's more reasonable to keep it on-stack. Moving the
    variable to the scope of use reduces the stack usage again
    
    tree-checker.c:check_leaf                    -264 (728 -> 464)
    
    Reviewed-by: Josef Bacik <jbacik@fb.com>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52ea16655aeed2571b9042c18db3eb089c37910c
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Dec 6 15:18:14 2017 +0100

    btrfs: tree-checker: use %zu format string for size_t
    
    commit 7cfad65297bfe0aa2996cd72d21c898aa84436d9 upstream.
    
    The return value of sizeof() is of type size_t, so we must print it
    using the %z format modifier rather than %l to avoid this warning
    on some architectures:
    
    fs/btrfs/tree-checker.c: In function 'check_dir_item':
    fs/btrfs/tree-checker.c:273:50: error: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'u32' {aka 'unsigned int'} [-Werror=format=]
    
    Fixes: 005887f2e3e0 ("btrfs: tree-checker: Add checker for dir item")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe09fe216e502b17716689721a5c59d6a21277ac
Author: Qu Wenruo <wqu@suse.com>
Date:   Wed Nov 8 08:54:25 2017 +0800

    btrfs: tree-checker: Add checker for dir item
    
    commit ad7b0368f33cffe67fecd302028915926e50ef7e upstream.
    
    Add checker for dir item, for key types DIR_ITEM, DIR_INDEX and
    XATTR_ITEM.
    
    This checker does comprehensive checks for:
    
    1) dir_item header and its data size
       Against item boundary and maximum name/xattr length.
       This part is mostly the same as old verify_dir_item().
    
    2) dir_type
       Against maximum file types, and against key type.
       Since XATTR key should only have FT_XATTR dir item, and normal dir
       item type should not have XATTR key.
    
       The check between key->type and dir_type is newly introduced by this
       patch.
    
    3) name hash
       For XATTR and DIR_ITEM key, key->offset is name hash (crc32c).
       Check the hash of the name against the key to ensure it's correct.
    
       The name hash check is only found in btrfs-progs before this patch.
    
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: Su Yue <suy.fnst@cn.fujitsu.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6a07f903543e45d3660d5fbc8385f89da763c81
Author: Qu Wenruo <wqu@suse.com>
Date:   Wed Nov 8 08:54:24 2017 +0800

    btrfs: tree-checker: Fix false panic for sanity test
    
    commit 69fc6cbbac542c349b3d350d10f6e394c253c81d upstream.
    
    [BUG]
    If we run btrfs with CONFIG_BTRFS_FS_RUN_SANITY_TESTS=y, it will
    instantly cause kernel panic like:
    
    ------
    ...
    assertion failed: 0, file: fs/btrfs/disk-io.c, line: 3853
    ...
    Call Trace:
     btrfs_mark_buffer_dirty+0x187/0x1f0 [btrfs]
     setup_items_for_insert+0x385/0x650 [btrfs]
     __btrfs_drop_extents+0x129a/0x1870 [btrfs]
    ...
    -----
    
    [Cause]
    Btrfs will call btrfs_check_leaf() in btrfs_mark_buffer_dirty() to check
    if the leaf is valid with CONFIG_BTRFS_FS_RUN_SANITY_TESTS=y.
    
    However quite some btrfs_mark_buffer_dirty() callers(*) don't really
    initialize its item data but only initialize its item pointers, leaving
    item data uninitialized.
    
    This makes tree-checker catch uninitialized data as error, causing
    such panic.
    
    *: These callers include but not limited to
    setup_items_for_insert()
    btrfs_split_item()
    btrfs_expand_item()
    
    [Fix]
    Add a new parameter @check_item_data to btrfs_check_leaf().
    With @check_item_data set to false, item data check will be skipped and
    fallback to old btrfs_check_leaf() behavior.
    
    So we can still get early warning if we screw up item pointers, and
    avoid false panic.
    
    Cc: Filipe Manana <fdmanana@gmail.com>
    Reported-by: Lakshmipathi.G <lakshmipathi.g@gmail.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3032dc25fb4d7ffdbb61df875cc09b3ec662c85
Author: Qu Wenruo <quwenruo.btrfs@gmx.com>
Date:   Mon Oct 9 01:51:03 2017 +0000

    btrfs: tree-checker: Enhance btrfs_check_node output
    
    commit bba4f29896c986c4cec17bc0f19f2ce644fceae1 upstream.
    
    Use inline function to replace macro since we don't need
    stringification.
    (Macro still exists until all callers get updated)
    
    And add more info about the error, and replace EIO with EUCLEAN.
    
    For nr_items error, report if it's too large or too small, and output
    the valid value range.
    
    For node block pointer, added a new alignment checker.
    
    For key order, also output the next key to make the problem more
    obvious.
    
    Signed-off-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
    [ wording adjustments, unindented long strings ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb3493e2476c5ce60c6a376a6b50d465f2864968
Author: Qu Wenruo <quwenruo.btrfs@gmx.com>
Date:   Mon Oct 9 01:51:02 2017 +0000

    btrfs: Move leaf and node validation checker to tree-checker.c
    
    commit 557ea5dd003d371536f6b4e8f7c8209a2b6fd4e3 upstream.
    
    It's no doubt the comprehensive tree block checker will become larger,
    so moving them into their own files is quite reasonable.
    
    Signed-off-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
    [ wording adjustments ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64948fd63f662180c00f0fe70b623eab51108a89
Author: Qu Wenruo <quwenruo.btrfs@gmx.com>
Date:   Wed Aug 23 16:57:59 2017 +0900

    btrfs: Add checker for EXTENT_CSUM
    
    commit 4b865cab96fe2a30ed512cf667b354bd291b3b0a upstream.
    
    EXTENT_CSUM checker is a relatively easy one, only needs to check:
    
    1) Objectid
       Fixed to BTRFS_EXTENT_CSUM_OBJECTID
    
    2) Key offset alignment
       Must be aligned to sectorsize
    
    3) Item size alignedment
       Must be aligned to csum size
    
    Signed-off-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa5d29e6d7cbfac45e3b7bdb7bb3d48f124bbe55
Author: Qu Wenruo <quwenruo.btrfs@gmx.com>
Date:   Wed Aug 23 16:57:58 2017 +0900

    btrfs: Add sanity check for EXTENT_DATA when reading out leaf
    
    commit 40c3c40947324d9f40bf47830c92c59a9bbadf4a upstream.
    
    Add extra checks for item with EXTENT_DATA type.  This checks the
    following thing:
    
    0) Key offset
       All key offsets must be aligned to sectorsize.
       Inline extent must have 0 for key offset.
    
    1) Item size
       Uncompressed inline file extent size must match item size.
       (Compressed inline file extent has no information about its on-disk size.)
       Regular/preallocated file extent size must be a fixed value.
    
    2) Every member of regular file extent item
       Including alignment for bytenr and offset, possible value for
       compression/encryption/type.
    
    3) Type/compression/encode must be one of the valid values.
    
    This should be the most comprehensive and strict check in the context
    of btrfs_item for EXTENT_DATA.
    
    Signed-off-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    [ switch to BTRFS_FILE_EXTENT_TYPES, similar to what
      BTRFS_COMPRESS_TYPES does ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac6ea50bb6306ed056222a5967b2bad3c3a9e2dd
Author: Qu Wenruo <quwenruo.btrfs@gmx.com>
Date:   Wed Aug 23 16:57:57 2017 +0900

    btrfs: Check if item pointer overlaps with the item itself
    
    commit 7f43d4affb2a254d421ab20b0cf65ac2569909fb upstream.
    
    Function check_leaf() checks if any item pointer points outside of the
    leaf, but it doesn't check if the pointer overlaps with the item itself.
    
    Normally only the last item may be the victim, but adding such check is
    never a bad idea anyway.
    
    Signed-off-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5cc85fe139c181e53cc557230c5ea4001a90c80
Author: Qu Wenruo <quwenruo.btrfs@gmx.com>
Date:   Wed Aug 23 16:57:56 2017 +0900

    btrfs: Refactor check_leaf function for later expansion
    
    commit c3267bbaa9cae09b62960eafe33ad19196803285 upstream.
    
    Current check_leaf() function does a good job checking key order and
    item offset/size.
    
    However it only checks from slot 0 to the last but one slot, this is
    good but makes later expansion hard.
    
    So this refactoring iterates from slot 0 to the last slot.
    For key comparison, it uses a key with all 0 as initial key, so all
    valid keys should be larger than that.
    
    And for item size/offset checks, it compares current item end with
    previous item offset.
    For slot 0, use leaf end as a special case.
    
    This makes later item/key offset checks and item size checks easier to
    be implemented.
    
    Also, makes check_leaf() to return -EUCLEAN other than -EIO to indicate
    error.
    
    Signed-off-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 895586ecb7a4528336d41f81d0ce3985e8abbed6
Author: Qu Wenruo <wqu@suse.com>
Date:   Wed Aug 1 10:37:17 2018 +0800

    btrfs: Verify that every chunk has corresponding block group at mount time
    
    commit 7ef49515fa6727cb4b6f2f5b0ffbc5fc20a9f8c6 upstream.
    
    If a crafted image has missing block group items, it could cause
    unexpected behavior and breaks the assumption of 1:1 chunk<->block group
    mapping.
    
    Although we have the block group -> chunk mapping check, we still need
    chunk -> block group mapping check.
    
    This patch will do extra check to ensure each chunk has its
    corresponding block group.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199847
    Reported-by: Xu Wen <wen.xu@gatech.edu>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Gu Jinxiang <gujx@cn.fujitsu.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7eef132ccc95c9af50b647c5da0511d2b8492f8
Author: Gu Jinxiang <gujx@cn.fujitsu.com>
Date:   Wed Jul 4 18:16:39 2018 +0800

    btrfs: validate type when reading a chunk
    
    commit 315409b0098fb2651d86553f0436b70502b29bb2 upstream.
    
    Reported in https://bugzilla.kernel.org/show_bug.cgi?id=199839, with an
    image that has an invalid chunk type but does not return an error.
    
    Add chunk type check in btrfs_check_chunk_valid, to detect the wrong
    type combinations.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199839
    Reported-by: Xu Wen <wen.xu@gatech.edu>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Gu Jinxiang <gujx@cn.fujitsu.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 107b02c81a8761f1f7efc1e8b54d435324ccd13e
Author: Lior David <qca_liord@qca.qualcomm.com>
Date:   Tue Nov 14 15:25:39 2017 +0200

    wil6210: missing length check in wmi_set_ie
    
    commit b5a8ffcae4103a9d823ea3aa3a761f65779fbe2a upstream.
    
    Add a length check in wmi_set_ie to detect unsigned integer
    overflow.
    
    Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
    Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39d9e1c62e3f8b5569a0d9bf4d47a3d5d8ae02e2
Author: Vakul Garg <vakul.garg@nxp.com>
Date:   Mon Sep 10 22:53:46 2018 +0530

    net/tls: Fixed return value when tls_complete_pending_work() fails
    
    commit 150085791afb8054e11d2e080d4b9cd755dd7f69 upstream.
    
    In tls_sw_sendmsg() and tls_sw_sendpage(), the variable 'ret' has
    been set to return value of tls_complete_pending_work(). This allows
    return of proper error code if tls_complete_pending_work() fails.
    
    Fixes: 3c4d7559159b ("tls: kernel TLS support")
    Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 4.14: adjust context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a0f5919e1e6a1c0423d895ab75eb15f94a67c69
Author: Boris Pismenny <borisp@mellanox.com>
Date:   Tue Feb 27 14:18:39 2018 +0200

    tls: Use correct sk->sk_prot for IPV6
    
    commit c113187d38ff85dc302a1bb55864b203ebb2ba10 upstream.
    
    The tls ulp overrides sk->prot with a new tls specific proto structs.
    The tls specific structs were previously based on the ipv4 specific
    tcp_prot sturct.
    As a result, attaching the tls ulp to an ipv6 tcp socket replaced
    some ipv6 callback with the ipv4 equivalents.
    
    This patch adds ipv6 tls proto structs and uses them when
    attached to ipv6 sockets.
    
    Fixes: 3c4d7559159b ('tls: kernel TLS support')
    Signed-off-by: Boris Pismenny <borisp@mellanox.com>
    Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b8b2e76222f1241cec381eb0ec599ee33e9cd00
Author: Ilya Lesokhin <ilyal@mellanox.com>
Date:   Mon Nov 13 10:22:49 2017 +0200

    tls: don't override sk_write_space if tls_set_sw_offload fails.
    
    commit ee181e5201e640a4b92b217e9eab2531dab57d2c upstream.
    
    If we fail to enable tls in the kernel we shouldn't override
    the sk_write_space callback
    
    Fixes: 3c4d7559159b ('tls: kernel TLS support')
    Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93f16446c8ddacbf26ae8408ecd9c9c397b8d5b4
Author: Ilya Lesokhin <ilyal@mellanox.com>
Date:   Mon Nov 13 10:22:48 2017 +0200

    tls: Avoid copying crypto_info again after cipher_type check.
    
    commit 196c31b4b54474b31dee3c30352c45c2a93e9226 upstream.
    
    Avoid copying crypto_info again after cipher_type check
    to avoid a TOCTOU exploits.
    The temporary array on the stack is removed as we don't really need it
    
    Fixes: 3c4d7559159b ('tls: kernel TLS support')
    Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 4.14: Preserve changes made by earlier backports of
     "tls: return -EBUSY if crypto_info is already set" and "tls: zero the
     crypto information from tls_context before freeing"]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 797b8bb47fb27ee49a3b59ad110e5264585415aa
Author: Ilya Lesokhin <ilyal@mellanox.com>
Date:   Mon Nov 13 10:22:46 2017 +0200

    tls: Fix TLS ulp context leak, when TLS_TX setsockopt is not used.
    
    commit ff45d820a2df163957ad8ab459b6eb6976144c18 upstream.
    
    Previously the TLS ulp context would leak if we attached a TLS ulp
    to a socket but did not use the TLS_TX setsockopt,
    or did use it but it failed.
    This patch solves the issue by overriding prot[TLS_BASE_TX].close
    and fixing tls_sk_proto_close to work properly
    when its called with ctx->tx_conf == TLS_BASE_TX.
    This patch also removes ctx->free_resources as we can use ctx->tx_conf
    to obtain the relevant information.
    
    Fixes: 3c4d7559159b ('tls: kernel TLS support')
    Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 4.14: Keep using tls_ctx_free() as introduced by
     the earlier backport of "tls: zero the crypto information from
     tls_context before freeing"]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 25f03991a5210f31491e1e2fccec7cf0d080772e
Author: Ilya Lesokhin <ilyal@mellanox.com>
Date:   Mon Nov 13 10:22:45 2017 +0200

    tls: Add function to update the TLS socket configuration
    
    commit 6d88207fcfddc002afe3e2e4a455e5201089d5d9 upstream.
    
    The tx configuration is now stored in ctx->tx_conf.
    And sk->sk_prot is updated trough a function
    This will simplify things when we add rx
    and support for different possible
    tx and rx cross configurations.
    
    Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83b570c004da47b51d7417ac18d8491d9fc91420
Author: Alexei Starovoitov <ast@kernel.org>
Date:   Tue May 15 09:27:05 2018 -0700

    bpf: Prevent memory disambiguation attack
    
    commit af86ca4e3088fe5eacf2f7e58c01fa68ca067672 upstream.
    
    Detect code patterns where malicious 'speculative store bypass' can be used
    and sanitize such patterns.
    
     39: (bf) r3 = r10
     40: (07) r3 += -216
     41: (79) r8 = *(u64 *)(r7 +0)   // slow read
     42: (7a) *(u64 *)(r10 -72) = 0  // verifier inserts this instruction
     43: (7b) *(u64 *)(r8 +0) = r3   // this store becomes slow due to r8
     44: (79) r1 = *(u64 *)(r6 +0)   // cpu speculatively executes this load
     45: (71) r2 = *(u8 *)(r1 +0)    // speculatively arbitrary 'load byte'
                                     // is now sanitized
    
    Above code after x86 JIT becomes:
     e5: mov    %rbp,%rdx
     e8: add    $0xffffffffffffff28,%rdx
     ef: mov    0x0(%r13),%r14
     f3: movq   $0x0,-0x48(%rbp)
     fb: mov    %rdx,0x0(%r14)
     ff: mov    0x0(%rbx),%rdi
    103: movzbq 0x0(%rdi),%rsi
    
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    [bwh: Backported to 4.14:
     - Add bpf_verifier_env parameter to check_stack_write()
     - Look up stack slot_types with state->stack_slot_type[] rather than
       state->stack[].slot_type[]
     - Drop bpf_verifier_env argument to verbose()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b16d0c5d32468a0624505a7b6b211e20488295e9
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Fri Jul 27 19:25:32 2018 +0200

    libceph: implement CEPHX_V2 calculation mode
    
    commit cc255c76c70f7a87d97939621eae04b600d9f4a1 upstream.
    
    Derive the signature from the entire buffer (both AES cipher blocks)
    instead of using just the first half of the first block, leaving out
    data_crc entirely.
    
    This addresses CVE-2018-1129.
    
    Link: http://tracker.ceph.com/issues/24837
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3fd73c8a71f299e30359a63add1f33e3fd834831
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Fri Jul 27 19:18:34 2018 +0200

    libceph: add authorizer challenge
    
    commit 6daca13d2e72bedaaacfc08f873114c9307d5aea upstream.
    
    When a client authenticates with a service, an authorizer is sent with
    a nonce to the service (ceph_x_authorize_[ab]) and the service responds
    with a mutation of that nonce (ceph_x_authorize_reply).  This lets the
    client verify the service is who it says it is but it doesn't protect
    against a replay: someone can trivially capture the exchange and reuse
    the same authorizer to authenticate themselves.
    
    Allow the service to reject an initial authorizer with a random
    challenge (ceph_x_authorize_challenge).  The client then has to respond
    with an updated authorizer proving they are able to decrypt the
    service's challenge and that the new authorizer was produced for this
    specific connection instance.
    
    The accepting side requires this challenge and response unconditionally
    if the client side advertises they have CEPHX_V2 feature bit.
    
    This addresses CVE-2018-1128.
    
    Link: http://tracker.ceph.com/issues/24836
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a55056e1523990e1ef9d70531ffaf27fd1ddff55
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Fri Jul 27 16:37:54 2018 +0200

    libceph: factor out encrypt_authorizer()
    
    commit 149cac4a50b0b4081b38b2f38de6ef71c27eaa85 upstream.
    
    Will be used for encrypting both the initial and updated authorizers.
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0858417b5c2e7bcc0b9e52c4b76e2af3d69e138b
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Thu Jul 26 18:05:43 2018 +0200

    libceph: factor out __ceph_x_decrypt()
    
    commit c571fe24d243bfe7017f0e67fe800b3cc2a1d1f7 upstream.
    
    Will be used for decrypting the server challenge which is only preceded
    by ceph_x_encrypt_header.
    
    Drop struct_v check to allow for extending ceph_x_encrypt_header in the
    future.
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 66abd96062b627f0ee20a684ebba48cec80233d7
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Thu Jul 26 17:43:47 2018 +0200

    libceph: factor out __prepare_write_connect()
    
    commit c0f56b483aa09c99bfe97409a43ad786f33b8a5a upstream.
    
    Will be used for sending ceph_msg_connect with an updated authorizer,
    after the server challenges the initial authorizer.
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fd0d0f9bb59ec5b628622e30f22158cb564c4ea
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Thu Jul 26 15:17:46 2018 +0200

    libceph: store ceph_auth_handshake pointer in ceph_connection
    
    commit 262614c4294d33b1f19e0d18c0091d9c329b544a upstream.
    
    We already copy authorizer_reply_buf and authorizer_reply_buf_len into
    ceph_connection.  Factoring out __prepare_write_connect() requires two
    more: authorizer_buf and authorizer_buf_len.  Store the pointer to the
    handshake in con->auth rather than piling on.
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba9606d0121b644019d0699b5973926cc1a91c10
Author: Richard Weinberger <richard@nod.at>
Date:   Tue Jun 12 09:33:16 2018 +0200

    ubi: Initialize Fastmap checkmapping correctly
    
    commit 25677478474a91fa1b46f19a4a591a9848bca6fb upstream
    
    We cannot do it last, otherwithse it will be skipped for dynamic
    volumes.
    
    Reported-by: Lachmann, Juergen <juergen.lachmann@harman.com>
    Fixes: 34653fd8c46e ("ubi: fastmap: Check each mapping only once")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30cdc0c3bac950bebd3ba59f5ff980cdd3710e0f
Author: Matthias Schwarzott <zzam@gentoo.org>
Date:   Mon Oct 30 06:07:29 2017 -0400

    media: em28xx: Fix use-after-free when disconnecting
    
    [ Upstream commit 910b0797fa9e8af09c44a3fa36cb310ba7a7218d ]
    
    Fix bug by moving the i2c_unregister_device calls after deregistration
    of dvb frontend.
    
    The new style i2c drivers already destroys the frontend object at
    i2c_unregister_device time.
    When the dvb frontend is unregistered afterwards it leads to this oops:
    
      [ 6058.866459] BUG: unable to handle kernel NULL pointer dereference at 00000000000001f8
      [ 6058.866578] IP: dvb_frontend_stop+0x30/0xd0 [dvb_core]
      [ 6058.866644] PGD 0
      [ 6058.866646] P4D 0
    
      [ 6058.866726] Oops: 0000 [#1] SMP
      [ 6058.866768] Modules linked in: rc_pinnacle_pctv_hd(O) em28xx_rc(O) si2157(O) si2168(O) em28xx_dvb(O) em28xx(O) si2165(O) a8293(O) tda10071(O) tea5767(O) tuner(O) cx23885(O) tda18271(O) videobuf2_dvb(O) videobuf2_dma_sg(O) m88ds3103(O) tveeprom(O) cx2341x(O) v4l2_common(O) dvb_core(O) rc_core(O) videobuf2_memops(O) videobuf2_v4l2(O) videobuf2_core(O) videodev(O) media(O) bluetooth ecdh_generic ums_realtek uas rtl8192cu rtl_usb rtl8192c_common rtlwifi usb_storage snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic i2c_mux snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core kvm_intel kvm irqbypass [last unloaded: videobuf2_memops]
      [ 6058.867497] CPU: 2 PID: 7349 Comm: kworker/2:0 Tainted: G        W  O    4.13.9-gentoo #1
      [ 6058.867595] Hardware name: MEDION E2050 2391/H81H3-EM2, BIOS H81EM2W08.308 08/25/2014
      [ 6058.867692] Workqueue: usb_hub_wq hub_event
      [ 6058.867746] task: ffff88011a15e040 task.stack: ffffc90003074000
      [ 6058.867825] RIP: 0010:dvb_frontend_stop+0x30/0xd0 [dvb_core]
      [ 6058.867896] RSP: 0018:ffffc90003077b58 EFLAGS: 00010293
      [ 6058.867964] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000010040001f
      [ 6058.868056] RDX: ffff88011a15e040 RSI: ffffea000464e400 RDI: ffff88001cbe3028
      [ 6058.868150] RBP: ffffc90003077b68 R08: ffff880119390380 R09: 000000010040001f
      [ 6058.868241] R10: ffffc90003077b18 R11: 000000000001e200 R12: ffff88001cbe3028
      [ 6058.868330] R13: ffff88001cbe68d0 R14: ffff8800cf734000 R15: ffff8800cf734098
      [ 6058.868419] FS:  0000000000000000(0000) GS:ffff88011fb00000(0000) knlGS:0000000000000000
      [ 6058.868511] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 6058.868578] CR2: 00000000000001f8 CR3: 00000001113c5000 CR4: 00000000001406e0
      [ 6058.868662] Call Trace:
      [ 6058.868705]  dvb_unregister_frontend+0x2a/0x80 [dvb_core]
      [ 6058.868774]  em28xx_dvb_fini+0x132/0x220 [em28xx_dvb]
      [ 6058.868840]  em28xx_close_extension+0x34/0x90 [em28xx]
      [ 6058.868902]  em28xx_usb_disconnect+0x4e/0x70 [em28xx]
      [ 6058.868968]  usb_unbind_interface+0x6d/0x260
      [ 6058.869025]  device_release_driver_internal+0x150/0x210
      [ 6058.869094]  device_release_driver+0xd/0x10
      [ 6058.869150]  bus_remove_device+0xe4/0x160
      [ 6058.869204]  device_del+0x1ce/0x2f0
      [ 6058.869253]  usb_disable_device+0x99/0x270
      [ 6058.869306]  usb_disconnect+0x8d/0x260
      [ 6058.869359]  hub_event+0x93d/0x1520
      [ 6058.869408]  ? dequeue_task_fair+0xae5/0xd20
      [ 6058.869467]  process_one_work+0x1d9/0x3e0
      [ 6058.869522]  worker_thread+0x43/0x3e0
      [ 6058.869576]  kthread+0x104/0x140
      [ 6058.869602]  ? trace_event_raw_event_workqueue_work+0x80/0x80
      [ 6058.869640]  ? kthread_create_on_node+0x40/0x40
      [ 6058.869673]  ret_from_fork+0x22/0x30
      [ 6058.869698] Code: 54 49 89 fc 53 48 8b 9f 18 03 00 00 0f 1f 44 00 00 41 83 bc 24 04 05 00 00 02 74 0c 41 c7 84 24 04 05 00 00 01 00 00 00 0f ae f0 <48> 8b bb f8 01 00 00 48 85 ff 74 5c e8 df 40 f0 e0 48 8b 93 f8
      [ 6058.869850] RIP: dvb_frontend_stop+0x30/0xd0 [dvb_core] RSP: ffffc90003077b58
      [ 6058.869894] CR2: 00000000000001f8
      [ 6058.875880] ---[ end trace 717eecf7193b3fc6 ]---
    
    Signed-off-by: Matthias Schwarzott <zzam@gentoo.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f85b74fb1c0a7fa267f828a90b582e27fdf56e7
Author: Hugh Dickins <hughd@google.com>
Date:   Fri Nov 30 14:10:47 2018 -0800

    mm/khugepaged: collapse_shmem() do not crash on Compound
    
    commit 06a5e1268a5fb9c2b346a3da6b97e85f2eba0f07 upstream.
    
    collapse_shmem()'s VM_BUG_ON_PAGE(PageTransCompound) was unsafe: before
    it holds page lock of the first page, racing truncation then extension
    might conceivably have inserted a hugepage there already.  Fail with the
    SCAN_PAGE_COMPOUND result, instead of crashing (CONFIG_DEBUG_VM=y) or
    otherwise mishandling the unexpected hugepage - though later we might
    code up a more constructive way of handling it, with SCAN_SUCCESS.
    
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1811261529310.2275@eggly.anvils
    Fixes: f3f0e1d2150b2 ("khugepaged: add support of collapse for tmpfs/shmem pages")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: <stable@vger.kernel.org>    [4.8+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84c55f8d40102855f3b86ffdfad6b5e4da517858
Author: Hugh Dickins <hughd@google.com>
Date:   Fri Nov 30 14:10:43 2018 -0800

    mm/khugepaged: collapse_shmem() without freezing new_page
    
    commit 87c460a0bded56195b5eb497d44709777ef7b415 upstream.
    
    khugepaged's collapse_shmem() does almost all of its work, to assemble
    the huge new_page from 512 scattered old pages, with the new_page's
    refcount frozen to 0 (and refcounts of all old pages so far also frozen
    to 0).  Including shmem_getpage() to read in any which were out on swap,
    memory reclaim if necessary to allocate their intermediate pages, and
    copying over all the data from old to new.
    
    Imagine the frozen refcount as a spinlock held, but without any lock
    debugging to highlight the abuse: it's not good, and under serious load
    heads into lockups - speculative getters of the page are not expecting
    to spin while khugepaged is rescheduled.
    
    One can get a little further under load by hacking around elsewhere; but
    fortunately, freezing the new_page turns out to have been entirely
    unnecessary, with no hacks needed elsewhere.
    
    The huge new_page lock is already held throughout, and guards all its
    subpages as they are brought one by one into the page cache tree; and
    anything reading the data in that page, without the lock, before it has
    been marked PageUptodate, would already be in the wrong.  So simply
    eliminate the freezing of the new_page.
    
    Each of the old pages remains frozen with refcount 0 after it has been
    replaced by a new_page subpage in the page cache tree, until they are
    all unfrozen on success or failure: just as before.  They could be
    unfrozen sooner, but cause no problem once no longer visible to
    find_get_entry(), filemap_map_pages() and other speculative lookups.
    
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1811261527570.2275@eggly.anvils
    Fixes: f3f0e1d2150b2 ("khugepaged: add support of collapse for tmpfs/shmem pages")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: <stable@vger.kernel.org>    [4.8+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b447a6adf423cd80862a5944e4e9d9c91afff05a
Author: Hugh Dickins <hughd@google.com>
Date:   Fri Nov 30 14:10:39 2018 -0800

    mm/khugepaged: minor reorderings in collapse_shmem()
    
    commit 042a30824871fa3149b0127009074b75cc25863c upstream.
    
    Several cleanups in collapse_shmem(): most of which probably do not
    really matter, beyond doing things in a more familiar and reassuring
    order.  Simplify the failure gotos in the main loop, and on success
    update stats while interrupts still disabled from the last iteration.
    
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1811261526400.2275@eggly.anvils
    Fixes: f3f0e1d2150b2 ("khugepaged: add support of collapse for tmpfs/shmem pages")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: <stable@vger.kernel.org>    [4.8+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5021918a515cd86fb8715ec0f24ae66f15f5aba5
Author: Hugh Dickins <hughd@google.com>
Date:   Fri Nov 30 14:10:35 2018 -0800

    mm/khugepaged: collapse_shmem() remember to clear holes
    
    commit 2af8ff291848cc4b1cce24b6c943394eb2c761e8 upstream.
    
    Huge tmpfs testing reminds us that there is no __GFP_ZERO in the gfp
    flags khugepaged uses to allocate a huge page - in all common cases it
    would just be a waste of effort - so collapse_shmem() must remember to
    clear out any holes that it instantiates.
    
    The obvious place to do so, where they are put into the page cache tree,
    is not a good choice: because interrupts are disabled there.  Leave it
    until further down, once success is assured, where the other pages are
    copied (before setting PageUptodate).
    
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1811261525080.2275@eggly.anvils
    Fixes: f3f0e1d2150b2 ("khugepaged: add support of collapse for tmpfs/shmem pages")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: <stable@vger.kernel.org>    [4.8+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98f1ae169c2e7264b198c3df08612f1bcd0fcfac
Author: Hugh Dickins <hughd@google.com>
Date:   Fri Nov 30 14:10:29 2018 -0800

    mm/khugepaged: fix crashes due to misaccounted holes
    
    commit aaa52e340073b7f4593b3c4ddafcafa70cf838b5 upstream.
    
    Huge tmpfs testing on a shortish file mapped into a pmd-rounded extent
    hit shmem_evict_inode()'s WARN_ON(inode->i_blocks) followed by
    clear_inode()'s BUG_ON(inode->i_data.nrpages) when the file was later
    closed and unlinked.
    
    khugepaged's collapse_shmem() was forgetting to update mapping->nrpages
    on the rollback path, after it had added but then needs to undo some
    holes.
    
    There is indeed an irritating asymmetry between shmem_charge(), whose
    callers want it to increment nrpages after successfully accounting
    blocks, and shmem_uncharge(), when __delete_from_page_cache() already
    decremented nrpages itself: oh well, just add a comment on that to them
    both.
    
    And shmem_recalc_inode() is supposed to be called when the accounting is
    expected to be in balance (so it can deduce from imbalance that reclaim
    discarded some pages): so change shmem_charge() to update nrpages
    earlier (though it's rare for the difference to matter at all).
    
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1811261523450.2275@eggly.anvils
    Fixes: 800d8c63b2e98 ("shmem: add huge pages support")
    Fixes: f3f0e1d2150b2 ("khugepaged: add support of collapse for tmpfs/shmem pages")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: <stable@vger.kernel.org>    [4.8+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 81d2848c99cc4951eb3f7c3ce4313e830b07cc2b
Author: Hugh Dickins <hughd@google.com>
Date:   Fri Nov 30 14:10:25 2018 -0800

    mm/khugepaged: collapse_shmem() stop if punched or truncated
    
    commit 701270fa193aadf00bdcf607738f64997275d4c7 upstream.
    
    Huge tmpfs testing showed that although collapse_shmem() recognizes a
    concurrently truncated or hole-punched page correctly, its handling of
    holes was liable to refill an emptied extent.  Add check to stop that.
    
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1811261522040.2275@eggly.anvils
    Fixes: f3f0e1d2150b2 ("khugepaged: add support of collapse for tmpfs/shmem pages")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Reviewed-by: Matthew Wilcox <willy@infradead.org>
    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Cc: <stable@vger.kernel.org>    [4.8+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f75a09833839caef7450275cc227dcef1679493
Author: Hugh Dickins <hughd@google.com>
Date:   Fri Nov 30 14:10:21 2018 -0800

    mm/huge_memory: fix lockdep complaint on 32-bit i_size_read()
    
    commit 006d3ff27e884f80bd7d306b041afc415f63598f upstream.
    
    Huge tmpfs testing, on 32-bit kernel with lockdep enabled, showed that
    __split_huge_page() was using i_size_read() while holding the irq-safe
    lru_lock and page tree lock, but the 32-bit i_size_read() uses an
    irq-unsafe seqlock which should not be nested inside them.
    
    Instead, read the i_size earlier in split_huge_page_to_list(), and pass
    the end offset down to __split_huge_page(): all while holding head page
    lock, which is enough to prevent truncation of that extent before the
    page tree lock has been taken.
    
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1811261520070.2275@eggly.anvils
    Fixes: baa355fd33142 ("thp: file pages support for split_huge_page()")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: <stable@vger.kernel.org>    [4.8+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16d07443b27746fc819600fbe79742335a471d47
Author: Hugh Dickins <hughd@google.com>
Date:   Fri Nov 30 14:10:16 2018 -0800

    mm/huge_memory: splitting set mapping+index before unfreeze
    
    commit 173d9d9fd3ddae84c110fea8aedf1f26af6be9ec upstream.
    
    Huge tmpfs stress testing has occasionally hit shmem_undo_range()'s
    VM_BUG_ON_PAGE(page_to_pgoff(page) != index, page).
    
    Move the setting of mapping and index up before the page_ref_unfreeze()
    in __split_huge_page_tail() to fix this: so that a page cache lookup
    cannot get a reference while the tail's mapping and index are unstable.
    
    In fact, might as well move them up before the smp_wmb(): I don't see an
    actual need for that, but if I'm missing something, this way round is
    safer than the other, and no less efficient.
    
    You might argue that VM_BUG_ON_PAGE(page_to_pgoff(page) != index, page) is
    misplaced, and should be left until after the trylock_page(); but left as
    is has not crashed since, and gives more stringent assurance.
    
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1811261516380.2275@eggly.anvils
    Fixes: e9b61f19858a5 ("thp: reintroduce split_huge_page()")
    Requires: 605ca5ede764 ("mm/huge_memory.c: reorder operations in __split_huge_page_tail()")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: <stable@vger.kernel.org>    [4.8+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30241d721f90ea1cd783b79049024379d4a5b4f0
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date:   Thu Apr 5 16:23:28 2018 -0700

    mm/huge_memory.c: reorder operations in __split_huge_page_tail()
    
    commit 605ca5ede7643a01f4c4a15913f9714ac297f8a6 upstream.
    
    THP split makes non-atomic change of tail page flags.  This is almost ok
    because tail pages are locked and isolated but this breaks recent
    changes in page locking: non-atomic operation could clear bit
    PG_waiters.
    
    As a result concurrent sequence get_page_unless_zero() -> lock_page()
    might block forever.  Especially if this page was truncated later.
    
    Fix is trivial: clone flags before unfreezing page reference counter.
    
    This race exists since commit 62906027091f ("mm: add PageWaiters
    indicating tasks are waiting for a page bit") while unsave unfreeze
    itself was added in commit 8df651c7059e ("thp: cleanup
    split_huge_page()").
    
    clear_compound_head() also must be called before unfreezing page
    reference because after successful get_page_unless_zero() might follow
    put_page() which needs correct compound_head().
    
    And replace page_ref_inc()/page_ref_add() with page_ref_unfreeze() which
    is made especially for that and has semantic of smp_store_release().
    
    Link: http://lkml.kernel.org/r/151844393341.210639.13162088407980624477.stgit@buzz
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e12b67d81b08a79994ee9b1484a7e0c4601bfdad
Author: Hugh Dickins <hughd@google.com>
Date:   Fri Nov 30 14:10:13 2018 -0800

    mm/huge_memory: rename freeze_page() to unmap_page()
    
    commit 906f9cdfc2a0800f13683f9e4ebdfd08c12ee81b upstream.
    
    The term "freeze" is used in several ways in the kernel, and in mm it
    has the particular meaning of forcing page refcount temporarily to 0.
    freeze_page() is just too confusing a name for a function that unmaps a
    page: rename it unmap_page(), and rename unfreeze_page() remap_page().
    
    Went to change the mention of freeze_page() added later in mm/rmap.c,
    but found it to be incorrect: ordinary page reclaim reaches there too;
    but the substance of the comment still seems correct, so edit it down.
    
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1811261514080.2275@eggly.anvils
    Fixes: e9b61f19858a5 ("thp: reintroduce split_huge_page()")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: <stable@vger.kernel.org>    [4.8+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
