Linux 5.4.171

 
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>

 
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>

 
f2fs: quota: fix potential deadlock [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Fri Sep 3 10:38:11 2021 +0800

    f2fs: quota: fix potential deadlock
    
    commit a5c0042200b28fff3bde6fa128ddeaef97990f8d upstream.
    
    As Yi Zhuang reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=214299
    
    There is potential deadlock during quota data flush as below:
    
    Thread A:                       Thread B:
    f2fs_dquot_acquire
    down_read(&sbi->quota_sem)
                                    f2fs_write_checkpoint
                                    block_operations
                                    f2fs_look_all
                                    down_write(&sbi->cp_rwsem)
    f2fs_quota_write
    f2fs_write_begin
    __do_map_lock
    f2fs_lock_op
    down_read(&sbi->cp_rwsem)
                                    __need_flush_qutoa
                                    down_write(&sbi->quota_sem)
    
    This patch changes block_operations() to use trylock, if it fails,
    it means there is potential quota data updater, in this condition,
    let's flush quota data first and then trylock again to check dirty
    status of quota data.
    
    The side effect is: in heavy race condition (e.g. multi quota data
    upaters vs quota data flusher), it may decrease the probability of
    synchronizing quota data successfully in checkpoint() due to limited
    retry time of quota flush.
    
    Reported-by: Yi Zhuang <zhuangyi1@huawei.com>
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@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 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: touchscreen - Fix backport of a02dcde595f7cbd240ccd64de96034ad91cffc40 [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Mon Jan 3 12:29:35 2022 -0700

    Input: touchscreen - Fix backport of a02dcde595f7cbd240ccd64de96034ad91cffc40
    
    Upstream commit a02dcde595f7 ("Input: touchscreen - avoid bitwise vs
    logical OR warning") was applied as commit f6e9e7be9b80 ("Input:
    touchscreen - avoid bitwise vs logical OR warning") in linux-5.4.y but
    it did not properly account for commit d9265e8a878a ("Input:
    of_touchscreen - add support for touchscreen-min-x|y"), which means the
    warning mentioned in the commit message is not fully fixed:
    
    drivers/input/touchscreen/of_touchscreen.c:78:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
            data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x",
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/input/touchscreen/of_touchscreen.c:78:17: note: cast one or both operands to int to silence this warning
    drivers/input/touchscreen/of_touchscreen.c:92:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
            data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-y",
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/input/touchscreen/of_touchscreen.c:92:17: note: cast one or both operands to int to silence this warning
    2 warnings generated.
    
    It seems like the 4.19 backport was applied to the 5.4 tree, which did
    not have any conflicts so no issue was noticed at that point.
    
    Fix up the backport to bring it more in line with the upstream version
    so that there is no warning.
    
    Fixes: f6e9e7be9b80 ("Input: touchscreen - avoid bitwise vs logical OR warning")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

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

    Linux 5.4.171
    
    Link: https://lore.kernel.org/r/20220110071815.647309738@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    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>

 
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>

 
net: phy: micrel: set soft_reset callback to genphy_soft_reset for KSZ8081 [+ + +]
Author: Christian Melki <christian.melki@t2data.com>
Date:   Wed Feb 24 21:55:36 2021 +0100

    net: phy: micrel: set soft_reset callback to genphy_soft_reset for KSZ8081
    
    commit 764d31cacfe48440745c4bbb55a62ac9471c9f19 upstream.
    
    Following a similar reinstate for the KSZ9031.
    
    Older kernels would use the genphy_soft_reset if the PHY did not implement
    a .soft_reset.
    
    Bluntly removing that default may expose a lot of situations where various
    PHYs/board implementations won't recover on various changes.
    Like with this implementation during a 4.9.x to 5.4.x LTS transition.
    I think it's a good thing to remove unwanted soft resets but wonder if it
    did open a can of worms?
    
    Atleast this fixes one iMX6 FEC/RMII/8081 combo.
    
    Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
    Signed-off-by: Christian Melki <christian.melki@t2data.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20210224205536.9349-1-christian.melki@t2data.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
    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>

 
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: 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>

 
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>

 
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>

 
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>

 
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>