Список изменений в Linux 4.4.299

 
Bluetooth: btusb: Apply QCA Rome patches for some ATH3012 models [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon May 21 22:34:52 2018 +0200

    Bluetooth: btusb: Apply QCA Rome patches for some ATH3012 models
    
    commit 803cdb8ce584198cd45825822910cac7de6378cb upstream.
    
    In commit f44cb4b19ed4 ("Bluetooth: btusb: Fix quirk for Atheros
    1525/QCA6174") we tried to address the non-working Atheros BT devices
    by changing the quirk from BTUSB_ATH3012 to BTUSB_QCA_ROME.  This made
    such devices working while it turned out to break other existing chips
    with the very same USB ID, hence it was reverted afterwards.
    
    This is another attempt to tackle the issue.  The essential point to
    use BTUSB_QCA_ROME is to apply the btusb_setup_qca() and do RAM-
    patching.  And the previous attempt failed because btusb_setup_qca()
    returns -ENODEV if the ROM version doesn't match with the expected
    ones.  For some devices that have already the "correct" ROM versions,
    we may just skip the setup procedure and continue the rest.
    
    So, the first fix we'll need is to add a check of the ROM version in
    the function to skip the setup if the ROM version looks already sane,
    so that it can be applied for all ath devices.
    
    However, the world is a bit more complex than that simple solution.
    Since BTUSB_ATH3012 quirk checks the bcdDevice and bails out when it's
    0x0001 at the beginning of probing, so the device probe always aborts
    here.
    
    In this patch, we add another check of ROM version again, and if the
    device needs patching, the probe continues.  For that, a slight
    refactoring of btusb_qca_send_vendor_req() was required so that the
    probe function can pass usb_device pointer directly before allocating
    hci_dev stuff.
    
    Fixes: commit f44cb4b19ed4 ("Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174")
    Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1082504
    Tested-by: Ivan Levshin <ivan.levshin@microfocus.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bpf, test: fix ld_abs + vlan push/pop stress test [+ + +]
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Thu Oct 20 17:13:53 2016 +0200

    bpf, test: fix ld_abs + vlan push/pop stress test
    
    commit 0d906b1e8d4002cdd59590fec630f4e75023e288 upstream.
    
    After commit 636c2628086e ("net: skbuff: Remove errornous length
    validation in skb_vlan_pop()") mentioned test case stopped working,
    throwing a -12 (ENOMEM) return code. The issue however is not due to
    636c2628086e, but rather due to a buggy test case that got uncovered
    from the change in behaviour in 636c2628086e.
    
    The data_size of that test case for the skb was set to 1. In the
    bpf_fill_ld_abs_vlan_push_pop() handler bpf insns are generated that
    loop with: reading skb data, pushing 68 tags, reading skb data,
    popping 68 tags, reading skb data, etc, in order to force a skb
    expansion and thus trigger that JITs recache skb->data. Problem is
    that initial data_size is too small.
    
    While before 636c2628086e, the test silently bailed out due to the
    skb->len < VLAN_ETH_HLEN check with returning 0, and now throwing an
    error from failing skb_ensure_writable(). Set at least minimum of
    ETH_HLEN as an initial length so that on first push of data, equivalent
    pop will succeed.
    
    Fixes: 4d9c5c53ac99 ("test_bpf: add bpf_skb_vlan_push/pop() tests")
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    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>

 
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>

 
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>

 
Linux: Linux 4.4.299 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jan 11 13:37:12 2022 +0100

    Linux 4.4.299
    
    Link: https://lore.kernel.org/r/20220110071811.779189823@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.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: Pavel Machek (CIP) <pavel@denx.de>
    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: 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>
    [nathan: Resolve conflict due to lack of 8b0e195314fab]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    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>

 
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>