óÐÉÓÏË ÉÚÍÅÎÅÎÉÊ × Linux 4.9.322

 
caif_virtio: fix race between virtio_device_ready() and ndo_open() [+ + +]
Author: Jason Wang <jasowang@redhat.com>
Date:   Mon Jun 20 13:11:14 2022 +0800

    caif_virtio: fix race between virtio_device_ready() and ndo_open()
    
    commit 11a37eb66812ce6a06b79223ad530eb0e1d7294d upstream.
    
    We currently depend on probe() calling virtio_device_ready() -
    which happens after netdev
    registration. Since ndo_open() can be called immediately
    after register_netdev, this means there exists a race between
    ndo_open() and virtio_device_ready(): the driver may start to use the
    device (e.g. TX) before DRIVER_OK which violates the spec.
    
    Fix this by switching to use register_netdevice() and protect the
    virtio_device_ready() with rtnl_lock() to make sure ndo_open() can
    only be called after virtio_device_ready().
    
    Fixes: 0d2e1a2926b18 ("caif_virtio: Introduce caif over virtio")
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Message-Id: <20220620051115.3142-3-jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm raid: fix KASAN warning in raid5_add_disks [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Jun 29 13:40:57 2022 -0400

    dm raid: fix KASAN warning in raid5_add_disks
    
    commit 617b365872a247480e9dcd50a32c8d1806b21861 upstream.
    
    There's a KASAN warning in raid5_add_disk when running the LVM testsuite.
    The warning happens in the test
    lvconvert-raid-reshape-linear_to_raid6-single-type.sh. We fix the warning
    by verifying that rdev->saved_raid_disk is within limits.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
hwmon: (ibmaem) don't call platform_device_del() if platform_device_add() fails [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Jul 1 15:41:53 2022 +0800

    hwmon: (ibmaem) don't call platform_device_del() if platform_device_add() fails
    
    [ Upstream commit d0e51022a025ca5350fafb8e413a6fe5d4baf833 ]
    
    If platform_device_add() fails, it no need to call platform_device_del(), split
    platform_device_unregister() into platform_device_del/put(), so platform_device_put()
    can be called separately.
    
    Fixes: 8808a793f052 ("ibmaem: new driver for power/energy/temp meters in IBM System X hardware")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20220701074153.4021556-1-yangyingliang@huawei.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6/sit: fix ipip6_tunnel_get_prl return value [+ + +]
Author: katrinzhou <katrinzhou@tencent.com>
Date:   Tue Jun 28 11:50:30 2022 +0800

    ipv6/sit: fix ipip6_tunnel_get_prl return value
    
    commit adabdd8f6acabc0c3fdbba2e7f5a2edd9c5ef22d upstream.
    
    When kcalloc fails, ipip6_tunnel_get_prl() should return -ENOMEM.
    Move the position of label "out" to return correctly.
    
    Addresses-Coverity: ("Unused value")
    Fixes: 300aaeeaab5f ("[IPV6] SIT: Add SIOCGETPRL ioctl to get/dump PRL.")
    Signed-off-by: katrinzhou <katrinzhou@tencent.com>
    Reviewed-by: Eric Dumazet<edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20220628035030.1039171-1-zys.zljxml@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 4.9.322 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jul 7 17:30:12 2022 +0200

    Linux 4.9.322
    
    Link: https://lore.kernel.org/r/20220705115605.742248854@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: bonding: fix possible NULL deref in rlb code [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jun 27 10:28:13 2022 +0000

    net: bonding: fix possible NULL deref in rlb code
    
    commit ab84db251c04d38b8dc7ee86e13d4050bedb1c88 upstream.
    
    syzbot has two reports involving the same root cause.
    
    bond_alb_initialize() must not set bond->alb_info.rlb_enabled
    if a memory allocation error is detected.
    
    Report 1:
    
    general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
    CPU: 0 PID: 12276 Comm: kworker/u4:10 Not tainted 5.19.0-rc3-syzkaller-00132-g3b89b511ea0c #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: netns cleanup_net
    RIP: 0010:rlb_clear_slave+0x10e/0x690 drivers/net/bonding/bond_alb.c:393
    Code: 8e fc 83 fb ff 0f 84 74 02 00 00 e8 cc 2a 8e fc 48 8b 44 24 08 89 dd 48 c1 e5 06 4c 8d 34 28 49 8d 7e 14 48 89 f8 48 c1 e8 03 <42> 0f b6 14 20 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
    RSP: 0018:ffffc90018a8f678 EFLAGS: 00010203
    RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: ffff88803375bb00 RSI: ffffffff84ec4ac4 RDI: 0000000000000014
    RBP: 0000000000000000 R08: 0000000000000005 R09: 00000000ffffffff
    R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000
    R13: ffff8880ac889000 R14: 0000000000000000 R15: ffff88815a668c80
    FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00005597077e10b0 CR3: 0000000026668000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    bond_alb_deinit_slave+0x43c/0x6b0 drivers/net/bonding/bond_alb.c:1663
    __bond_release_one.cold+0x383/0xd53 drivers/net/bonding/bond_main.c:2370
    bond_slave_netdev_event drivers/net/bonding/bond_main.c:3778 [inline]
    bond_netdev_event+0x993/0xad0 drivers/net/bonding/bond_main.c:3889
    notifier_call_chain+0xb5/0x200 kernel/notifier.c:87
    call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945
    call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]
    call_netdevice_notifiers net/core/dev.c:1997 [inline]
    unregister_netdevice_many+0x948/0x18b0 net/core/dev.c:10839
    default_device_exit_batch+0x449/0x590 net/core/dev.c:11333
    ops_exit_list+0x125/0x170 net/core/net_namespace.c:167
    cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594
    process_one_work+0x996/0x1610 kernel/workqueue.c:2289
    worker_thread+0x665/0x1080 kernel/workqueue.c:2436
    kthread+0x2e9/0x3a0 kernel/kthread.c:376
    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
    </TASK>
    
    Report 2:
    
    general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
    CPU: 1 PID: 5206 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-12108-g58f9d52ff689 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:rlb_req_update_slave_clients+0x109/0x2f0 drivers/net/bonding/bond_alb.c:502
    Code: 5d 18 8f fc 41 80 3e 00 0f 85 a5 01 00 00 89 d8 48 c1 e0 06 49 03 84 24 68 01 00 00 48 8d 78 30 49 89 c7 48 89 fa 48 c1 ea 03 <80> 3c 2a 00 0f 85 98 01 00 00 4d 39 6f 30 75 83 e8 22 18 8f fc 49
    RSP: 0018:ffffc9000300ee80 EFLAGS: 00010206
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc90016c11000
    RDX: 0000000000000006 RSI: ffffffff84eb6bf3 RDI: 0000000000000030
    RBP: dffffc0000000000 R08: 0000000000000005 R09: 00000000ffffffff
    R10: 0000000000000000 R11: 0000000000000000 R12: ffff888027c80c80
    R13: ffff88807d7ff800 R14: ffffed1004f901bd R15: 0000000000000000
    FS:  00007f6f46c58700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020010000 CR3: 00000000516cc000 CR4: 00000000003506e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     alb_fasten_mac_swap+0x886/0xa80 drivers/net/bonding/bond_alb.c:1070
     bond_alb_handle_active_change+0x624/0x1050 drivers/net/bonding/bond_alb.c:1765
     bond_change_active_slave+0xfa1/0x29b0 drivers/net/bonding/bond_main.c:1173
     bond_select_active_slave+0x23f/0xa50 drivers/net/bonding/bond_main.c:1253
     bond_enslave+0x3b34/0x53b0 drivers/net/bonding/bond_main.c:2159
     do_set_master+0x1c8/0x220 net/core/rtnetlink.c:2577
     rtnl_newlink_create net/core/rtnetlink.c:3380 [inline]
     __rtnl_newlink+0x13ac/0x17e0 net/core/rtnetlink.c:3580
     rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3593
     rtnetlink_rcv_msg+0x43a/0xc90 net/core/rtnetlink.c:6089
     netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501
     netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
     netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
     netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg+0xcf/0x120 net/socket.c:734
     ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492
     ___sys_sendmsg+0xf3/0x170 net/socket.c:2546
     __sys_sendmsg net/socket.c:2575 [inline]
     __do_sys_sendmsg net/socket.c:2584 [inline]
     __se_sys_sendmsg net/socket.c:2582 [inline]
     __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    RIP: 0033:0x7f6f45a89109
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f6f46c58168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007f6f45b9c030 RCX: 00007f6f45a89109
    RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000006
    RBP: 00007f6f45ae308d R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007ffed99029af R14: 00007f6f46c58300 R15: 0000000000022000
     </TASK>
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jay Vosburgh <j.vosburgh@gmail.com>
    Cc: Veaceslav Falico <vfalico@gmail.com>
    Cc: Andy Gospodarek <andy@greyhouse.net>
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Link: https://lore.kernel.org/r/20220627102813.126264-1-edumazet@google.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: bonding: fix use-after-free after 802.3ad slave unbind [+ + +]
Author: Yevhen Orlov <yevhen.orlov@plvision.eu>
Date:   Wed Jun 29 04:29:14 2022 +0300

    net: bonding: fix use-after-free after 802.3ad slave unbind
    
    commit 050133e1aa2cb49bb17be847d48a4431598ef562 upstream.
    
    commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"),
    resolve case, when there is several aggregation groups in the same bond.
    bond_3ad_unbind_slave will invalidate (clear) aggregator when
    __agg_active_ports return zero. So, ad_clear_agg can be executed even, when
    num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for,
    previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave
    will not update slave ports list, because lag_ports==NULL. So, here we
    got slave ports, pointing to freed aggregator memory.
    
    Fix with checking actual number of ports in group (as was before
    commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ),
    before ad_clear_agg().
    
    The KASAN logs are as follows:
    
    [  767.617392] ==================================================================
    [  767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470
    [  767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767
    [  767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G           O 5.15.11 #15
    [  767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT)
    [  767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler
    [  767.666468] Call trace:
    [  767.668930]  dump_backtrace+0x0/0x2d0
    [  767.672625]  show_stack+0x24/0x30
    [  767.675965]  dump_stack_lvl+0x68/0x84
    [  767.679659]  print_address_description.constprop.0+0x74/0x2b8
    [  767.685451]  kasan_report+0x1f0/0x260
    [  767.689148]  __asan_load2+0x94/0xd0
    [  767.692667]  bond_3ad_state_machine_handler+0x13dc/0x1470
    
    Fixes: 0622cab0341c ("bonding: fix 802.3ad aggregator reselection")
    Co-developed-by: Maksym Glubokiy <maksym.glubokiy@plvision.eu>
    Signed-off-by: Maksym Glubokiy <maksym.glubokiy@plvision.eu>
    Signed-off-by: Yevhen Orlov <yevhen.orlov@plvision.eu>
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Link: https://lore.kernel.org/r/20220629012914.361-1-yevhen.orlov@plvision.eu
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: Rename and export copy_skb_header [+ + +]
Author: Ilya Lesokhin <ilyal@mellanox.com>
Date:   Mon Apr 30 10:16:11 2018 +0300

    net: Rename and export copy_skb_header
    
    commit 08303c189581c985e60f588ad92a041e46b6e307 upstream.
    
    [ jgross@suse.com: added as needed by XSA-403 mitigation ]
    
    copy_skb_header is renamed to skb_copy_header and
    exported. Exposing this function give more flexibility
    in copying SKBs.
    skb_copy and skb_copy_expand do not give enough control
    over which parts are copied.
    
    Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
    Signed-off-by: Boris Pismenny <borisp@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: rose: fix UAF bugs caused by timer handler [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Wed Jun 29 08:26:40 2022 +0800

    net: rose: fix UAF bugs caused by timer handler
    
    commit 9cc02ede696272c5271a401e4f27c262359bc2f6 upstream.
    
    There are UAF bugs in rose_heartbeat_expiry(), rose_timer_expiry()
    and rose_idletimer_expiry(). The root cause is that del_timer()
    could not stop the timer handler that is running and the refcount
    of sock is not managed properly.
    
    One of the UAF bugs is shown below:
    
        (thread 1)          |        (thread 2)
                            |  rose_bind
                            |  rose_connect
                            |    rose_start_heartbeat
    rose_release            |    (wait a time)
      case ROSE_STATE_0     |
      rose_destroy_socket   |  rose_heartbeat_expiry
        rose_stop_heartbeat |
        sock_put(sk)        |    ...
      sock_put(sk) // FREE  |
                            |    bh_lock_sock(sk) // USE
    
    The sock is deallocated by sock_put() in rose_release() and
    then used by bh_lock_sock() in rose_heartbeat_expiry().
    
    Although rose_destroy_socket() calls rose_stop_heartbeat(),
    it could not stop the timer that is running.
    
    The KASAN report triggered by POC is shown below:
    
    BUG: KASAN: use-after-free in _raw_spin_lock+0x5a/0x110
    Write of size 4 at addr ffff88800ae59098 by task swapper/3/0
    ...
    Call Trace:
     <IRQ>
     dump_stack_lvl+0xbf/0xee
     print_address_description+0x7b/0x440
     print_report+0x101/0x230
     ? irq_work_single+0xbb/0x140
     ? _raw_spin_lock+0x5a/0x110
     kasan_report+0xed/0x120
     ? _raw_spin_lock+0x5a/0x110
     kasan_check_range+0x2bd/0x2e0
     _raw_spin_lock+0x5a/0x110
     rose_heartbeat_expiry+0x39/0x370
     ? rose_start_heartbeat+0xb0/0xb0
     call_timer_fn+0x2d/0x1c0
     ? rose_start_heartbeat+0xb0/0xb0
     expire_timers+0x1f3/0x320
     __run_timers+0x3ff/0x4d0
     run_timer_softirq+0x41/0x80
     __do_softirq+0x233/0x544
     irq_exit_rcu+0x41/0xa0
     sysvec_apic_timer_interrupt+0x8c/0xb0
     </IRQ>
     <TASK>
     asm_sysvec_apic_timer_interrupt+0x1b/0x20
    RIP: 0010:default_idle+0xb/0x10
    RSP: 0018:ffffc9000012fea0 EFLAGS: 00000202
    RAX: 000000000000bcae RBX: ffff888006660f00 RCX: 000000000000bcae
    RDX: 0000000000000001 RSI: ffffffff843a11c0 RDI: ffffffff843a1180
    RBP: dffffc0000000000 R08: dffffc0000000000 R09: ffffed100da36d46
    R10: dfffe9100da36d47 R11: ffffffff83cf0950 R12: 0000000000000000
    R13: 1ffff11000ccc1e0 R14: ffffffff8542af28 R15: dffffc0000000000
    ...
    Allocated by task 146:
     __kasan_kmalloc+0xc4/0xf0
     sk_prot_alloc+0xdd/0x1a0
     sk_alloc+0x2d/0x4e0
     rose_create+0x7b/0x330
     __sock_create+0x2dd/0x640
     __sys_socket+0xc7/0x270
     __x64_sys_socket+0x71/0x80
     do_syscall_64+0x43/0x90
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Freed by task 152:
     kasan_set_track+0x4c/0x70
     kasan_set_free_info+0x1f/0x40
     ____kasan_slab_free+0x124/0x190
     kfree+0xd3/0x270
     __sk_destruct+0x314/0x460
     rose_release+0x2fa/0x3b0
     sock_close+0xcb/0x230
     __fput+0x2d9/0x650
     task_work_run+0xd6/0x160
     exit_to_user_mode_loop+0xc7/0xd0
     exit_to_user_mode_prepare+0x4e/0x80
     syscall_exit_to_user_mode+0x20/0x40
     do_syscall_64+0x4f/0x90
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    This patch adds refcount of sock when we use functions
    such as rose_start_heartbeat() and so on to start timer,
    and decreases the refcount of sock when timer is finished
    or deleted by functions such as rose_stop_heartbeat()
    and so on. As a result, the UAF bugs could be mitigated.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Tested-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220629002640.5693-1-duoming@zju.edu.cn
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: ax88179_178a: Fix packet receiving [+ + +]
Author: Jose Alonso <joalonsof@gmail.com>
Date:   Tue Jun 28 12:13:02 2022 -0300

    net: usb: ax88179_178a: Fix packet receiving
    
    commit f8ebb3ac881b17712e1d5967c97ab1806b16d3d6 upstream.
    
    This patch corrects packet receiving in ax88179_rx_fixup.
    
    - problem observed:
      ifconfig shows allways a lot of 'RX Errors' while packets
      are received normally.
    
      This occurs because ax88179_rx_fixup does not recognise properly
      the usb urb received.
      The packets are normally processed and at the end, the code exits
      with 'return 0', generating RX Errors.
      (pkt_cnt==-2 and ptk_hdr over field rx_hdr trying to identify
       another packet there)
    
      This is a usb urb received by "tcpdump -i usbmon2 -X" on a
      little-endian CPU:
      0x0000:  eeee f8e3 3b19 87a0 94de 80e3 daac 0800
               ^         packet 1 start (pkt_len = 0x05ec)
               ^^^^      IP alignment pseudo header
                    ^    ethernet packet start
               last byte ethernet packet   v
               padding (8-bytes aligned)     vvvv vvvv
      0x05e0:  c92d d444 1420 8a69 83dd 272f e82b 9811
      0x05f0:  eeee f8e3 3b19 87a0 94de 80e3 daac 0800
      ...      ^ packet 2
      0x0be0:  eeee f8e3 3b19 87a0 94de 80e3 daac 0800
      ...
      0x1130:  9d41 9171 8a38 0ec5 eeee f8e3 3b19 87a0
      ...
      0x1720:  8cfc 15ff 5e4c e85c eeee f8e3 3b19 87a0
      ...
      0x1d10:  ecfa 2a3a 19ab c78c eeee f8e3 3b19 87a0
      ...
      0x2070:  eeee f8e3 3b19 87a0 94de 80e3 daac 0800
      ...      ^ packet 7
      0x2120:  7c88 4ca5 5c57 7dcc 0d34 7577 f778 7e0a
      0x2130:  f032 e093 7489 0740 3008 ec05 0000 0080
                                   ====1==== ====2====
               hdr_off             ^
               pkt_len = 0x05ec         ^^^^
               AX_RXHDR_*=0x00830  ^^^^   ^
               pkt_len = 0                        ^^^^
               AX_RXHDR_DROP_ERR=0x80000000  ^^^^   ^
      0x2140:  3008 ec05 0000 0080 3008 5805 0000 0080
      0x2150:  3008 ec05 0000 0080 3008 ec05 0000 0080
      0x2160:  3008 5803 0000 0080 3008 c800 0000 0080
               ===11==== ===12==== ===13==== ===14====
      0x2170:  0000 0000 0e00 3821
                         ^^^^ ^^^^ rx_hdr
                         ^^^^      pkt_cnt=14
                              ^^^^ hdr_off=0x2138
               ^^^^ ^^^^           padding
    
      The dump shows that pkt_cnt is the number of entrys in the
      per-packet metadata. It is "2 * packet count".
      Each packet have two entrys. The first have a valid
      value (pkt_len and AX_RXHDR_*) and the second have a
      dummy-header 0x80000000 (pkt_len=0 with AX_RXHDR_DROP_ERR).
      Why exists dummy-header for each packet?!?
      My guess is that this was done probably to align the
      entry for each packet to 64-bits and maintain compatibility
      with old firmware.
      There is also a padding (0x00000000) before the rx_hdr to
      align the end of rx_hdr to 64-bit.
      Note that packets have a alignment of 64-bits (8-bytes).
    
      This patch assumes that the dummy-header and the last
      padding are optional. So it preserves semantics and
      recognises the same valid packets as the current code.
    
      This patch was made using only the dumpfile information and
      tested with only one device:
      0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
    
    Fixes: 57bc3d3ae8c1 ("net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup")
    Fixes: e2ca90c276e1 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver")
    Signed-off-by: Jose Alonso <joalonsof@gmail.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/d6970bb04bf67598af4d316eaeb1792040b18cfd.camel@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: qmi_wwan: add Telit 0x1060 composition [+ + +]
Author: Carlo Lobrano <c.lobrano@gmail.com>
Date:   Fri Sep 3 14:09:53 2021 +0200

    net: usb: qmi_wwan: add Telit 0x1060 composition
    
    commit 8d17a33b076d24aa4861f336a125c888fb918605 upstream.
    
    This patch adds support for Telit LN920 0x1060 composition
    
    0x1060: tty, adb, rmnet, tty, tty, tty, tty
    
    Signed-off-by: Carlo Lobrano <c.lobrano@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: qmi_wwan: add Telit 0x1070 composition [+ + +]
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Fri Dec 10 10:57:22 2021 +0100

    net: usb: qmi_wwan: add Telit 0x1070 composition
    
    commit 94f2a444f28a649926c410eb9a38afb13a83ebe0 upstream.
    
    Add the following Telit FN990 composition:
    
    0x1070: tty, adb, rmnet, tty, tty, tty, tty
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Link: https://lore.kernel.org/r/20211210095722.22269-1-dnlplm@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: qmi_wwan: add Telit 0x1260 and 0x1261 compositions [+ + +]
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Wed May 15 17:29:43 2019 +0200

    net: usb: qmi_wwan: add Telit 0x1260 and 0x1261 compositions
    
    commit b4e467c82f8c12af78b6f6fa5730cb7dea7af1b4 upstream.
    
    Added support for Telit LE910Cx 0x1260 and 0x1261 compositions.
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: qmi_wwan: add Telit LE910Cx 0x1230 composition [+ + +]
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Mon Nov 2 12:01:08 2020 +0100

    net: usb: qmi_wwan: add Telit LE910Cx 0x1230 composition
    
    commit 5fd8477ed8ca77e64b93d44a6dae4aa70c191396 upstream.
    
    Add support for Telit LE910Cx 0x1230 composition:
    
    0x1230: tty, adb, rmnet, audio, tty, tty, tty, tty
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Link: https://lore.kernel.org/r/20201102110108.17244-1-dnlplm@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
netfilter: nft_dynset: restore set element counter when failing to update [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Jun 21 14:01:41 2022 +0200

    netfilter: nft_dynset: restore set element counter when failing to update
    
    commit 05907f10e235680cc7fb196810e4ad3215d5e648 upstream.
    
    This patch fixes a race condition.
    
    nft_rhash_update() might fail for two reasons:
    
    - Element already exists in the hashtable.
    - Another packet won race to insert an entry in the hashtable.
    
    In both cases, new() has already bumped the counter via atomic_add_unless(),
    therefore, decrement the set element counter.
    
    Fixes: 22fe54d5fefc ("netfilter: nf_tables: add support for dynamic set updates")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfc: nfcmrvl: Fix irq_of_parse_and_map() return value [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Mon Jun 27 14:40:48 2022 +0200

    nfc: nfcmrvl: Fix irq_of_parse_and_map() return value
    
    commit 5a478a653b4cca148d5c89832f007ec0809d7e6d upstream.
    
    The irq_of_parse_and_map() returns 0 on failure, not a negative ERRNO.
    
    Reported-by: Lv Ruyi <lv.ruyi@zte.com.cn>
    Fixes: caf6e49bf6d0 ("NFC: nfcmrvl: add spi driver")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220627124048.296253-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
NFC: nxp-nci: Don't issue a zero length i2c_master_read() [+ + +]
Author: Michael Walle <michael@walle.cc>
Date:   Mon Jun 27 19:06:42 2022 +0200

    NFC: nxp-nci: Don't issue a zero length i2c_master_read()
    
    commit eddd95b9423946aaacb55cac6a9b2cea8ab944fc upstream.
    
    There are packets which doesn't have a payload. In that case, the second
    i2c_master_read() will have a zero length. But because the NFC
    controller doesn't have any data left, it will NACK the I2C read and
    -ENXIO will be returned. In case there is no payload, just skip the
    second i2c master read.
    
    Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/powernv: wire up rng during setup_arch [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Jun 21 16:08:49 2022 +0200

    powerpc/powernv: wire up rng during setup_arch
    
    commit f3eac426657d985b97c92fa5f7ae1d43f04721f3 upstream.
    
    The platform's RNG must be available before random_init() in order to be
    useful for initial seeding, which in turn means that it needs to be
    called from setup_arch(), rather than from an init call.
    
    Complicating things, however, is that POWER8 systems need some per-cpu
    state and kmalloc, which isn't available at this stage. So we split
    things up into an early phase and a later opportunistic phase. This
    commit also removes some noisy log messages that don't add much.
    
    Fixes: a4da0d50b2a0 ("powerpc: Implement arch_get_random_long/int() for powernv")
    Cc: stable@vger.kernel.org # v3.13+
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    [mpe: Add of_node_put(), use pnv naming, minor change log editing]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220621140849.127227-1-Jason@zx2c4.com
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
qmi_wwan: Added support for Telit LN940 series [+ + +]
Author: Jörgen Storvist <jorgen.storvist@gmail.com>
Date:   Thu Dec 13 17:00:35 2018 +0100

    qmi_wwan: Added support for Telit LN940 series
    
    commit 1986af16e8ed355822600c24b3d2f0be46b573df upstream.
    
    Added support for the Telit LN940 series cellular modules QMI interface.
    QMI_QUIRK_SET_DTR quirk requied for Qualcomm MDM9x40 chipset.
    
    Signed-off-by: Jörgen Storvist <jorgen.storvist@gmail.com>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sit: use min [+ + +]
Author: kernel test robot <lkp@intel.com>
Date:   Sat Mar 27 10:29:32 2021 +0100

    sit: use min
    
    commit 284fda1eff8a8b27d2cafd7dc8fb423d13720f21 upstream.
    
    Opportunity for min()
    
    Generated by: scripts/coccinelle/misc/minmax.cocci
    
    CC: Denis Efremov <efremov@linux.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: kernel test robot <lkp@intel.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
SUNRPC: Fix READ_PLUS crasher [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Thu Jun 30 16:48:18 2022 -0400

    SUNRPC: Fix READ_PLUS crasher
    
    commit a23dd544debcda4ee4a549ec7de59e85c3c8345c upstream.
    
    Looks like there are still cases when "space_left - frag1bytes" can
    legitimately exceed PAGE_SIZE. Ensure that xdr->end always remains
    within the current encode buffer.
    
    Reported-by: Bruce Fields <bfields@fieldses.org>
    Reported-by: Zorro Lang <zlang@redhat.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216151
    Fixes: 6c254bf3b637 ("SUNRPC: Fix the calculation of xdr->end in xdr_get_next_encode_buffer()")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usbnet: fix memory allocation in helpers [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Jun 28 11:35:17 2022 +0200

    usbnet: fix memory allocation in helpers
    
    commit e65af5403e462ccd7dff6a045a886c64da598c2e upstream.
    
    usbnet provides some helper functions that are also used in
    the context of reset() operations. During a reset the other
    drivers on a device are unable to operate. As that can be block
    drivers, a driver for another interface cannot use paging
    in its memory allocations without risking a deadlock.
    Use GFP_NOIO in the helpers.
    
    Fixes: 877bd862f32b8 ("usbnet: introduce usbnet 3 command helpers")
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20220628093517.7469-1-oneukum@suse.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usbnet: make sure no NULL pointer is passed through [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Apr 5 14:14:39 2017 +0200

    usbnet: make sure no NULL pointer is passed through
    
    commit 6c22fce07c97f765af1808ec3be007847e0b47d1 upstream.
    
    Coverity reports:
    
            ** CID 751368:  Null pointer dereferences  (FORWARD_NULL)
            /drivers/net/usb/usbnet.c: 1925 in __usbnet_read_cmd()
    
            ________________________________________________________________________________________________________
            *** CID 751368:  Null pointer dereferences  (FORWARD_NULL)
            /drivers/net/usb/usbnet.c: 1925 in __usbnet_read_cmd()
            1919     EXPORT_SYMBOL(usbnet_link_change);
            1920
            1921     /*-------------------------------------------------------------------------*/
            1922     static int __usbnet_read_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
            1923                                 u16 value, u16 index, void *data, u16 size)
            1924     {
            >>>     CID 751368:  Null pointer dereferences  (FORWARD_NULL)
            >>>     Assigning: "buf" = "NULL".
            1925            void *buf = NULL;
            1926            int err = -ENOMEM;
            1927
            1928            netdev_dbg(dev->net, "usbnet_read_cmd cmd=0x%02x reqtype=%02x"
            1929                       " value=0x%04x index=0x%04x size=%d\n",
            1930                       cmd, reqtype, value, index, size);
    
            ** CID 751370:  Null pointer dereferences  (FORWARD_NULL)
            /drivers/net/usb/usbnet.c: 1952 in __usbnet_write_cmd()
    
            ________________________________________________________________________________________________________
            *** CID 751370:  Null pointer dereferences  (FORWARD_NULL)
            /drivers/net/usb/usbnet.c: 1952 in __usbnet_write_cmd()
            1946     }
            1947
            1948     static int __usbnet_write_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
            1949                                  u16 value, u16 index, const void *data,
            1950                                  u16 size)
            1951     {
            >>>     CID 751370:  Null pointer dereferences  (FORWARD_NULL)
            >>>     Assigning: "buf" = "NULL".
            1952            void *buf = NULL;
            1953            int err = -ENOMEM;
            1954
            1955            netdev_dbg(dev->net, "usbnet_write_cmd cmd=0x%02x reqtype=%02x"
            1956                       " value=0x%04x index=0x%04x size=%d\n",
            1957                       cmd, reqtype, value, index, size);
    
            ** CID 1325026:  Null pointer dereferences  (FORWARD_NULL)
            /drivers/net/usb/ch9200.c: 143 in control_write()
    
    It is valid to offer commands without a buffer, but then you need a size
    of zero. This should actually be checked.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xen/arm: Fix race in RB-tree based P2M accounting [+ + +]
Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Date:   Fri Jul 1 09:57:42 2022 +0200

    xen/arm: Fix race in RB-tree based P2M accounting
    
    commit b75cd218274e01d026dc5240e86fdeb44bbed0c8 upstream.
    
    During the PV driver life cycle the mappings are added to
    the RB-tree by set_foreign_p2m_mapping(), which is called from
    gnttab_map_refs() and are removed by clear_foreign_p2m_mapping()
    which is called from gnttab_unmap_refs(). As both functions end
    up calling __set_phys_to_machine_multi() which updates the RB-tree,
    this function can be called concurrently.
    
    There is already a "p2m_lock" to protect against concurrent accesses,
    but the problem is that the first read of "phys_to_mach.rb_node"
    in __set_phys_to_machine_multi() is not covered by it, so this might
    lead to the incorrect mappings update (removing in our case) in RB-tree.
    
    In my environment the related issue happens rarely and only when
    PV net backend is running, the xen_add_phys_to_mach_entry() claims
    that it cannot add new pfn <-> mfn mapping to the tree since it is
    already exists which results in a failure when mapping foreign pages.
    
    But there might be other bad consequences related to the non-protected
    root reads such use-after-free, etc.
    
    While at it, also fix the similar usage in __pfn_to_mfn(), so
    initialize "struct rb_node *n" with the "p2m_lock" held in both
    functions to avoid possible bad consequences.
    
    This is CVE-2022-33744 / XSA-406.
    
    Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xen/blkfront: fix leaking data in shared pages [+ + +]
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Wed Mar 30 09:03:48 2022 +0200

    xen/blkfront: fix leaking data in shared pages
    
    commit 2f446ffe9d737e9a844b97887919c4fda18246e7 upstream.
    
    When allocating pages to be used for shared communication with the
    backend always zero them, this avoids leaking unintended data present
    on the pages.
    
    This is CVE-2022-26365, part of XSA-403.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xen/blkfront: force data bouncing when backend is untrusted [+ + +]
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Apr 7 13:04:24 2022 +0200

    xen/blkfront: force data bouncing when backend is untrusted
    
    commit 2400617da7eebf9167d71a46122828bc479d64c9 upstream.
    
    Split the current bounce buffering logic used with persistent grants
    into it's own option, and allow enabling it independently of
    persistent grants.  This allows to reuse the same code paths to
    perform the bounce buffering required to avoid leaking contiguous data
    in shared pages not part of the request fragments.
    
    Reporting whether the backend is to be trusted can be done using a
    module parameter, or from the xenstore frontend path as set by the
    toolstack when adding the device.
    
    This is CVE-2022-33742, part of XSA-403.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xen/gntdev: Avoid blocking in unmap_grant_pages() [+ + +]
Author: Demi Marie Obenour <demi@invisiblethingslab.com>
Date:   Tue Jun 21 22:27:26 2022 -0400

    xen/gntdev: Avoid blocking in unmap_grant_pages()
    
    commit dbe97cff7dd9f0f75c524afdd55ad46be3d15295 upstream.
    
    unmap_grant_pages() currently waits for the pages to no longer be used.
    In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a
    deadlock against i915: i915 was waiting for gntdev's MMU notifier to
    finish, while gntdev was waiting for i915 to free its pages.  I also
    believe this is responsible for various deadlocks I have experienced in
    the past.
    
    Avoid these problems by making unmap_grant_pages async.  This requires
    making it return void, as any errors will not be available when the
    function returns.  Fortunately, the only use of the return value is a
    WARN_ON(), which can be replaced by a WARN_ON when the error is
    detected.  Additionally, a failed call will not prevent further calls
    from being made, but this is harmless.
    
    Because unmap_grant_pages is now async, the grant handle will be sent to
    INVALID_GRANT_HANDLE too late to prevent multiple unmaps of the same
    handle.  Instead, a separate bool array is allocated for this purpose.
    This wastes memory, but stuffing this information in padding bytes is
    too fragile.  Furthermore, it is necessary to grab a reference to the
    map before making the asynchronous call, and release the reference when
    the call returns.
    
    It is also necessary to guard against reentrancy in gntdev_map_put(),
    and to handle the case where userspace tries to map a mapping whose
    contents have not all been freed yet.
    
    Fixes: 745282256c75 ("xen/gntdev: safely unmap grants in case they are still in use")
    Cc: stable@vger.kernel.org
    Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/20220622022726.2538-1-demi@invisiblethingslab.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xen/netfront: fix leaking data in shared pages [+ + +]
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Wed Apr 6 17:38:04 2022 +0200

    xen/netfront: fix leaking data in shared pages
    
    commit 307c8de2b02344805ebead3440d8feed28f2f010 upstream.
    
    When allocating pages to be used for shared communication with the
    backend always zero them, this avoids leaking unintended data present
    on the pages.
    
    This is CVE-2022-33740, part of XSA-403.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xen/netfront: force data bouncing when backend is untrusted [+ + +]
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Apr 7 12:20:06 2022 +0200

    xen/netfront: force data bouncing when backend is untrusted
    
    commit 4491001c2e0fa69efbb748c96ec96b100a5cdb7e upstream.
    
    Bounce all data on the skbs to be transmitted into zeroed pages if the
    backend is untrusted. This avoids leaking data present in the pages
    shared with the backend but not part of the skb fragments.  This
    requires introducing a new helper in order to allocate skbs with a
    size multiple of XEN_PAGE_SIZE so we don't leak contiguous data on the
    granted pages.
    
    Reporting whether the backend is to be trusted can be done using a
    module parameter, or from the xenstore frontend path as set by the
    toolstack when adding the device.
    
    This is CVE-2022-33741, part of XSA-403.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>