Linux 5.15.14

 
ARM: dts: gpio-ranges property is now required [+ + +]
Author: Phil Elwell <phil@raspberrypi.com>
Date:   Tue Jan 4 18:02:47 2022 +0100

    ARM: dts: gpio-ranges property is now required
    
    [ Upstream commit c8013355ead68dce152cf426686f8a5f80d88b40 ]
    
    Since [1], added in 5.7, the absence of a gpio-ranges property has
    prevented GPIOs from being restored to inputs when released.
    Add those properties for BCM283x and BCM2711 devices.
    
    [1] commit 2ab73c6d8323 ("gpio: Support GPIO controllers without
        pin-ranges")
    
    Link: https://lore.kernel.org/r/20220104170247.956760-1-linus.walleij@linaro.org
    Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
    Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs")
    Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
    Reported-by: Florian Fainelli <f.fainelli@gmail.com>
    Reported-by: Jan Kiszka <jan.kiszka@web.de>
    Signed-off-by: Phil Elwell <phil@raspberrypi.com>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20211206092237.4105895-3-phil@raspberrypi.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
atlantic: Fix buff_ring OOB in aq_ring_rx_clean [+ + +]
Author: Zekun Shen <bruceshenzk@gmail.com>
Date:   Sun Dec 26 21:32:45 2021 -0500

    atlantic: Fix buff_ring OOB in aq_ring_rx_clean
    
    [ Upstream commit 5f50153288452e10b6edd69ec9112c49442b054a ]
    
    The function obtain the next buffer without boundary check.
    We should return with I/O error code.
    
    The bug is found by fuzzing and the crash report is attached.
    It is an OOB bug although reported as use-after-free.
    
    [    4.804724] BUG: KASAN: use-after-free in aq_ring_rx_clean+0x1e88/0x2730 [atlantic]
    [    4.805661] Read of size 4 at addr ffff888034fe93a8 by task ksoftirqd/0/9
    [    4.806505]
    [    4.806703] CPU: 0 PID: 9 Comm: ksoftirqd/0 Tainted: G        W         5.6.0 #34
    [    4.809030] Call Trace:
    [    4.809343]  dump_stack+0x76/0xa0
    [    4.809755]  print_address_description.constprop.0+0x16/0x200
    [    4.810455]  ? aq_ring_rx_clean+0x1e88/0x2730 [atlantic]
    [    4.811234]  ? aq_ring_rx_clean+0x1e88/0x2730 [atlantic]
    [    4.813183]  __kasan_report.cold+0x37/0x7c
    [    4.813715]  ? aq_ring_rx_clean+0x1e88/0x2730 [atlantic]
    [    4.814393]  kasan_report+0xe/0x20
    [    4.814837]  aq_ring_rx_clean+0x1e88/0x2730 [atlantic]
    [    4.815499]  ? hw_atl_b0_hw_ring_rx_receive+0x9a5/0xb90 [atlantic]
    [    4.816290]  aq_vec_poll+0x179/0x5d0 [atlantic]
    [    4.816870]  ? _GLOBAL__sub_I_65535_1_aq_pci_func_init+0x20/0x20 [atlantic]
    [    4.817746]  ? __next_timer_interrupt+0xba/0xf0
    [    4.818322]  net_rx_action+0x363/0xbd0
    [    4.818803]  ? call_timer_fn+0x240/0x240
    [    4.819302]  ? __switch_to_asm+0x40/0x70
    [    4.819809]  ? napi_busy_loop+0x520/0x520
    [    4.820324]  __do_softirq+0x18c/0x634
    [    4.820797]  ? takeover_tasklets+0x5f0/0x5f0
    [    4.821343]  run_ksoftirqd+0x15/0x20
    [    4.821804]  smpboot_thread_fn+0x2f1/0x6b0
    [    4.822331]  ? smpboot_unregister_percpu_thread+0x160/0x160
    [    4.823041]  ? __kthread_parkme+0x80/0x100
    [    4.823571]  ? smpboot_unregister_percpu_thread+0x160/0x160
    [    4.824301]  kthread+0x2b5/0x3b0
    [    4.824723]  ? kthread_create_on_node+0xd0/0xd0
    [    4.825304]  ret_from_fork+0x35/0x40
    
    Signed-off-by: Zekun Shen <bruceshenzk@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
auxdisplay: charlcd: checking for pointer reference before dereferencing [+ + +]
Author: Luiz Sampaio <sampaio.ime@gmail.com>
Date:   Tue Nov 9 19:07:32 2021 -0300

    auxdisplay: charlcd: checking for pointer reference before dereferencing
    
    [ Upstream commit 4daa9ff89ef27be43c15995412d6aee393a78200 ]
    
    Check if the pointer lcd->ops->init_display exists before dereferencing it.
    If a driver called charlcd_init() without defining the ops, this would
    return segmentation fault, as happened to me when implementing a charlcd
    driver.  Checking the pointer before dereferencing protects from
    segmentation fault.
    
    Signed-off-by: Luiz Sampaio <sampaio.ime@gmail.com>
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
batman-adv: mcast: don't send link-local multicast to mcast routers [+ + +]
Author: Linus Lüssing <linus.luessing@c0d3.blue>
Date:   Sat Jan 1 06:27:13 2022 +0100

    batman-adv: mcast: don't send link-local multicast to mcast routers
    
    commit 938f2e0b57ffe8a6df71e1e177b2978b1b33fe5e upstream.
    
    The addition of routable multicast TX handling introduced a
    bug/regression for packets with a link-local multicast destination:
    These packets would be sent to all batman-adv nodes with a multicast
    router and to all batman-adv nodes with an old version without multicast
    router detection.
    
    This even disregards the batman-adv multicast fanout setting, which can
    potentially lead to an unwanted, high number of unicast transmissions or
    even congestion.
    
    Fixing this by avoiding to send link-local multicast packets to nodes in
    the multicast router list.
    
    Fixes: 11d458c1cb9b ("batman-adv: mcast: apply optimizations for routable packets, too")
    Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cgroup: Allocate cgroup_file_ctx for kernfs_open_file->priv [+ + +]
Author: Tejun Heo <tj@kernel.org>
Date:   Thu Jan 6 11:02:29 2022 -1000

    cgroup: Allocate cgroup_file_ctx for kernfs_open_file->priv
    
    commit 0d2b5955b36250a9428c832664f2079cbf723bec upstream.
    
    of->priv is currently used by each interface file implementation to store
    private information. This patch collects the current two private data usages
    into struct cgroup_file_ctx which is allocated and freed by the common path.
    This allows generic private data which applies to multiple files, which will
    be used to in the following patch.
    
    Note that cgroup_procs iterator is now embedded as procs.iter in the new
    cgroup_file_ctx so that it doesn't need to be allocated and freed
    separately.
    
    v2: union dropped from cgroup_file_ctx and the procs iterator is embedded in
        cgroup_file_ctx as suggested by Linus.
    
    v3: Michal pointed out that cgroup1's procs pidlist uses of->priv too.
        Converted. Didn't change to embedded allocation as cgroup1 pidlists get
        stored for caching.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Reviewed-by: Michal Koutný <mkoutny@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cgroup: Use open-time cgroup namespace for process migration perm checks [+ + +]
Author: Tejun Heo <tj@kernel.org>
Date:   Thu Jan 6 11:02:29 2022 -1000

    cgroup: Use open-time cgroup namespace for process migration perm checks
    
    commit e57457641613fef0d147ede8bd6a3047df588b95 upstream.
    
    cgroup process migration permission checks are performed at write time as
    whether a given operation is allowed or not is dependent on the content of
    the write - the PID. This currently uses current's cgroup namespace which is
    a potential security weakness as it may allow scenarios where a less
    privileged process tricks a more privileged one into writing into a fd that
    it created.
    
    This patch makes cgroup remember the cgroup namespace at the time of open
    and uses it for migration permission checks instad of current's. Note that
    this only applies to cgroup2 as cgroup1 doesn't have namespace support.
    
    This also fixes a use-after-free bug on cgroupns reported in
    
     https://lore.kernel.org/r/00000000000048c15c05d0083397@google.com
    
    Note that backporting this fix also requires the preceding patch.
    
    Reported-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
    Cc: Michal Koutný <mkoutny@suse.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Reviewed-by: Michal Koutný <mkoutny@suse.com>
    Reported-by: syzbot+50f5cf33a284ce738b62@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/00000000000048c15c05d0083397@google.com
    Fixes: 5136f6365ce3 ("cgroup: implement "nsdelegate" mount option")
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cgroup: Use open-time credentials for process migraton perm checks [+ + +]
Author: Tejun Heo <tj@kernel.org>
Date:   Thu Jan 6 11:02:28 2022 -1000

    cgroup: Use open-time credentials for process migraton perm checks
    
    commit 1756d7994ad85c2479af6ae5a9750b92324685af upstream.
    
    cgroup process migration permission checks are performed at write time as
    whether a given operation is allowed or not is dependent on the content of
    the write - the PID. This currently uses current's credentials which is a
    potential security weakness as it may allow scenarios where a less
    privileged process tricks a more privileged one into writing into a fd that
    it created.
    
    This patch makes both cgroup2 and cgroup1 process migration interfaces to
    use the credentials saved at the time of open (file->f_cred) instead of
    current's.
    
    Reported-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
    Fixes: 187fe84067bd ("cgroup: require write perm on common ancestor when moving processes on the default hierarchy")
    Reviewed-by: Michal Koutný <mkoutny@suse.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Added power down for DCN10 [+ + +]
Author: Lai, Derek <Derek.Lai@amd.com>
Date:   Mon Dec 6 17:10:59 2021 +0800

    drm/amd/display: Added power down for DCN10
    
    [ Upstream commit d97e631af2db84c8c9d63abf68d487d0bb559e4c ]
    
    [Why]
    The change of setting a timer callback on boot for 10 seconds is still
    working, just lacked power down for DCN10.
    
    [How]
    Added power down for DCN10.
    
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
    Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Derek Lai <Derek.Lai@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: fix B0 TMDS deepcolor no dislay issue [+ + +]
Author: Charlene Liu <Charlene.Liu@amd.com>
Date:   Sun Dec 5 21:19:30 2021 -0500

    drm/amd/display: fix B0 TMDS deepcolor no dislay issue
    
    [ Upstream commit 2eb82577a16d4c8eb31e4ed520649850bb95b223 ]
    
    [why]
    B0 PHY C map to F, D map to G driver use logic instance, dmub does the
    remap. Driver still need use the right PHY instance to access right HW.
    
    [how]
    use phyical instance when program PHY register.
    
    [note]
    could move resync_control programming to dmub next.
    
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
    Reviewed-by: Jun Lei <Jun.Lei@amd.com>
    Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Charlene Liu <Charlene.Liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/pm: Fix xgmi link control on aldebaran [+ + +]
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Wed Dec 15 23:37:03 2021 +0800

    drm/amd/pm: Fix xgmi link control on aldebaran
    
    [ Upstream commit 19e66d512e4182a0461530fa3159638e0f55d97e ]
    
    Fix the message argument.
            0: Allow power down
            1: Disallow power down
    
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: keep the BACO feature enabled for suspend [+ + +]
Author: Evan Quan <evan.quan@amd.com>
Date:   Thu Dec 30 17:53:54 2021 +0800

    drm/amd/pm: keep the BACO feature enabled for suspend
    
    commit eaa090538e8d21801c6d5f94590c3799e6a528b5 upstream.
    
    To pair with the workaround which always reset the ASIC in suspend.
    Otherwise, the reset which relies on BACO will fail.
    
    Fixes: daf8de0874ab5b ("drm/amdgpu: always reset the asic in suspend (v2)")
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Guchun Chen <guchun.chen@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/pm: skip setting gfx cgpg in the s0ix suspend-resume [+ + +]
Author: Prike Liang <Prike.Liang@amd.com>
Date:   Mon Dec 13 16:17:02 2021 +0800

    drm/amd/pm: skip setting gfx cgpg in the s0ix suspend-resume
    
    [ Upstream commit 8c45096c60d6ce6341c374636100ed1b2c1c33a1 ]
    
    In the s0ix entry need retain gfx in the gfxoff state,so here need't
    set gfx cgpg in the S0ix suspend-resume process. Moreover move the S0ix
    check into SMU12 can simplify the code condition check.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1712
    Signed-off-by: Prike Liang <Prike.Liang@amd.com>
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: always reset the asic in suspend (v2) [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Nov 12 11:25:30 2021 -0500

    drm/amdgpu: always reset the asic in suspend (v2)
    
    [ Upstream commit daf8de0874ab5b74b38a38726fdd3d07ef98a7ee ]
    
    If the platform suspend happens to fail and the power rail
    is not turned off, the GPU will be in an unknown state on
    resume, so reset the asic so that it will be in a known
    good state on resume even if the platform suspend failed.
    
    v2: handle s0ix
    
    Acked-by: Luben Tuikov <luben.tuikov@amd.com>
    Acked-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: disable runpm if we are the primary adapter [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Dec 22 22:57:16 2021 -0500

    drm/amdgpu: disable runpm if we are the primary adapter
    
    commit b95dc06af3e683d6b7ddbbae178b2b2a21ee8b2b upstream.
    
    If we are the primary adapter (i.e., the one used by the firwmare
    framebuffer), disable runtime pm.  This fixes a regression caused
    by commit 55285e21f045 which results in the displays waking up
    shortly after they go to sleep due to the device coming out of
    runtime suspend and sending a hotplug uevent.
    
    v2: squash in reworked fix from Evan
    
    Fixes: 55285e21f045 ("fbdev/efifb: Release PCI device's runtime PM ref during FB destroy")
    Bug: https://bugzilla.kernel.org/show_bug.cgi?id=215203
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1840
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: fix dropped backing store handling in amdgpu_dma_buf_move_notify [+ + +]
Author: Christian König <ckoenig.leichtzumerken@gmail.com>
Date:   Fri Dec 10 09:39:27 2021 +0100

    drm/amdgpu: fix dropped backing store handling in amdgpu_dma_buf_move_notify
    
    [ Upstream commit fc74881c28d314b10efac016ef49df4ff40b8b97 ]
    
    bo->tbo.resource can now be NULL.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1811
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211210083927.1754-1-christian.koenig@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: put SMU into proper state on runpm suspending for BOCO capable platform [+ + +]
Author: Evan Quan <evan.quan@amd.com>
Date:   Fri Dec 17 19:05:06 2021 +0800

    drm/amdgpu: put SMU into proper state on runpm suspending for BOCO capable platform
    
    [ Upstream commit 7be3be2b027c12e84833b3dc9597d3bb7e4c5464 ]
    
    By setting mp1_state as PP_MP1_STATE_UNLOAD, MP1 will do some proper cleanups and
    put itself into a state ready for PNP. That can workaround some random resuming
    failure observed on BOCO capable platforms.
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Guchun Chen <guchun.chen@amd.com>
    Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
EDAC/i10nm: Release mdev/mbase when failing to detect HBM [+ + +]
Author: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Date:   Fri Dec 24 04:11:26 2021 -0500

    EDAC/i10nm: Release mdev/mbase when failing to detect HBM
    
    commit c370baa328022cbd46c59c821d1b467a97f047be upstream.
    
    On systems without HBM (High Bandwidth Memory) mdev/mbase are not
    released/unmapped.
    
    Add the code to release mdev/mbase when failing to detect HBM.
    
    [Tony: re-word commit message]
    
    Cc: <stable@vger.kernel.org>
    Fixes: c945088384d0 ("EDAC/i10nm: Add support for high bandwidth memory")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/20211224091126.1246-1-qiuxu.zhuo@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fbdev: fbmem: add a helper to determine if an aperture is used by a fw fb [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Dec 22 22:41:18 2021 -0500

    fbdev: fbmem: add a helper to determine if an aperture is used by a fw fb
    
    commit 9a45ac2320d0a6ae01880a30d4b86025fce4061b upstream.
    
    Add a function for drivers to check if the a firmware initialized
    fb is corresponds to their aperture.  This allows drivers to check if the
    device corresponds to what the firmware set up as the display device.
    
    Bug: https://bugzilla.kernel.org/show_bug.cgi?id=215203
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1840
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fscache_cookie_enabled: check cookie is valid before accessing it [+ + +]
Author: Dominique Martinet <asmadeus@codewreck.org>
Date:   Wed Nov 3 17:34:05 2021 +0900

    fscache_cookie_enabled: check cookie is valid before accessing it
    
    commit 0dc54bd4d6e03be1f0b678c4297170b79f1a44ab upstream.
    
    fscache_cookie_enabled() could be called on NULL cookies and cause a
    null pointer dereference when accessing cookie flags: just make sure
    the cookie is valid first
    
    Suggested-by: David Howells <dhowells@redhat.com>
    Acked-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Cc: Jeffrey E Altman <jaltman@auristor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
ftrace/samples: Add missing prototypes direct functions [+ + +]
Author: Jiri Olsa <jolsa@redhat.com>
Date:   Sun Dec 19 14:53:17 2021 +0100

    ftrace/samples: Add missing prototypes direct functions
    
    commit 0daf5cb217a9ca8ae91b8f966ddae322699fb71d upstream.
    
    There's another compilation fail (first here [1]) reported by kernel
    test robot for W=1 clang build:
    
      >> samples/ftrace/ftrace-direct-multi-modify.c:7:6: warning: no previous
      prototype for function 'my_direct_func1' [-Wmissing-prototypes]
         void my_direct_func1(unsigned long ip)
    
    Direct functions in ftrace direct sample modules need to have prototypes
    defined. They are already global in order to be visible for the inline
    assembly, so there's no problem.
    
    The kernel test robot reported just error for ftrace-direct-multi-modify,
    but I got same errors also for the rest of the modules touched by this patch.
    
    [1] 67d4f6e3bf5d ftrace/samples: Add missing prototype for my_direct_func
    
    Link: https://lkml.kernel.org/r/20211219135317.212430-1-jolsa@kernel.org
    
    Reported-by: kernel test robot <lkp@intel.com>
    Fixes: e1067a07cfbc ("ftrace/samples: Add module to test multi direct modify interface")
    Fixes: ae0cc3b7e7f5 ("ftrace/samples: Add a sample module that implements modify_ftrace_direct()")
    Fixes: 156473a0ff4f ("ftrace: Add another example of register_ftrace_direct() use case")
    Fixes: b06457c83af6 ("ftrace: Add sample module that uses register_ftrace_direct()")
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gpio: gpio-aspeed-sgpio: Fix wrong hwirq base in irq handler [+ + +]
Author: Steven Lee <steven_lee@aspeedtech.com>
Date:   Tue Dec 14 12:02:38 2021 +0800

    gpio: gpio-aspeed-sgpio: Fix wrong hwirq base in irq handler
    
    commit e5a7431f5a2d6dcff7d516ee9d178a3254b17b87 upstream.
    
    Each aspeed sgpio bank has 64 gpio pins(32 input pins and 32 output pins).
    The hwirq base for each sgpio bank should be multiples of 64 rather than
    multiples of 32.
    
    Signed-off-by: Steven Lee <steven_lee@aspeedtech.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
i2c: mpc: Avoid out of bounds memory access [+ + +]
Author: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date:   Wed Jan 5 14:53:04 2022 +1300

    i2c: mpc: Avoid out of bounds memory access
    
    commit 72a4a87da8f7bcf868b338615a814b6542f277f3 upstream.
    
    When performing an I2C transfer where the last message was a write KASAN
    would complain:
    
      BUG: KASAN: slab-out-of-bounds in mpc_i2c_do_action+0x154/0x630
      Read of size 2 at addr c814e310 by task swapper/2/0
    
      CPU: 2 PID: 0 Comm: swapper/2 Tainted: G    B             5.16.0-rc8 #1
      Call Trace:
      [e5ee9d50] [c08418e8] dump_stack_lvl+0x4c/0x6c (unreliable)
      [e5ee9d70] [c02f8a14] print_address_description.constprop.13+0x64/0x3b0
      [e5ee9da0] [c02f9030] kasan_report+0x1f0/0x204
      [e5ee9de0] [c0c76ee4] mpc_i2c_do_action+0x154/0x630
      [e5ee9e30] [c0c782c4] mpc_i2c_isr+0x164/0x240
      [e5ee9e60] [c00f3a04] __handle_irq_event_percpu+0xf4/0x3b0
      [e5ee9ec0] [c00f3d40] handle_irq_event_percpu+0x80/0x110
      [e5ee9f40] [c00f3e48] handle_irq_event+0x78/0xd0
      [e5ee9f60] [c00fcfec] handle_fasteoi_irq+0x19c/0x370
      [e5ee9fa0] [c00f1d84] generic_handle_irq+0x54/0x80
      [e5ee9fc0] [c0006b54] __do_irq+0x64/0x200
      [e5ee9ff0] [c0007958] __do_IRQ+0xe8/0x1c0
      [c812dd50] [e3eaab20] 0xe3eaab20
      [c812dd90] [c0007a4c] do_IRQ+0x1c/0x30
      [c812dda0] [c0000c04] ExternalInput+0x144/0x160
      --- interrupt: 500 at arch_cpu_idle+0x34/0x60
      NIP:  c000b684 LR: c000b684 CTR: c0019688
      REGS: c812ddb0 TRAP: 0500   Tainted: G    B              (5.16.0-rc8)
      MSR:  00029002 <CE,EE,ME>  CR: 22000488  XER: 20000000
    
      GPR00: c10ef7fc c812de90 c80ff200 c2394718 00000001 00000001 c10e3f90 00000003
      GPR08: 00000000 c0019688 c2394718 fc7d625b 22000484 00000000 21e17000 c208228c
      GPR16: e3e99284 00000000 ffffffff c2390000 c001bac0 c2082288 c812df60 c001ba60
      GPR24: c23949c0 00000018 00080000 00000004 c80ff200 00000002 c2348ee4 c2394718
      NIP [c000b684] arch_cpu_idle+0x34/0x60
      LR [c000b684] arch_cpu_idle+0x34/0x60
      --- interrupt: 500
      [c812de90] [c10e3f90] rcu_eqs_enter.isra.60+0xc0/0x110 (unreliable)
      [c812deb0] [c10ef7fc] default_idle_call+0xbc/0x230
      [c812dee0] [c00af0e8] do_idle+0x1c8/0x200
      [c812df10] [c00af3c0] cpu_startup_entry+0x20/0x30
      [c812df20] [c001e010] start_secondary+0x5d0/0xba0
      [c812dff0] [c00028a0] __secondary_start+0x90/0xdc
    
    This happened because we would overrun the i2c->msgs array on the final
    interrupt for the I2C STOP. This didn't happen if the last message was a
    read because there is no interrupt in that case. Ensure that we only
    access the current message if we are not processing a I2C STOP
    condition.
    
    Fixes: 1538d82f4647 ("i2c: mpc: Interrupt driven transfer")
    Reported-by: Maxime Bizon <mbizon@freebox.fr>
    Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
i40e: Fix for displaying message regarding NVM version [+ + +]
Author: Mateusz Palczewski <mateusz.palczewski@intel.com>
Date:   Thu Dec 9 11:04:35 2021 +0100

    i40e: Fix for displaying message regarding NVM version
    
    commit 40feded8a247f95957a0de9abd100085fb320a2f upstream.
    
    When loading the i40e driver, it prints a message like: 'The driver for the
    device detected a newer version of the NVM image v1.x than expected v1.y.
    Please install the most recent version of the network driver.' This is
    misleading as the driver is working as expected.
    
    Fix that by removing the second part of message and changing it from
    dev_info to dev_dbg.
    
    Fixes: 4fb29bddb57f ("i40e: The driver now prints the API version in error message")
    Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Tested-by: Gurucharan G <gurucharanx.g@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i40e: Fix incorrect netdev's real number of RX/TX queues [+ + +]
Author: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Date:   Fri Dec 17 14:29:05 2021 +0000

    i40e: Fix incorrect netdev's real number of RX/TX queues
    
    commit e738451d78b2f8a9635d66c6a87f304b4d965f7a upstream.
    
    There was a wrong queues representation in sysfs during
    driver's reinitialization in case of online cpus number is
    less than combined queues. It was caused by stopped
    NetworkManager, which is responsible for calling vsi_open
    function during driver's initialization.
    In specific situation (ex. 12 cpus online) there were 16 queues
    in /sys/class/net/<iface>/queues. In case of modifying queues with
    value higher, than number of online cpus, then it caused write
    errors and other errors.
    Add updating of sysfs's queues representation during driver
    initialization.
    
    Fixes: 41c445ff0f48 ("i40e: main driver core")
    Signed-off-by: Lukasz Cieplicki <lukaszx.cieplicki@intel.com>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Tested-by: Gurucharan G <gurucharanx.g@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i40e: Fix to not show opcode msg on unsuccessful VF MAC change [+ + +]
Author: Mateusz Palczewski <mateusz.palczewski@intel.com>
Date:   Wed Mar 3 11:45:33 2021 +0000

    i40e: Fix to not show opcode msg on unsuccessful VF MAC change
    
    commit 01cbf50877e602e2376af89e4a51c30bc574c618 upstream.
    
    Hide i40e opcode information sent during response to VF in case when
    untrusted VF tried to change MAC on the VF interface.
    
    This is implemented by adding an additional parameter 'hide' to the
    response sent to VF function that hides the display of error
    information, but forwards the error code to VF.
    
    Previously it was not possible to send response with some error code
    to VF without displaying opcode information.
    
    Fixes: 5c3c48ac6bf5 ("i40e: implement virtual device interface")
    Signed-off-by: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
    Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Reviewed-by: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Tested-by: Tony Brelinski <tony.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i40e: fix use-after-free in i40e_sync_filters_subtask() [+ + +]
Author: Di Zhu <zhudi2@huawei.com>
Date:   Mon Nov 29 19:52:01 2021 +0600

    i40e: fix use-after-free in i40e_sync_filters_subtask()
    
    commit 3116f59c12bd24c513194cd3acb3ec1f7d468954 upstream.
    
    Using ifconfig command to delete the ipv6 address will cause
    the i40e network card driver to delete its internal mac_filter and
    i40e_service_task kernel thread will concurrently access the mac_filter.
    These two processes are not protected by lock
    so causing the following use-after-free problems.
    
     print_address_description+0x70/0x360
     ? vprintk_func+0x5e/0xf0
     kasan_report+0x1b2/0x330
     i40e_sync_vsi_filters+0x4f0/0x1850 [i40e]
     i40e_sync_filters_subtask+0xe3/0x130 [i40e]
     i40e_service_task+0x195/0x24c0 [i40e]
     process_one_work+0x3f5/0x7d0
     worker_thread+0x61/0x6c0
     ? process_one_work+0x7d0/0x7d0
     kthread+0x1c3/0x1f0
     ? kthread_park+0xc0/0xc0
     ret_from_fork+0x35/0x40
    
    Allocated by task 2279810:
     kasan_kmalloc+0xa0/0xd0
     kmem_cache_alloc_trace+0xf3/0x1e0
     i40e_add_filter+0x127/0x2b0 [i40e]
     i40e_add_mac_filter+0x156/0x190 [i40e]
     i40e_addr_sync+0x2d/0x40 [i40e]
     __hw_addr_sync_dev+0x154/0x210
     i40e_set_rx_mode+0x6d/0xf0 [i40e]
     __dev_set_rx_mode+0xfb/0x1f0
     __dev_mc_add+0x6c/0x90
     igmp6_group_added+0x214/0x230
     __ipv6_dev_mc_inc+0x338/0x4f0
     addrconf_join_solict.part.7+0xa2/0xd0
     addrconf_dad_work+0x500/0x980
     process_one_work+0x3f5/0x7d0
     worker_thread+0x61/0x6c0
     kthread+0x1c3/0x1f0
     ret_from_fork+0x35/0x40
    
    Freed by task 2547073:
     __kasan_slab_free+0x130/0x180
     kfree+0x90/0x1b0
     __i40e_del_filter+0xa3/0xf0 [i40e]
     i40e_del_mac_filter+0xf3/0x130 [i40e]
     i40e_addr_unsync+0x85/0xa0 [i40e]
     __hw_addr_sync_dev+0x9d/0x210
     i40e_set_rx_mode+0x6d/0xf0 [i40e]
     __dev_set_rx_mode+0xfb/0x1f0
     __dev_mc_del+0x69/0x80
     igmp6_group_dropped+0x279/0x510
     __ipv6_dev_mc_dec+0x174/0x220
     addrconf_leave_solict.part.8+0xa2/0xd0
     __ipv6_ifa_notify+0x4cd/0x570
     ipv6_ifa_notify+0x58/0x80
     ipv6_del_addr+0x259/0x4a0
     inet6_addr_del+0x188/0x260
     addrconf_del_ifaddr+0xcc/0x130
     inet6_ioctl+0x152/0x190
     sock_do_ioctl+0xd8/0x2b0
     sock_ioctl+0x2e5/0x4c0
     do_vfs_ioctl+0x14e/0xa80
     ksys_ioctl+0x7c/0xa0
     __x64_sys_ioctl+0x42/0x50
     do_syscall_64+0x98/0x2c0
     entry_SYSCALL_64_after_hwframe+0x65/0xca
    
    Fixes: 41c445ff0f48 ("i40e: main driver core")
    Signed-off-by: Di Zhu <zhudi2@huawei.com>
    Signed-off-by: Rui Zhang <zhangrui182@huawei.com>
    Tested-by: Gurucharan G <gurucharanx.g@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iavf: Fix limit of total number of queues to active queues of VF [+ + +]
Author: Karen Sornek <karen.sornek@intel.com>
Date:   Wed Sep 1 09:21:46 2021 +0200

    iavf: Fix limit of total number of queues to active queues of VF
    
    commit b712941c8085e638bb92456e866ed3de4404e3d5 upstream.
    
    In the absence of this validation, if the user requests to
    configure queues more than the enabled queues, it results in
    sending the requested number of queues to the kernel stack
    (due to the asynchronous nature of VF response), in which
    case the stack might pick a queue to transmit that is not
    enabled and result in Tx hang. Fix this bug by
    limiting the total number of queues allocated for VF to
    active queues of VF.
    
    Fixes: d5b33d024496 ("i40evf: add ndo_setup_tc callback to i40evf")
    Signed-off-by: Ashwin Vijayavel <ashwin.vijayavel@intel.com>
    Signed-off-by: Karen Sornek <karen.sornek@intel.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ieee802154: atusb: fix uninit value in atusb_set_extended_addr [+ + +]
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Tue Jan 4 21:28:06 2022 +0300

    ieee802154: atusb: fix uninit value in atusb_set_extended_addr
    
    commit 754e4382354f7908923a1949d8dc8d05f82f09cb upstream.
    
    Alexander reported a use of uninitialized value in
    atusb_set_extended_addr(), that is caused by reading 0 bytes via
    usb_control_msg().
    
    Fix it by validating if the number of bytes transferred is actually
    correct, since usb_control_msg() may read less bytes, than was requested
    by caller.
    
    Fail log:
    
    BUG: KASAN: uninit-cmp in ieee802154_is_valid_extended_unicast_addr include/linux/ieee802154.h:310 [inline]
    BUG: KASAN: uninit-cmp in atusb_set_extended_addr drivers/net/ieee802154/atusb.c:1000 [inline]
    BUG: KASAN: uninit-cmp in atusb_probe.cold+0x29f/0x14db drivers/net/ieee802154/atusb.c:1056
    Uninit value used in comparison: 311daa649a2003bd stack handle: 000000009a2003bd
     ieee802154_is_valid_extended_unicast_addr include/linux/ieee802154.h:310 [inline]
     atusb_set_extended_addr drivers/net/ieee802154/atusb.c:1000 [inline]
     atusb_probe.cold+0x29f/0x14db drivers/net/ieee802154/atusb.c:1056
     usb_probe_interface+0x314/0x7f0 drivers/usb/core/driver.c:396
    
    Fixes: 7490b008d123 ("ieee802154: add support for atusb transceiver")
    Reported-by: Alexander Potapenko <glider@google.com>
    Acked-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Link: https://lore.kernel.org/r/20220104182806.7188-1-paskripkin@gmail.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Input: zinitix - make sure the IRQ is allocated before it gets enabled [+ + +]
Author: Nikita Travkin <nikita@trvn.ru>
Date:   Sat Jan 8 23:19:19 2022 -0800

    Input: zinitix - make sure the IRQ is allocated before it gets enabled
    
    [ Upstream commit cf73ed894ee939d6706d65e0cd186e4a64e3af6d ]
    
    Since irq request is the last thing in the driver probe, it happens
    later than the input device registration. This means that there is a
    small time window where if the open method is called the driver will
    attempt to enable not yet available irq.
    
    Fix that by moving the irq request before the input device registration.
    
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Fixes: 26822652c85e ("Input: add zinitix touchscreen driver")
    Signed-off-by: Nikita Travkin <nikita@trvn.ru>
    Link: https://lore.kernel.org/r/20220106072840.36851-2-nikita@trvn.ru
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ip6_vti: initialize __ip6_tnl_parm struct in vti6_siocdevprivate [+ + +]
Author: William Zhao <wizhao@redhat.com>
Date:   Thu Dec 23 12:33:16 2021 -0500

    ip6_vti: initialize __ip6_tnl_parm struct in vti6_siocdevprivate
    
    [ Upstream commit c1833c3964d5bd8c163bd4e01736a38bc473cb8a ]
    
    The "__ip6_tnl_parm" struct was left uninitialized causing an invalid
    load of random data when the "__ip6_tnl_parm" struct was used elsewhere.
    As an example, in the function "ip6_tnl_xmit_ctl()", it tries to access
    the "collect_md" member. With "__ip6_tnl_parm" being uninitialized and
    containing random data, the UBSAN detected that "collect_md" held a
    non-boolean value.
    
    The UBSAN issue is as follows:
    ===============================================================
    UBSAN: invalid-load in net/ipv6/ip6_tunnel.c:1025:14
    load of value 30 is not a valid value for type '_Bool'
    CPU: 1 PID: 228 Comm: kworker/1:3 Not tainted 5.16.0-rc4+ #8
    Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    Workqueue: ipv6_addrconf addrconf_dad_work
    Call Trace:
    <TASK>
    dump_stack_lvl+0x44/0x57
    ubsan_epilogue+0x5/0x40
    __ubsan_handle_load_invalid_value+0x66/0x70
    ? __cpuhp_setup_state+0x1d3/0x210
    ip6_tnl_xmit_ctl.cold.52+0x2c/0x6f [ip6_tunnel]
    vti6_tnl_xmit+0x79c/0x1e96 [ip6_vti]
    ? lock_is_held_type+0xd9/0x130
    ? vti6_rcv+0x100/0x100 [ip6_vti]
    ? lock_is_held_type+0xd9/0x130
    ? rcu_read_lock_bh_held+0xc0/0xc0
    ? lock_acquired+0x262/0xb10
    dev_hard_start_xmit+0x1e6/0x820
    __dev_queue_xmit+0x2079/0x3340
    ? mark_lock.part.52+0xf7/0x1050
    ? netdev_core_pick_tx+0x290/0x290
    ? kvm_clock_read+0x14/0x30
    ? kvm_sched_clock_read+0x5/0x10
    ? sched_clock_cpu+0x15/0x200
    ? find_held_lock+0x3a/0x1c0
    ? lock_release+0x42f/0xc90
    ? lock_downgrade+0x6b0/0x6b0
    ? mark_held_locks+0xb7/0x120
    ? neigh_connected_output+0x31f/0x470
    ? lockdep_hardirqs_on+0x79/0x100
    ? neigh_connected_output+0x31f/0x470
    ? ip6_finish_output2+0x9b0/0x1d90
    ? rcu_read_lock_bh_held+0x62/0xc0
    ? ip6_finish_output2+0x9b0/0x1d90
    ip6_finish_output2+0x9b0/0x1d90
    ? ip6_append_data+0x330/0x330
    ? ip6_mtu+0x166/0x370
    ? __ip6_finish_output+0x1ad/0xfb0
    ? nf_hook_slow+0xa6/0x170
    ip6_output+0x1fb/0x710
    ? nf_hook.constprop.32+0x317/0x430
    ? ip6_finish_output+0x180/0x180
    ? __ip6_finish_output+0xfb0/0xfb0
    ? lock_is_held_type+0xd9/0x130
    ndisc_send_skb+0xb33/0x1590
    ? __sk_mem_raise_allocated+0x11cf/0x1560
    ? dst_output+0x4a0/0x4a0
    ? ndisc_send_rs+0x432/0x610
    addrconf_dad_completed+0x30c/0xbb0
    ? addrconf_rs_timer+0x650/0x650
    ? addrconf_dad_work+0x73c/0x10e0
    addrconf_dad_work+0x73c/0x10e0
    ? addrconf_dad_completed+0xbb0/0xbb0
    ? rcu_read_lock_sched_held+0xaf/0xe0
    ? rcu_read_lock_bh_held+0xc0/0xc0
    process_one_work+0x97b/0x1740
    ? pwq_dec_nr_in_flight+0x270/0x270
    worker_thread+0x87/0xbf0
    ? process_one_work+0x1740/0x1740
    kthread+0x3ac/0x490
    ? set_kthread_struct+0x100/0x100
    ret_from_fork+0x22/0x30
    </TASK>
    ===============================================================
    
    The solution is to initialize "__ip6_tnl_parm" struct to zeros in the
    "vti6_siocdevprivate()" function.
    
    Signed-off-by: William Zhao <wizhao@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv4: Check attribute length for RTA_FLOW in multipath route [+ + +]
Author: David Ahern <dsahern@kernel.org>
Date:   Thu Dec 30 17:36:32 2021 -0700

    ipv4: Check attribute length for RTA_FLOW in multipath route
    
    commit 664b9c4b7392ce723b013201843264bf95481ce5 upstream.
    
    Make sure RTA_FLOW is at least 4B before using.
    
    Fixes: 4e902c57417c ("[IPv4]: FIB configuration using struct fib_config")
    Signed-off-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipv4: Check attribute length for RTA_GATEWAY in multipath route [+ + +]
Author: David Ahern <dsahern@kernel.org>
Date:   Thu Dec 30 17:36:31 2021 -0700

    ipv4: Check attribute length for RTA_GATEWAY in multipath route
    
    commit 7a3429bace0e08d94c39245631ea6bc109dafa49 upstream.
    
    syzbot reported uninit-value:
    ============================================================
      BUG: KMSAN: uninit-value in fib_get_nhs+0xac4/0x1f80
      net/ipv4/fib_semantics.c:708
       fib_get_nhs+0xac4/0x1f80 net/ipv4/fib_semantics.c:708
       fib_create_info+0x2411/0x4870 net/ipv4/fib_semantics.c:1453
       fib_table_insert+0x45c/0x3a10 net/ipv4/fib_trie.c:1224
       inet_rtm_newroute+0x289/0x420 net/ipv4/fib_frontend.c:886
    
    Add helper to validate RTA_GATEWAY length before using the attribute.
    
    Fixes: 4e902c57417c ("[IPv4]: FIB configuration using struct fib_config")
    Reported-by: syzbot+d4b9a2851cc3ce998741@syzkaller.appspotmail.com
    Signed-off-by: David Ahern <dsahern@kernel.org>
    Cc: Thomas Graf <tgraf@suug.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ipv6: Check attribute length for RTA_GATEWAY in multipath route [+ + +]
Author: David Ahern <dsahern@kernel.org>
Date:   Thu Dec 30 17:36:33 2021 -0700

    ipv6: Check attribute length for RTA_GATEWAY in multipath route
    
    commit 4619bcf91399f00a40885100fb61d594d8454033 upstream.
    
    Commit referenced in the Fixes tag used nla_memcpy for RTA_GATEWAY as
    does the current nla_get_in6_addr. nla_memcpy protects against accessing
    memory greater than what is in the attribute, but there is no check
    requiring the attribute to have an IPv6 address. Add it.
    
    Fixes: 51ebd3181572 ("ipv6: add support of equal cost multipath (ECMP)")
    Signed-off-by: David Ahern <dsahern@kernel.org>
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipv6: Check attribute length for RTA_GATEWAY when deleting multipath route [+ + +]
Author: David Ahern <dsahern@kernel.org>
Date:   Thu Dec 30 17:36:34 2021 -0700

    ipv6: Check attribute length for RTA_GATEWAY when deleting multipath route
    
    commit 1ff15a710a862db1101b97810af14aedc835a86a upstream.
    
    Make sure RTA_GATEWAY for IPv6 multipath route has enough bytes to hold
    an IPv6 address.
    
    Fixes: 6b9ea5a64ed5 ("ipv6: fix multipath route replace error recovery")
    Signed-off-by: David Ahern <dsahern@kernel.org>
    Cc: Roopa Prabhu <roopa@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipv6: Continue processing multipath route even if gateway attribute is invalid [+ + +]
Author: David Ahern <dsahern@kernel.org>
Date:   Mon Jan 3 10:19:11 2022 -0700

    ipv6: Continue processing multipath route even if gateway attribute is invalid
    
    [ Upstream commit e30a845b0376eb51c9c94f56bbd53b2e08ba822f ]
    
    ip6_route_multipath_del loop continues processing the multipath
    attribute even if delete of a nexthop path fails. For consistency,
    do the same if the gateway attribute is invalid.
    
    Fixes: 1ff15a710a86 ("ipv6: Check attribute length for RTA_GATEWAY when deleting multipath route")
    Signed-off-by: David Ahern <dsahern@kernel.org>
    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Link: https://lore.kernel.org/r/20220103171911.94739-1-dsahern@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: Do cleanup if attribute validation fails in multipath route [+ + +]
Author: David Ahern <dsahern@kernel.org>
Date:   Mon Jan 3 10:05:55 2022 -0700

    ipv6: Do cleanup if attribute validation fails in multipath route
    
    [ Upstream commit 95bdba23b5b4aa75fe3e6c84335e638641c707bb ]
    
    As Nicolas noted, if gateway validation fails walking the multipath
    attribute the code should jump to the cleanup to free previously
    allocated memory.
    
    Fixes: 1ff15a710a86 ("ipv6: Check attribute length for RTA_GATEWAY when deleting multipath route")
    Signed-off-by: David Ahern <dsahern@kernel.org>
    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Link: https://lore.kernel.org/r/20220103170555.94638-1-dsahern@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: raw: check passed optlen before reading [+ + +]
Author: Tamir Duberstein <tamird@gmail.com>
Date:   Wed Dec 29 15:09:47 2021 -0500

    ipv6: raw: check passed optlen before reading
    
    [ Upstream commit fb7bc9204095090731430c8921f9e629740c110a ]
    
    Add a check that the user-provided option is at least as long as the
    number of bytes we intend to read. Before this patch we would blindly
    read sizeof(int) bytes even in cases where the user passed
    optlen<sizeof(int), which would potentially read garbage or fault.
    
    Discovered by new tests in https://github.com/google/gvisor/pull/6957 .
    
    The original get_user call predates history in the git repo.
    
    Signed-off-by: Tamir Duberstein <tamird@gmail.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20211229200947.2862255-1-willemdebruijn.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: x86: Check for rmaps allocation [+ + +]
Author: Nikunj A Dadhania <nikunj@amd.com>
Date:   Wed Jan 5 09:33:37 2022 +0530

    KVM: x86: Check for rmaps allocation
    
    commit fffb5323780786c81ba005f8b8603d4a558aad28 upstream.
    
    With TDP MMU being the default now, access to mmu_rmaps_stat debugfs
    file causes following oops:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 7 PID: 3185 Comm: cat Not tainted 5.16.0-rc4+ #204
    RIP: 0010:pte_list_count+0x6/0x40
     Call Trace:
      <TASK>
      ? kvm_mmu_rmaps_stat_show+0x15e/0x320
      seq_read_iter+0x126/0x4b0
      ? aa_file_perm+0x124/0x490
      seq_read+0xf5/0x140
      full_proxy_read+0x5c/0x80
      vfs_read+0x9f/0x1a0
      ksys_read+0x67/0xe0
      __x64_sys_read+0x19/0x20
      do_syscall_64+0x3b/0xc0
      entry_SYSCALL_64_after_hwframe+0x44/0xae
     RIP: 0033:0x7fca6fc13912
    
    Return early when rmaps are not present.
    
    Reported-by: Vasant Hegde <vasant.hegde@amd.com>
    Tested-by: Vasant Hegde <vasant.hegde@amd.com>
    Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Reviewed-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220105040337.4234-1-nikunj@amd.com>
    Cc: stable@vger.kernel.org
    Fixes: 3bcd0662d66f ("KVM: X86: Introduce mmu_rmaps_stat per-vm debugfs file")
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 5.15.14 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jan 11 15:35:19 2022 +0100

    Linux 5.15.14
    
    Link: https://lore.kernel.org/r/20220110071821.500480371@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Zan Aziz <zanaziz313@gmail.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
lwtunnel: Validate RTA_ENCAP_TYPE attribute length [+ + +]
Author: David Ahern <dsahern@kernel.org>
Date:   Thu Dec 30 17:36:35 2021 -0700

    lwtunnel: Validate RTA_ENCAP_TYPE attribute length
    
    commit 8bda81a4d400cf8a72e554012f0d8c45e07a3904 upstream.
    
    lwtunnel_valid_encap_type_attr is used to validate encap attributes
    within a multipath route. Add length validation checking to the type.
    
    lwtunnel_valid_encap_type_attr is called converting attributes to
    fib{6,}_config struct which means it is used before fib_get_nhs,
    ip6_route_multipath_add, and ip6_route_multipath_del - other
    locations that use rtnh_ok and then nla_get_u16 on RTA_ENCAP_TYPE
    attribute.
    
    Fixes: 9ed59592e3e3 ("lwtunnel: fix autoload of lwt modules")
    
    Signed-off-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mac80211: initialize variable have_higher_than_11mbit [+ + +]
Author: Tom Rix <trix@redhat.com>
Date:   Thu Dec 23 08:28:48 2021 -0800

    mac80211: initialize variable have_higher_than_11mbit
    
    commit 68a18ad71378a56858141c4449e02a30c829763e upstream.
    
    Clang static analysis reports this warnings
    
    mlme.c:5332:7: warning: Branch condition evaluates to a
      garbage value
        have_higher_than_11mbit)
        ^~~~~~~~~~~~~~~~~~~~~~~
    
    have_higher_than_11mbit is only set to true some of the time in
    ieee80211_get_rates() but is checked all of the time.  So
    have_higher_than_11mbit needs to be initialized to false.
    
    Fixes: 5d6a1b069b7f ("mac80211: set basic rates earlier")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Link: https://lore.kernel.org/r/20211223162848.3243702-1-trix@redhat.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mac80211: mesh: embedd mesh_paths and mpp_paths into ieee80211_if_mesh [+ + +]
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Dec 30 22:55:47 2021 +0300

    mac80211: mesh: embedd mesh_paths and mpp_paths into ieee80211_if_mesh
    
    commit 8b5cb7e41d9d77ffca036b0239177de123394a55 upstream.
    
    Syzbot hit NULL deref in rhashtable_free_and_destroy(). The problem was
    in mesh_paths and mpp_paths being NULL.
    
    mesh_pathtbl_init() could fail in case of memory allocation failure, but
    nobody cared, since ieee80211_mesh_init_sdata() returns void. It led to
    leaving 2 pointers as NULL. Syzbot has found null deref on exit path,
    but it could happen anywhere else, because code assumes these pointers are
    valid.
    
    Since all ieee80211_*_setup_sdata functions are void and do not fail,
    let's embedd mesh_paths and mpp_paths into parent struct to avoid
    adding error handling on higher levels and follow the pattern of others
    setup_sdata functions
    
    Fixes: 60854fd94573 ("mac80211: mesh: convert path table to rhashtable")
    Reported-and-tested-by: syzbot+860268315ba86ea6b96b@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Link: https://lore.kernel.org/r/20211230195547.23977-1-paskripkin@gmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
md/raid1: fix missing bitmap update w/o WriteMostly devices [+ + +]
Author: Song Liu <song@kernel.org>
Date:   Mon Jan 3 13:49:36 2022 -0800

    md/raid1: fix missing bitmap update w/o WriteMostly devices
    
    commit 46669e8616c649c71c4cfcd712fd3d107e771380 upstream.
    
    commit [1] causes missing bitmap updates when there isn't any WriteMostly
    devices.
    
    Detailed steps to reproduce by Norbert (which somehow didn't make to lore):
    
       # setup md10 (raid1) with two drives (1 GByte sparse files)
       dd if=/dev/zero of=disk1 bs=1024k seek=1024 count=0
       dd if=/dev/zero of=disk2 bs=1024k seek=1024 count=0
    
       losetup /dev/loop11 disk1
       losetup /dev/loop12 disk2
    
       mdadm --create /dev/md10 --level=1 --raid-devices=2 /dev/loop11 /dev/loop12
    
       # add bitmap (aka write-intent log)
       mdadm /dev/md10 --grow --bitmap=internal
    
       echo check > /sys/block/md10/md/sync_action
    
       root:# cat /sys/block/md10/md/mismatch_cnt
       0
       root:#
    
       # remove member drive disk2 (loop12)
       mdadm /dev/md10 -f loop12 ; mdadm /dev/md10 -r loop12
    
       # modify degraded md device
       dd if=/dev/urandom of=/dev/md10 bs=512 count=1
    
       # no blocks recorded as out of sync on the remaining member disk1/loop11
       root:# mdadm -X /dev/loop11 | grep Bitmap
                 Bitmap : 16 bits (chunks), 0 dirty (0.0%)
       root:#
    
       # re-add disk2, nothing synced because of empty bitmap
       mdadm /dev/md10 --re-add /dev/loop12
    
       # check integrity again
       echo check > /sys/block/md10/md/sync_action
    
       # disk1 and disk2 are no longer in sync, reads return differend data
       root:# cat /sys/block/md10/md/mismatch_cnt
       128
       root:#
    
       # clean up
       mdadm -S /dev/md10
       losetup -d /dev/loop11
       losetup -d /dev/loop12
       rm disk1 disk2
    
    Fix this by moving the WriteMostly check to the if condition for
    alloc_behind_master_bio().
    
    [1] commit fd3b6975e9c1 ("md/raid1: only allocate write behind bio for WriteMostly device")
    Fixes: fd3b6975e9c1 ("md/raid1: only allocate write behind bio for WriteMostly device")
    Cc: stable@vger.kernel.org # v5.12+
    Cc: Guoqing Jiang <guoqing.jiang@linux.dev>
    Cc: Jens Axboe <axboe@kernel.dk>
    Reported-by: Norbert Warmuth <nwarmuth@t-online.de>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mISDN: change function names to avoid conflicts [+ + +]
Author: wolfgang huang <huangjinhui@kylinos.cn>
Date:   Tue Dec 28 16:01:20 2021 +0800

    mISDN: change function names to avoid conflicts
    
    [ Upstream commit 8b5fdfc57cc2471179d1c51081424ded833c16c8 ]
    
    As we build for mips, we meet following error. l1_init error with
    multiple definition. Some architecture devices usually marked with
    l1, l2, lxx as the start-up phase. so we change the mISDN function
    names, align with Isdnl2_xxx.
    
    mips-linux-gnu-ld: drivers/isdn/mISDN/layer1.o: in function `l1_init':
    (.text+0x890): multiple definition of `l1_init'; \
    arch/mips/kernel/bmips_5xxx_init.o:(.text+0xf0): first defined here
    make[1]: *** [home/mips/kernel-build/linux/Makefile:1161: vmlinux] Error 1
    
    Signed-off-by: wolfgang huang <huangjinhui@kylinos.cn>
    Reported-by: k2ci <kernel-bot@kylinos.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: net ticp:fix a kernel-infoleak in __tipc_sendmsg() [+ + +]
Author: Haimin Zhang <tcs_kernel@tencent.com>
Date:   Fri Dec 31 10:35:23 2021 +0800

    net ticp:fix a kernel-infoleak in __tipc_sendmsg()
    
    commit d6d86830705f173fca6087a3e67ceaf68db80523 upstream.
    
    struct tipc_socket_addr.ref has a 4-byte hole,and __tipc_getname() currently
    copying it to user space,causing kernel-infoleak.
    
    BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
    BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] lib/usercopy.c:33
    BUG: KMSAN: kernel-infoleak in _copy_to_user+0x1c9/0x270 lib/usercopy.c:33 lib/usercopy.c:33
     instrument_copy_to_user include/linux/instrumented.h:121 [inline]
     instrument_copy_to_user include/linux/instrumented.h:121 [inline] lib/usercopy.c:33
     _copy_to_user+0x1c9/0x270 lib/usercopy.c:33 lib/usercopy.c:33
     copy_to_user include/linux/uaccess.h:209 [inline]
     copy_to_user include/linux/uaccess.h:209 [inline] net/socket.c:287
     move_addr_to_user+0x3f6/0x600 net/socket.c:287 net/socket.c:287
     __sys_getpeername+0x470/0x6b0 net/socket.c:1987 net/socket.c:1987
     __do_sys_getpeername net/socket.c:1997 [inline]
     __se_sys_getpeername net/socket.c:1994 [inline]
     __do_sys_getpeername net/socket.c:1997 [inline] net/socket.c:1994
     __se_sys_getpeername net/socket.c:1994 [inline] net/socket.c:1994
     __x64_sys_getpeername+0xda/0x120 net/socket.c:1994 net/socket.c:1994
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_x64 arch/x86/entry/common.c:51 [inline] arch/x86/entry/common.c:82
     do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 arch/x86/entry/common.c:82
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Uninit was stored to memory at:
     tipc_getname+0x575/0x5e0 net/tipc/socket.c:757 net/tipc/socket.c:757
     __sys_getpeername+0x3b3/0x6b0 net/socket.c:1984 net/socket.c:1984
     __do_sys_getpeername net/socket.c:1997 [inline]
     __se_sys_getpeername net/socket.c:1994 [inline]
     __do_sys_getpeername net/socket.c:1997 [inline] net/socket.c:1994
     __se_sys_getpeername net/socket.c:1994 [inline] net/socket.c:1994
     __x64_sys_getpeername+0xda/0x120 net/socket.c:1994 net/socket.c:1994
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_x64 arch/x86/entry/common.c:51 [inline] arch/x86/entry/common.c:82
     do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 arch/x86/entry/common.c:82
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Uninit was stored to memory at:
     msg_set_word net/tipc/msg.h:212 [inline]
     msg_set_destport net/tipc/msg.h:619 [inline]
     msg_set_word net/tipc/msg.h:212 [inline] net/tipc/socket.c:1486
     msg_set_destport net/tipc/msg.h:619 [inline] net/tipc/socket.c:1486
     __tipc_sendmsg+0x44fa/0x5890 net/tipc/socket.c:1486 net/tipc/socket.c:1486
     tipc_sendmsg+0xeb/0x140 net/tipc/socket.c:1402 net/tipc/socket.c:1402
     sock_sendmsg_nosec net/socket.c:704 [inline]
     sock_sendmsg net/socket.c:724 [inline]
     sock_sendmsg_nosec net/socket.c:704 [inline] net/socket.c:2409
     sock_sendmsg net/socket.c:724 [inline] net/socket.c:2409
     ____sys_sendmsg+0xe11/0x12c0 net/socket.c:2409 net/socket.c:2409
     ___sys_sendmsg net/socket.c:2463 [inline]
     ___sys_sendmsg net/socket.c:2463 [inline] net/socket.c:2492
     __sys_sendmsg+0x704/0x840 net/socket.c:2492 net/socket.c:2492
     __do_sys_sendmsg net/socket.c:2501 [inline]
     __se_sys_sendmsg net/socket.c:2499 [inline]
     __do_sys_sendmsg net/socket.c:2501 [inline] net/socket.c:2499
     __se_sys_sendmsg net/socket.c:2499 [inline] net/socket.c:2499
     __x64_sys_sendmsg+0xe2/0x120 net/socket.c:2499 net/socket.c:2499
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_x64 arch/x86/entry/common.c:51 [inline] arch/x86/entry/common.c:82
     do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 arch/x86/entry/common.c:82
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Local variable skaddr created at:
     __tipc_sendmsg+0x2d0/0x5890 net/tipc/socket.c:1419 net/tipc/socket.c:1419
     tipc_sendmsg+0xeb/0x140 net/tipc/socket.c:1402 net/tipc/socket.c:1402
    
    Bytes 4-7 of 16 are uninitialized
    Memory access of size 16 starts at ffff888113753e00
    Data copied to user address 0000000020000280
    
    Reported-by: syzbot+cdbd40e0c3ca02cae3b7@syzkaller.appspotmail.com
    Signed-off-by: Haimin Zhang <tcs_kernel@tencent.com>
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Link: https://lore.kernel.org/r/1640918123-14547-1-git-send-email-tcs.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: ena: Fix error handling when calculating max IO queues number [+ + +]
Author: Arthur Kiyanovski <akiyano@amazon.com>
Date:   Sun Jan 2 07:37:28 2022 +0000

    net: ena: Fix error handling when calculating max IO queues number
    
    commit 5055dc0348b8b7c168e3296044bccd724e1ae6cd upstream.
    
    The role of ena_calc_max_io_queue_num() is to return the number
    of queues supported by the device, which means the return value
    should be >=0.
    
    The function that calls ena_calc_max_io_queue_num(), checks
    the return value. If it is 0, it means the device reported
    it supports 0 IO queues. This case is considered an error
    and is handled by the calling function accordingly.
    
    However the current implementation of ena_calc_max_io_queue_num()
    is wrong, since when it detects the device supports 0 IO queues,
    it returns -EFAULT.
    
    In such a case the calling function doesn't detect the error,
    and therefore doesn't handle it.
    
    This commit changes ena_calc_max_io_queue_num() to return 0
    in case the device reported it supports 0 queues, allowing the
    calling function to properly handle the error case.
    
    Fixes: 736ce3f414cc ("net: ena: make ethtool -l show correct max number of queues")
    Signed-off-by: Shay Agroskin <shayagr@amazon.com>
    Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: ena: Fix undefined state when tx request id is out of bounds [+ + +]
Author: Arthur Kiyanovski <akiyano@amazon.com>
Date:   Sun Jan 2 07:37:26 2022 +0000

    net: ena: Fix undefined state when tx request id is out of bounds
    
    commit c255a34e02efb1393d23ffb205ba1a11320aeffb upstream.
    
    ena_com_tx_comp_req_id_get() checks the req_id of a received completion,
    and if it is out of bounds returns -EINVAL. This is a sign that
    something is wrong with the device and it needs to be reset.
    
    The current code does not reset the device in this case, which leaves
    the driver in an undefined state, where this completion is not properly
    handled.
    
    This commit adds a call to handle_invalid_req_id() in ena_clean_tx_irq()
    and ena_clean_xdp_irq() which resets the device to fix the issue.
    
    This commit also removes unnecessary request id checks from
    validate_tx_req_id() and validate_xdp_req_id(). This check is unneeded
    because it was already performed in ena_com_tx_comp_req_id_get(), which
    is called right before these functions.
    
    Fixes: 548c4940b9f1 ("net: ena: Implement XDP_TX action")
    Signed-off-by: Shay Agroskin <shayagr@amazon.com>
    Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: ena: Fix wrong rx request id by resetting device [+ + +]
Author: Arthur Kiyanovski <akiyano@amazon.com>
Date:   Sun Jan 2 07:37:27 2022 +0000

    net: ena: Fix wrong rx request id by resetting device
    
    commit cb3d4f98f0b26eafa0b913ac3716e4714254a747 upstream.
    
    A wrong request id received from the device is a sign that
    something is wrong with it, therefore trigger a device reset.
    
    Also add some debug info to the "Page is NULL" print to make
    it easier to debug.
    
    Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
    Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: udp: fix alignment problem in udp4_seq_show() [+ + +]
Author: yangxingwu <xingwu.yang@gmail.com>
Date:   Mon Dec 27 16:29:51 2021 +0800

    net: udp: fix alignment problem in udp4_seq_show()
    
    [ Upstream commit 6c25449e1a32c594d743df8e8258e8ef870b6a77 ]
    
    $ cat /pro/net/udp
    
    before:
    
      sl  local_address rem_address   st tx_queue rx_queue tr tm->when
    26050: 0100007F:0035 00000000:0000 07 00000000:00000000 00:00000000
    26320: 0100007F:0143 00000000:0000 07 00000000:00000000 00:00000000
    27135: 00000000:8472 00000000:0000 07 00000000:00000000 00:00000000
    
    after:
    
       sl  local_address rem_address   st tx_queue rx_queue tr tm->when
    26050: 0100007F:0035 00000000:0000 07 00000000:00000000 00:00000000
    26320: 0100007F:0143 00000000:0000 07 00000000:00000000 00:00000000
    27135: 00000000:8472 00000000:0000 07 00000000:00000000 00:00000000
    
    Signed-off-by: yangxingwu <xingwu.yang@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netrom: fix copying in user data in nr_setsockopt [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue Jan 4 10:21:26 2022 +0100

    netrom: fix copying in user data in nr_setsockopt
    
    commit 3087a6f36ee028ec095c04a8531d7d33899b7fed upstream.
    
    This code used to copy in an unsigned long worth of data before
    the sockptr_t conversion, so restore that.
    
    Fixes: a7b75c5a8c41 ("net: pass a sockptr_t into ->setsockopt")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
phonet: refcount leak in pep_sock_accep [+ + +]
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Thu Dec 9 16:28:39 2021 +0800

    phonet: refcount leak in pep_sock_accep
    
    commit bcd0f93353326954817a4f9fa55ec57fb38acbb0 upstream.
    
    sock_hold(sk) is invoked in pep_sock_accept(), but __sock_put(sk) is not
    invoked in subsequent failure branches(pep_accept_conn() != 0).
    
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Link: https://lore.kernel.org/r/20211209082839.33985-1-hbh25y@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Aayush Agarwal <aayush.a.agarwal@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
power: bq25890: Enable continuous conversion for ADC at charging [+ + +]
Author: Yauhen Kharuzhy <jekhor@gmail.com>
Date:   Sun Nov 7 23:20:01 2021 +0300

    power: bq25890: Enable continuous conversion for ADC at charging
    
    commit 80211be1b9dec04cc2805d3d81e2091ecac289a1 upstream.
    
    Instead of one shot run of ADC at beginning of charging, run continuous
    conversion to ensure that all charging-related values are monitored
    properly (input voltage, input current, themperature etc.).
    
    Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

power: reset: ltc2952: Fix use of floating point literals [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Fri Nov 5 08:20:50 2021 -0700

    power: reset: ltc2952: Fix use of floating point literals
    
    commit 644106cdb89844be2496b21175b7c0c2e0fab381 upstream.
    
    A new commit in LLVM causes an error on the use of 'long double' when
    '-mno-x87' is used, which the kernel does through an alias,
    '-mno-80387' (see the LLVM commit below for more details around why it
    does this).
    
    drivers/power/reset/ltc2952-poweroff.c:162:28: error: expression requires  'long double' type support, but target 'x86_64-unknown-linux-gnu' does not support it
            data->wde_interval = 300L * 1E6L;
                                      ^
    drivers/power/reset/ltc2952-poweroff.c:162:21: error: expression requires  'long double' type support, but target 'x86_64-unknown-linux-gnu' does not support it
            data->wde_interval = 300L * 1E6L;
                               ^
    drivers/power/reset/ltc2952-poweroff.c:163:41: error: expression requires  'long double' type support, but target 'x86_64-unknown-linux-gnu' does not support it
            data->trigger_delay = ktime_set(2, 500L*1E6L);
                                                   ^
    3 errors generated.
    
    This happens due to the use of a 'long double' literal. The 'E6' part of
    '1E6L' causes the literal to be a 'double' then the 'L' suffix promotes
    it to 'long double'.
    
    There is no visible reason for floating point values in this driver, as
    the values are only assigned to integer types. Use NSEC_PER_MSEC, which
    is the same integer value as '1E6L', to avoid changing functionality but
    fix the error.
    
    Fixes: 6647156c00cc ("power: reset: add LTC2952 poweroff driver")
    Link: https://github.com/ClangBuiltLinux/linux/issues/1497
    Link: https://github.com/llvm/llvm-project/commit/a8083d42b1c346e21623a1d36d1f0cadd7801d83
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

power: supply: core: Break capacity loop [+ + +]
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Mon Nov 15 00:12:07 2021 +0100

    power: supply: core: Break capacity loop
    
    commit 51c7b6a0398f54b9120795796a4cff4fc9634f7d upstream.
    
    We should not go on looking for more capacity tables after
    we realize we have looked at the last one in
    power_supply_find_ocv2cap_table().
    
    Fixes: 3afb50d7125b ("power: supply: core: Add some helpers to use the battery OCV capacity table")
    Cc: Chunyan Zhang <chunyan.zhang@unisoc.com>
    Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RDMA/core: Don't infoleak GRH fields [+ + +]
Author: Leon Romanovsky <leon@kernel.org>
Date:   Tue Jan 4 14:21:52 2022 +0200

    RDMA/core: Don't infoleak GRH fields
    
    commit b35a0f4dd544eaa6162b6d2f13a2557a121ae5fd upstream.
    
    If dst->is_global field is not set, the GRH fields are not cleared
    and the following infoleak is reported.
    
    =====================================================
    BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
    BUG: KMSAN: kernel-infoleak in _copy_to_user+0x1c9/0x270 lib/usercopy.c:33
     instrument_copy_to_user include/linux/instrumented.h:121 [inline]
     _copy_to_user+0x1c9/0x270 lib/usercopy.c:33
     copy_to_user include/linux/uaccess.h:209 [inline]
     ucma_init_qp_attr+0x8c7/0xb10 drivers/infiniband/core/ucma.c:1242
     ucma_write+0x637/0x6c0 drivers/infiniband/core/ucma.c:1732
     vfs_write+0x8ce/0x2030 fs/read_write.c:588
     ksys_write+0x28b/0x510 fs/read_write.c:643
     __do_sys_write fs/read_write.c:655 [inline]
     __se_sys_write fs/read_write.c:652 [inline]
     __ia32_sys_write+0xdb/0x120 fs/read_write.c:652
     do_syscall_32_irqs_on arch/x86/entry/common.c:114 [inline]
     __do_fast_syscall_32+0x96/0xf0 arch/x86/entry/common.c:180
     do_fast_syscall_32+0x34/0x70 arch/x86/entry/common.c:205
     do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248
     entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
    
    Local variable resp created at:
     ucma_init_qp_attr+0xa4/0xb10 drivers/infiniband/core/ucma.c:1214
     ucma_write+0x637/0x6c0 drivers/infiniband/core/ucma.c:1732
    
    Bytes 40-59 of 144 are uninitialized
    Memory access of size 144 starts at ffff888167523b00
    Data copied to user address 0000000020000100
    
    CPU: 1 PID: 25910 Comm: syz-executor.1 Not tainted 5.16.0-rc5-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    =====================================================
    
    Fixes: 4ba66093bdc6 ("IB/core: Check for global flag when using ah_attr")
    Link: https://lore.kernel.org/r/0e9dd51f93410b7b2f4f5562f52befc878b71afa.1641298868.git.leonro@nvidia.com
    Reported-by: syzbot+6d532fa8f9463da290bc@syzkaller.appspotmail.com
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RDMA/uverbs: Check for null return of kmalloc_array [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Fri Dec 31 17:33:15 2021 +0800

    RDMA/uverbs: Check for null return of kmalloc_array
    
    commit 7694a7de22c53a312ea98960fcafc6ec62046531 upstream.
    
    Because of the possible failure of the allocation, data might be NULL
    pointer and will cause the dereference of the NULL pointer later.
    Therefore, it might be better to check it and return -ENOMEM.
    
    Fixes: 6884c6c4bd09 ("RDMA/verbs: Store the write/write_ex uapi entry points in the uverbs_api")
    Link: https://lore.kernel.org/r/20211231093315.1917667-1-jiasheng@iscas.ac.cn
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
reset: renesas: Fix Runtime PM usage [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed Dec 15 11:14:23 2021 +0100

    reset: renesas: Fix Runtime PM usage
    
    commit 92c959bae2e54ba1e2540ba5f813f7752bd76be1 upstream.
    
    If pm_runtime_resume_and_get() fails then it returns w/o the RPM usage
    counter being incremented. In this case call pm_runtime_put() in
    remove() will result in a usage counter imbalance. Therefore check the
    return code of pm_runtime_resume_and_get() and bail out in case of error.
    
    Fixes: bee08559701f ("reset: renesas: Add RZ/G2L usbphy control driver")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
    Link: https://lore.kernel.org/r/ec24e13f-0530-b091-7a08-864577b9b3be@gmail.com
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "drm/amdgpu: stop scheduler when calling hw_fini (v2)" [+ + +]
Author: Len Brown <len.brown@intel.com>
Date:   Sun Jan 9 13:11:37 2022 -0500

    Revert "drm/amdgpu: stop scheduler when calling hw_fini (v2)"
    
    commit df5bc0aa7ff6e2e14cb75182b4eda20253c711d4 upstream.
    
    This reverts commit f7d6779df642720e22bffd449e683bb8690bd3bf.
    
    This bisected regression has impacted suspend-resume stability
    since 5.15-rc1. It regressed -stable via 5.14.10.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215315
    Fixes: f7d6779df64 ("drm/amdgpu: stop scheduler when calling hw_fini (v2)")
    Cc: Guchun Chen <guchun.chen@amd.com>
    Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
    Cc: Christian Koenig <christian.koenig@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: <stable@vger.kernel.org> # 5.14+
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "i2c: core: support bus regulator controlling in adapter" [+ + +]
Author: Wolfram Sang <wsa@kernel.org>
Date:   Thu Jan 6 13:24:52 2022 +0100

    Revert "i2c: core: support bus regulator controlling in adapter"
    
    commit a19f75de73c220b4496d2aefb7a605dd032f7c01 upstream.
    
    This largely reverts commit 5a7b95fb993ec399c8a685552aa6a8fc995c40bd. It
    breaks suspend with AMD GPUs, and we couldn't incrementally fix it. So,
    let's remove the code and go back to the drawing board. We keep the
    header extension to not break drivers already populating the regulator.
    We expect to re-add the code handling it soon.
    
    Fixes: 5a7b95fb993e ("i2c: core: support bus regulator controlling in adapter")
    Reported-by: "Tareque Md.Hanif" <tarequemd.hanif@yahoo.com>
    Link: https://lore.kernel.org/r/1295184560.182511.1639075777725@mail.yahoo.com
    Reported-by: Konstantin Kharlamov <hi-angel@yandex.ru>
    Link: https://lore.kernel.org/r/7143a7147978f4104171072d9f5225d2ce355ec1.camel@yandex.ru
    BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1850
    Tested-by: "Tareque Md.Hanif" <tarequemd.hanif@yahoo.com>
    Tested-by: Konstantin Kharlamov <hi-angel@yandex.ru>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Cc: <stable@vger.kernel.org> # 5.14+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "net: usb: r8152: Add MAC passthrough support for more Lenovo Docks" [+ + +]
Author: Aaron Ma <aaron.ma@canonical.com>
Date:   Wed Jan 5 23:51:02 2022 +0800

    Revert "net: usb: r8152: Add MAC passthrough support for more Lenovo Docks"
    
    commit 00fcf8c7dd564c44448ff6a39728d2ca0c8efbd8 upstream.
    
    This reverts commit f77b83b5bbab53d2be339184838b19ed2c62c0a5.
    
    This change breaks multiple usb to ethernet dongles attached on Lenovo
    USB hub.
    
    Fixes: f77b83b5bbab ("net: usb: r8152: Add MAC passthrough support for more Lenovo Docks")
    Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
    Link: https://lore.kernel.org/r/20220105155102.8557-1-aaron.ma@canonical.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow" [+ + +]
Author: Maor Gottlieb <maorg@nvidia.com>
Date:   Wed Dec 22 12:13:12 2021 +0200

    Revert "RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow"
    
    commit 4163cb3d1980383220ad7043002b930995dcba33 upstream.
    
    This patch is not the full fix and still causes to call traces
    during mlx5_ib_dereg_mr().
    
    This reverts commit f0ae4afe3d35e67db042c58a52909e06262b740f.
    
    Fixes: f0ae4afe3d35 ("RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow")
    Link: https://lore.kernel.org/r/20211222101312.1358616-1-maorg@nvidia.com
    Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
    Acked-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rndis_host: support Hytera digital radios [+ + +]
Author: Thomas Toye <thomas@toye.io>
Date:   Sat Jan 1 18:22:07 2022 +0100

    rndis_host: support Hytera digital radios
    
    commit 29262e1f773b4b6a43711120be564c57fca07cfb upstream.
    
    Hytera makes a range of digital (DMR) radios. These radios can be
    programmed to a allow a computer to control them over Ethernet over USB,
    either using NCM or RNDIS.
    
    This commit adds support for RNDIS for Hytera radios. I tested with a
    Hytera PD785 and a Hytera MD785G. When these radios are programmed to
    set up a Radio to PC Network using RNDIS, an USB interface will be added
    with class 2 (Communications), subclass 2 (Abstract Modem Control) and
    an interface protocol of 255 ("vendor specific" - lsusb even hints "MSFT
    RNDIS?").
    
    This patch is similar to the solution of this StackOverflow user, but
    that only works for the Hytera MD785:
    https://stackoverflow.com/a/53550858
    
    To use the "Radio to PC Network" functionality of Hytera DMR radios, the
    radios need to be programmed correctly in CPS (Hytera's Customer
    Programming Software). "Forward to PC" should be checked in "Network"
    (under "General Setting" in "Conventional") and the "USB Network
    Communication Protocol" should be set to RNDIS.
    
    Signed-off-by: Thomas Toye <thomas@toye.io>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sch_qfq: prevent shift-out-of-bounds in qfq_init_qdisc [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jan 4 01:45:08 2022 -0800

    sch_qfq: prevent shift-out-of-bounds in qfq_init_qdisc
    
    commit 7d18a07897d07495ee140dd319b0e9265c0f68ba upstream.
    
    tx_queue_len can be set to ~0U, we need to be more
    careful about overflows.
    
    __fls(0) is undefined, as this report shows:
    
    UBSAN: shift-out-of-bounds in net/sched/sch_qfq.c:1430:24
    shift exponent 51770272 is too large for 32-bit type 'int'
    CPU: 0 PID: 25574 Comm: syz-executor.0 Not tainted 5.16.0-rc7-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x201/0x2d8 lib/dump_stack.c:106
     ubsan_epilogue lib/ubsan.c:151 [inline]
     __ubsan_handle_shift_out_of_bounds+0x494/0x530 lib/ubsan.c:330
     qfq_init_qdisc+0x43f/0x450 net/sched/sch_qfq.c:1430
     qdisc_create+0x895/0x1430 net/sched/sch_api.c:1253
     tc_modify_qdisc+0x9d9/0x1e20 net/sched/sch_api.c:1660
     rtnetlink_rcv_msg+0x934/0xe60 net/core/rtnetlink.c:5571
     netlink_rcv_skb+0x200/0x470 net/netlink/af_netlink.c:2496
     netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
     netlink_unicast+0x814/0x9f0 net/netlink/af_netlink.c:1345
     netlink_sendmsg+0xaea/0xe60 net/netlink/af_netlink.c:1921
     sock_sendmsg_nosec net/socket.c:704 [inline]
     sock_sendmsg net/socket.c:724 [inline]
     ____sys_sendmsg+0x5b9/0x910 net/socket.c:2409
     ___sys_sendmsg net/socket.c:2463 [inline]
     __sys_sendmsg+0x280/0x370 net/socket.c:2492
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fixes: 462dbc9101ac ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
scsi: libiscsi: Fix UAF in iscsi_conn_get_param()/iscsi_conn_teardown() [+ + +]
Author: Lixiaokeng <lixiaokeng@huawei.com>
Date:   Mon Dec 20 19:39:06 2021 +0800

    scsi: libiscsi: Fix UAF in iscsi_conn_get_param()/iscsi_conn_teardown()
    
    [ Upstream commit 1b8d0300a3e9f216ae4901bab886db7299899ec6 ]
    
    |- iscsi_if_destroy_conn            |-dev_attr_show
     |-iscsi_conn_teardown
      |-spin_lock_bh                     |-iscsi_sw_tcp_conn_get_param
    
      |-kfree(conn->persistent_address)   |-iscsi_conn_get_param
      |-kfree(conn->local_ipaddr)
                                           ==>|-read persistent_address
                                           ==>|-read local_ipaddr
      |-spin_unlock_bh
    
    When iscsi_conn_teardown() and iscsi_conn_get_param() happen in parallel, a
    UAF may be triggered.
    
    Link: https://lore.kernel.org/r/046ec8a0-ce95-d3fc-3235-666a7c65b224@huawei.com
    Reported-by: Lu Tixiong <lutianxiong@huawei.com>
    Reviewed-by: Mike Christie <michael.christie@oracle.com>
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
    Signed-off-by: Linfeilong <linfeilong@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sctp: hold endpoint before calling cb in sctp_transport_lookup_process [+ + +]
Author: Xin Long <lucien.xin@gmail.com>
Date:   Fri Dec 31 18:37:37 2021 -0500

    sctp: hold endpoint before calling cb in sctp_transport_lookup_process
    
    commit f9d31c4cf4c11ff10317f038b9c6f7c3bda6cdd4 upstream.
    
    The same fix in commit 5ec7d18d1813 ("sctp: use call_rcu to free endpoint")
    is also needed for dumping one asoc and sock after the lookup.
    
    Fixes: 86fdb3448cc1 ("sctp: ensure ep is not destroyed before doing the dump")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests: net: udpgro_fwd.sh: explicitly checking the available ping feature [+ + +]
Author: Jianguo Wu <wujianguo@chinatelecom.cn>
Date:   Fri Dec 31 10:01:08 2021 +0800

    selftests: net: udpgro_fwd.sh: explicitly checking the available ping feature
    
    commit 5e75d0b215b868337e7a193f28a543ec00e858b1 upstream.
    
    As Paolo pointed out, the result of ping IPv6 address depends on
    the running distro. So explicitly checking the available ping feature,
    as e.g. do the bareudp.sh self-tests.
    
    Fixes: 8b3170e07539 ("selftests: net: using ping6 for IPv6 in udpgro_fwd.sh")
    Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
    Link: https://lore.kernel.org/r/825ee22b-4245-dbf7-d2f7-a230770d6e21@163.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: x86: fix [-Wstringop-overread] warn in test_process_vm_readv() [+ + +]
Author: Shuah Khan <skhan@linuxfoundation.org>
Date:   Thu Oct 21 15:33:33 2021 -0600

    selftests: x86: fix [-Wstringop-overread] warn in test_process_vm_readv()
    
    commit dd40f44eabe1e122c6852fabb298aac05b083fce upstream.
    
    Fix the following [-Wstringop-overread] by passing in the variable
    instead of the value.
    
    test_vsyscall.c: In function ‘test_process_vm_readv’:
    test_vsyscall.c:500:22: warning: ‘__builtin_memcmp_eq’ specified bound 4096 exceeds source size 0 [-Wstringop-overread]
      500 |                 if (!memcmp(buf, (const void *)0xffffffffff600000, 4096)) {
          |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sfc: The RX page_ring is optional [+ + +]
Author: Martin Habets <habetsm.xilinx@gmail.com>
Date:   Sun Jan 2 08:41:22 2022 +0000

    sfc: The RX page_ring is optional
    
    commit 1d5a474240407c38ca8c7484a656ee39f585399c upstream.
    
    The RX page_ring is an optional feature that improves
    performance. When allocation fails the driver can still
    function, but possibly with a lower bandwidth.
    Guard against dereferencing a NULL page_ring.
    
    Fixes: 2768935a4660 ("sfc: reuse pages to avoid DMA mapping/unmapping costs")
    Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com>
    Reported-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/164111288276.5798.10330502993729113868.stgit@palantir17.mph.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing: Fix check for trace_percpu_buffer validity in get_trace_buf() [+ + +]
Author: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Date:   Thu Dec 23 16:04:38 2021 +0530

    tracing: Fix check for trace_percpu_buffer validity in get_trace_buf()
    
    commit 823e670f7ed616d0ce993075c8afe0217885f79d upstream.
    
    With the new osnoise tracer, we are seeing the below splat:
        Kernel attempted to read user page (c7d880000) - exploit attempt? (uid: 0)
        BUG: Unable to handle kernel data access on read at 0xc7d880000
        Faulting instruction address: 0xc0000000002ffa10
        Oops: Kernel access of bad area, sig: 11 [#1]
        LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
        ...
        NIP [c0000000002ffa10] __trace_array_vprintk.part.0+0x70/0x2f0
        LR [c0000000002ff9fc] __trace_array_vprintk.part.0+0x5c/0x2f0
        Call Trace:
        [c0000008bdd73b80] [c0000000001c49cc] put_prev_task_fair+0x3c/0x60 (unreliable)
        [c0000008bdd73be0] [c000000000301430] trace_array_printk_buf+0x70/0x90
        [c0000008bdd73c00] [c0000000003178b0] trace_sched_switch_callback+0x250/0x290
        [c0000008bdd73c90] [c000000000e70d60] __schedule+0x410/0x710
        [c0000008bdd73d40] [c000000000e710c0] schedule+0x60/0x130
        [c0000008bdd73d70] [c000000000030614] interrupt_exit_user_prepare_main+0x264/0x270
        [c0000008bdd73de0] [c000000000030a70] syscall_exit_prepare+0x150/0x180
        [c0000008bdd73e10] [c00000000000c174] system_call_vectored_common+0xf4/0x278
    
    osnoise tracer on ppc64le is triggering osnoise_taint() for negative
    duration in get_int_safe_duration() called from
    trace_sched_switch_callback()->thread_exit().
    
    The problem though is that the check for a valid trace_percpu_buffer is
    incorrect in get_trace_buf(). The check is being done after calculating
    the pointer for the current cpu, rather than on the main percpu pointer.
    Fix the check to be against trace_percpu_buffer.
    
    Link: https://lkml.kernel.org/r/a920e4272e0b0635cf20c444707cbce1b2c8973d.1640255304.git.naveen.n.rao@linux.vnet.ibm.com
    
    Cc: stable@vger.kernel.org
    Fixes: e2ace001176dc9 ("tracing: Choose static tp_printk buffer by explicit nesting count")
    Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tracing: Tag trace_percpu_buffer as a percpu pointer [+ + +]
Author: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Date:   Thu Dec 23 16:04:39 2021 +0530

    tracing: Tag trace_percpu_buffer as a percpu pointer
    
    commit f28439db470cca8b6b082239314e9fd10bd39034 upstream.
    
    Tag trace_percpu_buffer as a percpu pointer to resolve warnings
    reported by sparse:
      /linux/kernel/trace/trace.c:3218:46: warning: incorrect type in initializer (different address spaces)
      /linux/kernel/trace/trace.c:3218:46:    expected void const [noderef] __percpu *__vpp_verify
      /linux/kernel/trace/trace.c:3218:46:    got struct trace_buffer_struct *
      /linux/kernel/trace/trace.c:3234:9: warning: incorrect type in initializer (different address spaces)
      /linux/kernel/trace/trace.c:3234:9:    expected void const [noderef] __percpu *__vpp_verify
      /linux/kernel/trace/trace.c:3234:9:    got int *
    
    Link: https://lkml.kernel.org/r/ebabd3f23101d89cb75671b68b6f819f5edc830b.1640255304.git.naveen.n.rao@linux.vnet.ibm.com
    
    Cc: stable@vger.kernel.org
    Reported-by: kernel test robot <lkp@intel.com>
    Fixes: 07d777fe8c398 ("tracing: Add percpu buffers for trace_printk()")
    Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: mtu3: fix interval value for intr and isoc [+ + +]
Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date:   Sat Dec 18 17:57:46 2021 +0800

    usb: mtu3: fix interval value for intr and isoc
    
    [ Upstream commit e3d4621c22f90c33321ae6a6baab60cdb8e5a77c ]
    
    Use the Interval value from isoc/intr endpoint descriptor, no need
    minus one. The original code doesn't cause transfer error for
    normal cases, but it may have side effect with respond time of ERDY
    or tPingTimeout.
    
    Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Link: https://lore.kernel.org/r/20211218095749.6250-1-chunfeng.yun@mediatek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
userfaultfd/selftests: fix hugetlb area allocations [+ + +]
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date:   Thu Dec 30 20:12:31 2021 -0800

    userfaultfd/selftests: fix hugetlb area allocations
    
    [ Upstream commit f5c73297181c6b3ad76537bad98eaad6d29b9333 ]
    
    Currently, userfaultfd selftest for hugetlb as run from run_vmtests.sh
    or any environment where there are 'just enough' hugetlb pages will
    always fail with:
    
      testing events (fork, remap, remove):
                    ERROR: UFFDIO_COPY error: -12 (errno=12, line=616)
    
    The ENOMEM error code implies there are not enough hugetlb pages.
    However, there are free hugetlb pages but they are all reserved.  There
    is a basic problem with the way the test allocates hugetlb pages which
    has existed since the test was originally written.
    
    Due to the way 'cleanup' was done between different phases of the test,
    this issue was masked until recently.  The issue was uncovered by commit
    8ba6e8640844 ("userfaultfd/selftests: reinitialize test context in each
    test").
    
    For the hugetlb test, src and dst areas are allocated as PRIVATE
    mappings of a hugetlb file.  This means that at mmap time, pages are
    reserved for the src and dst areas.  At the start of event testing (and
    other tests) the src area is populated which results in allocation of
    huge pages to fill the area and consumption of reserves associated with
    the area.  Then, a child is forked to fault in the dst area.  Note that
    the dst area was allocated in the parent and hence the parent owns the
    reserves associated with the mapping.  The child has normal access to
    the dst area, but can not use the reserves created/owned by the parent.
    Thus, if there are no other huge pages available allocation of a page
    for the dst by the child will fail.
    
    Fix by not creating reserves for the dst area.  In this way the child
    can use free (non-reserved) pages.
    
    Also, MAP_PRIVATE of a file only makes sense if you are interested in
    the contents of the file before making a COW copy.  The test does not do
    this.  So, just use MAP_ANONYMOUS | MAP_HUGETLB to create an anonymous
    hugetlb mapping.  There is no need to create a hugetlb file in the
    non-shared case.
    
    Link: https://lkml.kernel.org/r/20211217172919.7861-1-mike.kravetz@oracle.com
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Axel Rasmussen <axelrasmussen@google.com>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Mina Almasry <almasrymina@google.com>
    Cc: Shuah Khan <shuah@kernel.org>
    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>

 
xfs: map unwritten blocks in XFS_IOC_{ALLOC,FREE}SP just like fallocate [+ + +]
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Wed Dec 22 14:19:18 2021 -0800

    xfs: map unwritten blocks in XFS_IOC_{ALLOC,FREE}SP just like fallocate
    
    commit 983d8e60f50806f90534cc5373d0ce867e5aaf79 upstream.
    
    The old ALLOCSP/FREESP ioctls in XFS can be used to preallocate space at
    the end of files, just like fallocate and RESVSP.  Make the behavior
    consistent with the other ioctls.
    
    Reported-by: Kirill Tkhai <ktkhai@virtuozzo.com>
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>