commit c4215ee4771bb935727df2db097fd28f8d644b5c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Dec 14 11:26:16 2022 +0100

    Linux 4.14.302
    
    Link: https://lore.kernel.org/r/20221212130912.069170932@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be1f943bc1c48c485ce553570972fb44458753ee
Author: Dan Carpenter <error27@gmail.com>
Date:   Wed Dec 7 10:06:31 2022 +0300

    net: mvneta: Fix an out of bounds check
    
    [ Upstream commit cdd97383e19d4afe29adc3376025a15ae3bab3a3 ]
    
    In an earlier commit, I added a bounds check to prevent an out of bounds
    read and a WARN().  On further discussion and consideration that check
    was probably too aggressive.  Instead of returning -EINVAL, a better fix
    would be to just prevent the out of bounds read but continue the process.
    
    Background: The value of "pp->rxq_def" is a number between 0-7 by default,
    or even higher depending on the value of "rxq_number", which is a module
    parameter. If the value is more than the number of available CPUs then
    it will trigger the WARN() in cpu_max_bits_warn().
    
    Fixes: e8b4fc13900b ("net: mvneta: Prevent out of bounds read in mvneta_config_rss()")
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Link: https://lore.kernel.org/r/Y5A7d1E5ccwHTYPf@kadam
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3d7ff8c04a83279fb7641fc4d5aa82a602df7c0
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Dec 6 10:13:51 2022 +0000

    ipv6: avoid use-after-free in ip6_fragment()
    
    [ Upstream commit 803e84867de59a1e5d126666d25eb4860cfd2ebe ]
    
    Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.
    
    It seems to not be always true, at least for UDP stack.
    
    syzbot reported:
    
    BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]
    BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
    Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618
    
    CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:284 [inline]
     print_report+0x15e/0x45d mm/kasan/report.c:395
     kasan_report+0xbf/0x1f0 mm/kasan/report.c:495
     ip6_dst_idev include/net/ip6_fib.h:245 [inline]
     ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
     __ip6_finish_output net/ipv6/ip6_output.c:193 [inline]
     ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206
     NF_HOOK_COND include/linux/netfilter.h:291 [inline]
     ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227
     dst_output include/net/dst.h:445 [inline]
     ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161
     ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966
     udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286
     udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313
     udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606
     inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg+0xd3/0x120 net/socket.c:734
     sock_write_iter+0x295/0x3d0 net/socket.c:1108
     call_write_iter include/linux/fs.h:2191 [inline]
     new_sync_write fs/read_write.c:491 [inline]
     vfs_write+0x9ed/0xdd0 fs/read_write.c:584
     ksys_write+0x1ec/0x250 fs/read_write.c:637
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7fde3588c0d9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 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:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9
    RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a
    RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000
     </TASK>
    
    Allocated by task 7618:
     kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
     kasan_set_track+0x25/0x30 mm/kasan/common.c:52
     __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325
     kasan_slab_alloc include/linux/kasan.h:201 [inline]
     slab_post_alloc_hook mm/slab.h:737 [inline]
     slab_alloc_node mm/slub.c:3398 [inline]
     slab_alloc mm/slub.c:3406 [inline]
     __kmem_cache_alloc_lru mm/slub.c:3413 [inline]
     kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422
     dst_alloc+0x14a/0x1f0 net/core/dst.c:92
     ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344
     ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]
     rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]
     ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254
     pol_lookup_func include/net/ip6_fib.h:582 [inline]
     fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121
     ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625
     ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638
     ip6_route_output include/net/ip6_route.h:98 [inline]
     ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092
     ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222
     ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260
     udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554
     inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg+0xd3/0x120 net/socket.c:734
     __sys_sendto+0x23a/0x340 net/socket.c:2117
     __do_sys_sendto net/socket.c:2129 [inline]
     __se_sys_sendto net/socket.c:2125 [inline]
     __x64_sys_sendto+0xe1/0x1b0 net/socket.c:2125
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Freed by task 7599:
     kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
     kasan_set_track+0x25/0x30 mm/kasan/common.c:52
     kasan_save_free_info+0x2e/0x40 mm/kasan/generic.c:511
     ____kasan_slab_free mm/kasan/common.c:236 [inline]
     ____kasan_slab_free+0x160/0x1c0 mm/kasan/common.c:200
     kasan_slab_free include/linux/kasan.h:177 [inline]
     slab_free_hook mm/slub.c:1724 [inline]
     slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1750
     slab_free mm/slub.c:3661 [inline]
     kmem_cache_free+0xee/0x5c0 mm/slub.c:3683
     dst_destroy+0x2ea/0x400 net/core/dst.c:127
     rcu_do_batch kernel/rcu/tree.c:2250 [inline]
     rcu_core+0x81f/0x1980 kernel/rcu/tree.c:2510
     __do_softirq+0x1fb/0xadc kernel/softirq.c:571
    
    Last potentially related work creation:
     kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
     __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:481
     call_rcu+0x9d/0x820 kernel/rcu/tree.c:2798
     dst_release net/core/dst.c:177 [inline]
     dst_release+0x7d/0xe0 net/core/dst.c:167
     refdst_drop include/net/dst.h:256 [inline]
     skb_dst_drop include/net/dst.h:268 [inline]
     skb_release_head_state+0x250/0x2a0 net/core/skbuff.c:838
     skb_release_all net/core/skbuff.c:852 [inline]
     __kfree_skb net/core/skbuff.c:868 [inline]
     kfree_skb_reason+0x151/0x4b0 net/core/skbuff.c:891
     kfree_skb_list_reason+0x4b/0x70 net/core/skbuff.c:901
     kfree_skb_list include/linux/skbuff.h:1227 [inline]
     ip6_fragment+0x2026/0x2770 net/ipv6/ip6_output.c:949
     __ip6_finish_output net/ipv6/ip6_output.c:193 [inline]
     ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206
     NF_HOOK_COND include/linux/netfilter.h:291 [inline]
     ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227
     dst_output include/net/dst.h:445 [inline]
     ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161
     ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966
     udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286
     udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313
     udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606
     inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg+0xd3/0x120 net/socket.c:734
     sock_write_iter+0x295/0x3d0 net/socket.c:1108
     call_write_iter include/linux/fs.h:2191 [inline]
     new_sync_write fs/read_write.c:491 [inline]
     vfs_write+0x9ed/0xdd0 fs/read_write.c:584
     ksys_write+0x1ec/0x250 fs/read_write.c:637
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Second to last potentially related work creation:
     kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
     __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:481
     call_rcu+0x9d/0x820 kernel/rcu/tree.c:2798
     dst_release net/core/dst.c:177 [inline]
     dst_release+0x7d/0xe0 net/core/dst.c:167
     refdst_drop include/net/dst.h:256 [inline]
     skb_dst_drop include/net/dst.h:268 [inline]
     __dev_queue_xmit+0x1b9d/0x3ba0 net/core/dev.c:4211
     dev_queue_xmit include/linux/netdevice.h:3008 [inline]
     neigh_resolve_output net/core/neighbour.c:1552 [inline]
     neigh_resolve_output+0x51b/0x840 net/core/neighbour.c:1532
     neigh_output include/net/neighbour.h:546 [inline]
     ip6_finish_output2+0x56c/0x1530 net/ipv6/ip6_output.c:134
     __ip6_finish_output net/ipv6/ip6_output.c:195 [inline]
     ip6_finish_output+0x694/0x1170 net/ipv6/ip6_output.c:206
     NF_HOOK_COND include/linux/netfilter.h:291 [inline]
     ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227
     dst_output include/net/dst.h:445 [inline]
     NF_HOOK include/linux/netfilter.h:302 [inline]
     NF_HOOK include/linux/netfilter.h:296 [inline]
     mld_sendpack+0xa09/0xe70 net/ipv6/mcast.c:1820
     mld_send_cr net/ipv6/mcast.c:2121 [inline]
     mld_ifc_work+0x720/0xdc0 net/ipv6/mcast.c:2653
     process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
     worker_thread+0x669/0x1090 kernel/workqueue.c:2436
     kthread+0x2e8/0x3a0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
    
    The buggy address belongs to the object at ffff88801d403dc0
     which belongs to the cache ip6_dst_cache of size 240
    The buggy address is located 192 bytes inside of
     240-byte region [ffff88801d403dc0, ffff88801d403eb0)
    
    The buggy address belongs to the physical page:
    page:ffffea00007500c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1d403
    memcg:ffff888022f49c81
    flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff)
    raw: 00fff00000000200 ffffea0001ef6580 dead000000000002 ffff88814addf640
    raw: 0000000000000000 00000000800c000c 00000001ffffffff ffff888022f49c81
    page dumped because: kasan: bad access detected
    page_owner tracks the page as allocated
    page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_HARDWALL), pid 3719, tgid 3719 (kworker/0:6), ts 136223432244, free_ts 136222971441
     prep_new_page mm/page_alloc.c:2539 [inline]
     get_page_from_freelist+0x10b5/0x2d50 mm/page_alloc.c:4288
     __alloc_pages+0x1cb/0x5b0 mm/page_alloc.c:5555
     alloc_pages+0x1aa/0x270 mm/mempolicy.c:2285
     alloc_slab_page mm/slub.c:1794 [inline]
     allocate_slab+0x213/0x300 mm/slub.c:1939
     new_slab mm/slub.c:1992 [inline]
     ___slab_alloc+0xa91/0x1400 mm/slub.c:3180
     __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3279
     slab_alloc_node mm/slub.c:3364 [inline]
     slab_alloc mm/slub.c:3406 [inline]
     __kmem_cache_alloc_lru mm/slub.c:3413 [inline]
     kmem_cache_alloc+0x31a/0x3d0 mm/slub.c:3422
     dst_alloc+0x14a/0x1f0 net/core/dst.c:92
     ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344
     icmp6_dst_alloc+0x71/0x680 net/ipv6/route.c:3261
     mld_sendpack+0x5de/0xe70 net/ipv6/mcast.c:1809
     mld_send_cr net/ipv6/mcast.c:2121 [inline]
     mld_ifc_work+0x720/0xdc0 net/ipv6/mcast.c:2653
     process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
     worker_thread+0x669/0x1090 kernel/workqueue.c:2436
     kthread+0x2e8/0x3a0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
    page last free stack trace:
     reset_page_owner include/linux/page_owner.h:24 [inline]
     free_pages_prepare mm/page_alloc.c:1459 [inline]
     free_pcp_prepare+0x65c/0xd90 mm/page_alloc.c:1509
     free_unref_page_prepare mm/page_alloc.c:3387 [inline]
     free_unref_page+0x1d/0x4d0 mm/page_alloc.c:3483
     __unfreeze_partials+0x17c/0x1a0 mm/slub.c:2586
     qlink_free mm/kasan/quarantine.c:168 [inline]
     qlist_free_all+0x6a/0x170 mm/kasan/quarantine.c:187
     kasan_quarantine_reduce+0x184/0x210 mm/kasan/quarantine.c:294
     __kasan_slab_alloc+0x66/0x90 mm/kasan/common.c:302
     kasan_slab_alloc include/linux/kasan.h:201 [inline]
     slab_post_alloc_hook mm/slab.h:737 [inline]
     slab_alloc_node mm/slub.c:3398 [inline]
     kmem_cache_alloc_node+0x304/0x410 mm/slub.c:3443
     __alloc_skb+0x214/0x300 net/core/skbuff.c:497
     alloc_skb include/linux/skbuff.h:1267 [inline]
     netlink_alloc_large_skb net/netlink/af_netlink.c:1191 [inline]
     netlink_sendmsg+0x9a6/0xe10 net/netlink/af_netlink.c:1896
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg+0xd3/0x120 net/socket.c:734
     __sys_sendto+0x23a/0x340 net/socket.c:2117
     __do_sys_sendto net/socket.c:2129 [inline]
     __se_sys_sendto net/socket.c:2125 [inline]
     __x64_sys_sendto+0xe1/0x1b0 net/socket.c:2125
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: 1758fd4688eb ("ipv6: remove unnecessary dst_hold() in ip6_fragment()")
    Reported-by: syzbot+8c0ac31aa9681abb9e2d@syzkaller.appspotmail.com
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Wei Wang <weiwan@google.com>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Link: https://lore.kernel.org/r/20221206101351.2037285-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1abdb3e14ff9eafc776672ae615c67bb7f8d3c32
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Dec 7 09:53:10 2022 +0800

    net: plip: don't call kfree_skb/dev_kfree_skb() under spin_lock_irq()
    
    [ Upstream commit 7d8c19bfc8ff3f78e5337107ca9246327fcb6b45 ]
    
    It is not allowed to call kfree_skb() or consume_skb() from
    hardware interrupt context or with interrupts being disabled.
    So replace kfree_skb/dev_kfree_skb() with dev_kfree_skb_irq()
    and dev_consume_skb_irq() under spin_lock_irq().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Link: https://lore.kernel.org/r/20221207015310.2984909-1-yangyingliang@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 572f47fef932b41bc47eb2e7cf39c7eeeedafa4a
Author: Juergen Gross <jgross@suse.com>
Date:   Wed Dec 7 08:19:38 2022 +0100

    xen/netback: fix build warning
    
    [ Upstream commit 7dfa764e0223a324366a2a1fc056d4d9d4e95491 ]
    
    Commit ad7f402ae4f4 ("xen/netback: Ensure protocol headers don't fall in
    the non-linear area") introduced a (valid) build warning. There have
    even been reports of this problem breaking networking of Xen guests.
    
    Fixes: ad7f402ae4f4 ("xen/netback: Ensure protocol headers don't fall in the non-linear area")
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Tested-by: Jason Andryuk <jandryuk@gmail.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb1e293f858e5e1152b8791047ed4bdaaf392189
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Sun Dec 4 14:09:08 2022 +0800

    ethernet: aeroflex: fix potential skb leak in greth_init_rings()
    
    [ Upstream commit 063a932b64db3317ec020c94466fe52923a15f60 ]
    
    The greth_init_rings() function won't free the newly allocated skb when
    dma_mapping_error() returns error, so add dev_kfree_skb() to fix it.
    
    Compile tested only.
    
    Fixes: d4c41139df6e ("net: Add Aeroflex Gaisler 10/100/1G Ethernet MAC driver")
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Link: https://lore.kernel.org/r/1670134149-29516-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit abf037ca3025b30dc20d97a40d922a4e0a7cafe3
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Sat Dec 3 17:46:35 2022 +0800

    tipc: Fix potential OOB in tipc_link_proto_rcv()
    
    [ Upstream commit 743117a997bbd4840e827295c07e59bcd7f7caa3 ]
    
    Fix the potential risk of OOB if skb_linearize() fails in
    tipc_link_proto_rcv().
    
    Fixes: 5cbb28a4bf65 ("tipc: linearize arriving NAME_DISTR and LINK_PROTO buffers")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Link: https://lore.kernel.org/r/20221203094635.29024-1-yuehaibing@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8067cd244cea2c332f8326842fd10158fa2cb64f
Author: Liu Jian <liujian56@huawei.com>
Date:   Sat Dec 3 17:42:40 2022 +0800

    net: hisilicon: Fix potential use-after-free in hix5hd2_rx()
    
    [ Upstream commit 433c07a13f59856e4585e89e86b7d4cc59348fab ]
    
    The skb is delivered to napi_gro_receive() which may free it, after
    calling this, dereferencing skb may trigger use-after-free.
    
    Fixes: 57c5bc9ad7d7 ("net: hisilicon: add hix5hd2 mac driver")
    Signed-off-by: Liu Jian <liujian56@huawei.com>
    Link: https://lore.kernel.org/r/20221203094240.1240211-2-liujian56@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 196e12671cb629d9f3b77b4d8bec854fc445533a
Author: Liu Jian <liujian56@huawei.com>
Date:   Sat Dec 3 17:42:39 2022 +0800

    net: hisilicon: Fix potential use-after-free in hisi_femac_rx()
    
    [ Upstream commit 4640177049549de1a43e9bc49265f0cdfce08cfd ]
    
    The skb is delivered to napi_gro_receive() which may free it, after
    calling this, dereferencing skb may trigger use-after-free.
    
    Fixes: 542ae60af24f ("net: hisilicon: Add Fast Ethernet MAC driver")
    Signed-off-by: Liu Jian <liujian56@huawei.com>
    Link: https://lore.kernel.org/r/20221203094240.1240211-1-liujian56@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3630719271189794a237d7c4dda5c3e1a04c98f8
Author: Jisheng Zhang <jszhang@kernel.org>
Date:   Sat Dec 3 00:17:39 2022 +0800

    net: stmmac: fix "snps,axi-config" node property parsing
    
    [ Upstream commit 61d4f140943c47c1386ed89f7260e00418dfad9d ]
    
    In dt-binding snps,dwmac.yaml, some properties under "snps,axi-config"
    node are named without "axi_" prefix, but the driver expects the
    prefix. Since the dt-binding has been there for a long time, we'd
    better make driver match the binding for compatibility.
    
    Fixes: afea03656add ("stmmac: rework DMA bus setting and introduce new platform AXI structure")
    Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
    Link: https://lore.kernel.org/r/20221202161739.2203-1-jszhang@kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dbdcfb9f6748218a149f62468d6297ce3f014e9c
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Dec 2 13:44:14 2022 -0800

    NFC: nci: Bounds check struct nfc_target arrays
    
    [ Upstream commit e329e71013c9b5a4535b099208493c7826ee4a64 ]
    
    While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported:
    
      memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18)
    
    This appears to be a legitimate lack of bounds checking in
    nci_add_new_protocol(). Add the missing checks.
    
    Reported-by: syzbot+210e196cef4711b65139@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/lkml/0000000000001c590f05ee7b3ff4@google.com
    Fixes: 019c4fbaa790 ("NFC: Add NCI multiple targets support")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20221202214410.never.693-kees@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47a1a2f6cd5ec3a4f8a2d9bfa1e0605347cdb92c
Author: Dan Carpenter <error27@gmail.com>
Date:   Fri Dec 2 12:58:26 2022 +0300

    net: mvneta: Prevent out of bounds read in mvneta_config_rss()
    
    [ Upstream commit e8b4fc13900b8e8be48debffd0dfd391772501f7 ]
    
    The pp->indir[0] value comes from the user.  It is passed to:
    
            if (cpu_online(pp->rxq_def))
    
    inside the mvneta_percpu_elect() function.  It needs bounds checkeding
    to ensure that it is not beyond the end of the cpu bitmap.
    
    Fixes: cad5d847a093 ("net: mvneta: Fix the CPU choice in mvneta_percpu_elect")
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7af8f3ecfa84dfec645be245e0c118d1eed48b6
Author: Valentina Goncharenko <goncharenko.vp@ispras.ru>
Date:   Thu Dec 1 20:34:08 2022 +0300

    net: encx24j600: Fix invalid logic in reading of MISTAT register
    
    [ Upstream commit 25f427ac7b8d89b0259f86c0c6407b329df742b2 ]
    
    A loop for reading MISTAT register continues while regmap_read() fails
    and (mistat & BUSY), but if regmap_read() fails a value of mistat is
    undefined.
    
    The patch proposes to check for BUSY flag only when regmap_read()
    succeed. Compile test only.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: d70e53262f5c ("net: Microchip encx24j600 driver")
    Signed-off-by: Valentina Goncharenko <goncharenko.vp@ispras.ru>
    Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a5599c2c2c0baa9bb75c7d44d42e81e373e89c6
Author: Valentina Goncharenko <goncharenko.vp@ispras.ru>
Date:   Thu Dec 1 20:34:07 2022 +0300

    net: encx24j600: Add parentheses to fix precedence
    
    [ Upstream commit 167b3f2dcc62c271f3555b33df17e361bb1fa0ee ]
    
    In functions regmap_encx24j600_phy_reg_read() and
    regmap_encx24j600_phy_reg_write() in the conditions of the waiting
    cycles for filling the variable 'ret' it is necessary to add parentheses
    to prevent wrong assignment due to logical operations precedence.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: d70e53262f5c ("net: Microchip encx24j600 driver")
    Signed-off-by: Valentina Goncharenko <goncharenko.vp@ispras.ru>
    Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9980a3ea20de40c83817877106c909cb032692d2
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Wed Nov 30 09:17:05 2022 +0000

    mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()
    
    [ Upstream commit b3d72d3135d2ef68296c1ee174436efd65386f04 ]
    
    Kernel fault injection test reports null-ptr-deref as follows:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000008
    RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114
    Call Trace:
     <TASK>
     raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87
     call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944
     unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982
     unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879
     register_netdevice+0x9a8/0xb90 net/core/dev.c:10083
     ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659
     ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229
     mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316
    
    ieee802154_if_add() allocates wpan_dev as netdev's private data, but not
    init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage
    the list when device register/unregister, and may lead to null-ptr-deref.
    
    Use INIT_LIST_HEAD() on it to initialize it correctly.
    
    Fixes: fcf39e6e88e9 ("ieee802154: add wpan_dev_list")
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Acked-by: Alexander Aring <aahringo@redhat.com>
    
    Link: https://lore.kernel.org/r/20221130091705.1831140-1-weiyongjun@huaweicloud.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88ec63dee63f932ab461350161331fdd51e39c75
Author: Wang ShaoBo <bobo.shaobowang@huawei.com>
Date:   Wed Nov 9 17:37:26 2022 +0800

    Bluetooth: 6LoWPAN: add missing hci_dev_put() in get_l2cap_conn()
    
    [ Upstream commit 747da1308bdd5021409974f9180f0d8ece53d142 ]
    
    hci_get_route() takes reference, we should use hci_dev_put() to release
    it when not need anymore.
    
    Fixes: 6b8d4a6a0314 ("Bluetooth: 6LoWPAN: Use connected oriented channel instead of fixed one")
    Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1585997c4f2ab0c1fc08dd0146ddc16a336f583f
Author: Akihiko Odaki <akihiko.odaki@daynix.com>
Date:   Fri Nov 25 22:30:31 2022 +0900

    igb: Allocate MSI-X vector when testing
    
    [ Upstream commit 28e96556baca7056d11d9fb3cdd0aba4483e00d8 ]
    
    Without this change, the interrupt test fail with MSI-X environment:
    
    $ sudo ethtool -t enp0s2 offline
    [   43.921783] igb 0000:00:02.0: offline testing starting
    [   44.855824] igb 0000:00:02.0 enp0s2: igb: enp0s2 NIC Link is Down
    [   44.961249] igb 0000:00:02.0 enp0s2: igb: enp0s2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
    [   51.272202] igb 0000:00:02.0: testing shared interrupt
    [   56.996975] igb 0000:00:02.0 enp0s2: igb: enp0s2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
    The test result is FAIL
    The test extra info:
    Register test  (offline)         0
    Eeprom test    (offline)         0
    Interrupt test (offline)         4
    Loopback test  (offline)         0
    Link test   (on/offline)         0
    
    Here, "4" means an expected interrupt was not delivered.
    
    To fix this, route IRQs correctly to the first MSI-X vector by setting
    IVAR_MISC. Also, set bit 0 of EIMS so that the vector will not be
    masked. The interrupt test now runs properly with this change:
    
    $ sudo ethtool -t enp0s2 offline
    [   42.762985] igb 0000:00:02.0: offline testing starting
    [   50.141967] igb 0000:00:02.0: testing shared interrupt
    [   56.163957] igb 0000:00:02.0 enp0s2: igb: enp0s2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
    The test result is PASS
    The test extra info:
    Register test  (offline)         0
    Eeprom test    (offline)         0
    Interrupt test (offline)         0
    Loopback test  (offline)         0
    Link test   (on/offline)         0
    
    Fixes: 4eefa8f01314 ("igb: add single vector msi-x testing to interrupt test")
    Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
    Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 057ddc8ddf0a088a1960517010664e8e0edaae0e
Author: Akihiko Odaki <akihiko.odaki@daynix.com>
Date:   Fri Oct 28 22:00:00 2022 +0900

    e1000e: Fix TX dispatch condition
    
    [ Upstream commit eed913f6919e253f35d454b2f115f2a4db2b741a ]
    
    e1000_xmit_frame is expected to stop the queue and dispatch frames to
    hardware if there is not sufficient space for the next frame in the
    buffer, but sometimes it failed to do so because the estimated maximum
    size of frame was wrong. As the consequence, the later invocation of
    e1000_xmit_frame failed with NETDEV_TX_BUSY, and the frame in the buffer
    remained forever, resulting in a watchdog failure.
    
    This change fixes the estimated size by making it match with the
    condition for NETDEV_TX_BUSY. Apparently, the old estimation failed to
    account for the following lines which determines the space requirement
    for not causing NETDEV_TX_BUSY:
        ```
            /* reserve a descriptor for the offload context */
            if ((mss) || (skb->ip_summed == CHECKSUM_PARTIAL))
                    count++;
            count++;
    
            count += DIV_ROUND_UP(len, adapter->tx_fifo_limit);
        ```
    
    This issue was found when running http-stress02 test included in Linux
    Test Project 20220930 on QEMU with the following commandline:
    ```
    qemu-system-x86_64 -M q35,accel=kvm -m 8G -smp 8
            -drive if=virtio,format=raw,file=root.img,file.locking=on
            -device e1000e,netdev=netdev
            -netdev tap,script=ifup,downscript=no,id=netdev
    ```
    
    Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for ICH9 devices only)")
    Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
    Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Tested-by: Naama Meir <naamax.meir@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 71d591ef873f9ebb86cd8d053b3caee785b2de6a
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Tue Nov 22 20:35:08 2022 +0800

    gpio: amd8111: Fix PCI device reference count leak
    
    [ Upstream commit 45fecdb9f658d9c82960c98240bc0770ade19aca ]
    
    for_each_pci_dev() is implemented by pci_get_device(). The comment of
    pci_get_device() says that it will increase the reference count for the
    returned pci_dev and also decrease the reference count for the input
    pci_dev @from if it is not NULL.
    
    If we break for_each_pci_dev() loop with pdev not NULL, we need to call
    pci_dev_put() to decrease the reference count. Add the missing
    pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL
    input parameter, there is no problem for the 'Device not found' branch.
    For the normal path, add pci_dev_put() in amd_gpio_exit().
    
    Fixes: f942a7de047d ("gpio: add a driver for GPIO pins found on AMD-8111 south bridge chips")
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30f48686cf06a9b0565e61b8eada93dacaebf55f
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date:   Mon Nov 21 01:22:01 2022 +0100

    ca8210: Fix crash by zero initializing data
    
    [ Upstream commit 1e24c54da257ab93cff5826be8a793b014a5dc9c ]
    
    The struct cas_control embeds multiple generic SPI structures and we
    have to make sure these structures are initialized to default values.
    This driver does not set all attributes. When using kmalloc before some
    attributes were not initialized and contained random data which caused
    random crashes at bootup.
    
    Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
    Link: https://lore.kernel.org/r/20221121002201.1339636-1-hauke@hauke-m.de
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dcdf331276c9b13ed43c16f4810b3bd2dc006128
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Sun Nov 20 15:50:46 2022 +0800

    ieee802154: cc2520: Fix error return code in cc2520_hw_init()
    
    [ Upstream commit 4d002d6a2a00ac1c433899bd7625c6400a74cfba ]
    
    In cc2520_hw_init(), if oscillator start failed, the error code
    should be returned.
    
    Fixes: 0da6bc8cc341 ("ieee802154: cc2520: adds driver for TI CC2520 radio")
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Link: https://lore.kernel.org/r/20221120075046.2213633-1-william.xuanziyang@huawei.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 809783f8b4b600c7fb3bccb10fefef822601ea3b
Author: ZhangPeng <zhangpeng362@huawei.com>
Date:   Wed Nov 16 07:14:28 2022 +0000

    HID: core: fix shift-out-of-bounds in hid_report_raw_event
    
    commit ec61b41918587be530398b0d1c9a0d16619397e5 upstream.
    
    Syzbot reported shift-out-of-bounds in hid_report_raw_event.
    
    microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) >
    32! (swapper/0)
    ======================================================================
    UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20
    shift exponent 127 is too large for 32-bit type 'int'
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted
    6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0
    Hardware name: Google Compute Engine/Google Compute Engine, BIOS
    Google 10/26/2022
    Call Trace:
     <IRQ>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
     ubsan_epilogue lib/ubsan.c:151 [inline]
     __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322
     snto32 drivers/hid/hid-core.c:1323 [inline]
     hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]
     hid_process_report drivers/hid/hid-core.c:1665 [inline]
     hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998
     hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066
     hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284
     __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671
     dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988
     call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474
     expire_timers kernel/time/timer.c:1519 [inline]
     __run_timers+0x76a/0x980 kernel/time/timer.c:1790
     run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803
     __do_softirq+0x277/0x75b kernel/softirq.c:571
     __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650
     irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
     sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107
    ======================================================================
    
    If the size of the integer (unsigned n) is bigger than 32 in snto32(),
    shift exponent will be too large for 32-bit type 'int', resulting in a
    shift-out-of-bounds bug.
    Fix this by adding a check on the size of the integer (unsigned n) in
    snto32(). To add support for n greater than 32 bits, set n to 32, if n
    is greater than 32.
    
    Reported-by: syzbot+8b1641d2f14732407e23@syzkaller.appspotmail.com
    Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
    Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8f91e4272c99df85d43c20f14aeaf7da34a0037
Author: Anastasia Belova <abelova@astralinux.ru>
Date:   Fri Nov 11 15:55:11 2022 +0300

    HID: hid-lg4ff: Add check for empty lbuf
    
    commit d180b6496143cd360c5d5f58ae4b9a8229c1f344 upstream.
    
    If an empty buf is received, lbuf is also empty. So lbuf is
    accessed by index -1.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: f31a2de3fe36 ("HID: hid-lg4ff: Allow switching of Logitech gaming wheels between compatibility modes")
    Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd331f7b43a818410a0e4fe2938ba5bf278868ea
Author: Thomas Huth <thuth@redhat.com>
Date:   Wed Nov 23 10:08:33 2022 +0100

    KVM: s390: vsie: Fix the initialization of the epoch extension (epdx) field
    
    commit 0dd4cdccdab3d74bd86b868768a7dca216bcce7e upstream.
    
    We recently experienced some weird huge time jumps in nested guests when
    rebooting them in certain cases. After adding some debug code to the epoch
    handling in vsie.c (thanks to David Hildenbrand for the idea!), it was
    obvious that the "epdx" field (the multi-epoch extension) did not get set
    to 0xff in case the "epoch" field was negative.
    Seems like the code misses to copy the value from the epdx field from
    the guest to the shadow control block. By doing so, the weird time
    jumps are gone in our scenarios.
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2140899
    Fixes: 8fa1696ea781 ("KVM: s390: Multiple Epoch Facility support")
    Signed-off-by: Thomas Huth <thuth@redhat.com>
    Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
    Cc: stable@vger.kernel.org # 4.19+
    Link: https://lore.kernel.org/r/20221123090833.292938-1-thuth@redhat.com
    Message-Id: <20221123090833.292938-1-thuth@redhat.com>
    Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b77600e26fd48727a95ffd50ba1e937efb548125
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Dec 7 16:53:15 2022 -1000

    memcg: fix possible use-after-free in memcg_write_event_control()
    
    commit 4a7ba45b1a435e7097ca0f79a847d0949d0eb088 upstream.
    
    memcg_write_event_control() accesses the dentry->d_name of the specified
    control fd to route the write call.  As a cgroup interface file can't be
    renamed, it's safe to access d_name as long as the specified file is a
    regular cgroup file.  Also, as these cgroup interface files can't be
    removed before the directory, it's safe to access the parent too.
    
    Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a
    call to __file_cft() which verified that the specified file is a regular
    cgroupfs file before further accesses.  The cftype pointer returned from
    __file_cft() was no longer necessary and the commit inadvertently dropped
    the file type check with it allowing any file to slip through.  With the
    invarients broken, the d_name and parent accesses can now race against
    renames and removals of arbitrary files and cause use-after-free's.
    
    Fix the bug by resurrecting the file type check in __file_cft().  Now that
    cgroupfs is implemented through kernfs, checking the file operations needs
    to go through a layer of indirection.  Instead, let's check the superblock
    and dentry type.
    
    Link: https://lkml.kernel.org/r/Y5FRm/cfcKPGzWwl@slm.duckdns.org
    Fixes: 347c4a874710 ("memcg: remove cgroup_event->cft")
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Jann Horn <jannh@google.com>
    Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Muchun Song <songmuchun@bytedance.com>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: <stable@vger.kernel.org>    [3.14+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2b56627c0d13009e02f6f2c0206c0451ed19a0e
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Wed Nov 16 15:07:22 2022 +0000

    media: v4l2-dv-timings.c: fix too strict blanking sanity checks
    
    commit 5eef2141776da02772c44ec406d6871a790761ee upstream.
    
    Sanity checks were added to verify the v4l2_bt_timings blanking fields
    in order to avoid integer overflows when userspace passes weird values.
    
    But that assumed that userspace would correctly fill in the front porch,
    backporch and sync values, but sometimes all you know is the total
    blanking, which is then assigned to just one of these fields.
    
    And that can fail with these checks.
    
    So instead set a maximum for the total horizontal and vertical
    blanking and check that each field remains below that.
    
    That is still sufficient to avoid integer overflows, but it also
    allows for more flexibility in how userspace fills in these fields.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Fixes: 4b6d66a45ed3 ("media: v4l2-dv-timings: add sanity checks for blanking values")
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9c76749c79a52692e71dc7a7f373d372573f213
Author: Connor Shu <Connor.Shu@ibm.com>
Date:   Wed Aug 22 14:16:46 2018 -0700

    rcutorture: Automatically create initrd directory
    
    [ Upstream commit 8f15c682ac5a778feb8e343f9057b89beb40d85b ]
    
    The rcutorture scripts currently expect the user to create the
    tools/testing/selftests/rcutorture/initrd directory.  Should the user
    fail to do this, the kernel build will fail with obscure and confusing
    error messages.  This commit therefore adds explicit checks for the
    tools/testing/selftests/rcutorture/initrd directory, and if not present,
    creates one on systems on which dracut is installed.  If this directory
    could not be created, a less obscure error message is emitted and the
    test is aborted.
    
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Connor Shu <Connor.Shu@ibm.com>
    [ paulmck: Adapt the script to fit into the rcutorture framework and
      severely abbreviate the initrd/init script. ]
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b81c566ab5724976de59ad7787e204f7938ae27
Author: Juergen Gross <jgross@suse.com>
Date:   Tue Dec 6 08:54:24 2022 +0100

    xen/netback: don't call kfree_skb() with interrupts disabled
    
    [ Upstream commit 74e7e1efdad45580cc3839f2a155174cf158f9b5 ]
    
    It is not allowed to call kfree_skb() from hardware interrupt
    context or with interrupts being disabled. So remove kfree_skb()
    from the spin_lock_irqsave() section and use the already existing
    "drop" label in xenvif_start_xmit() for dropping the SKB. At the
    same time replace the dev_kfree_skb() call there with a call of
    dev_kfree_skb_any(), as xenvif_start_xmit() can be called with
    disabled interrupts.
    
    This is XSA-424 / CVE-2022-42328 / CVE-2022-42329.
    
    Fixes: be81992f9086 ("xen/netback: don't queue unlimited number of packages")
    Reported-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff3f010d2a3e75106792a1706bdb4a9978655f97
Author: Juergen Gross <jgross@suse.com>
Date:   Wed Jun 8 06:37:26 2022 +0200

    xen/netback: do some code cleanup
    
    [ Upstream commit 5834e72eda0b7e5767eb107259d98eef19ebd11f ]
    
    Remove some unused macros and functions, make local functions static.
    
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Acked-by: Wei Liu <wei.liu@kernel.org>
    Link: https://lore.kernel.org/r/20220608043726.9380-1-jgross@suse.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 74e7e1efdad4 ("xen/netback: don't call kfree_skb() with interrupts disabled")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e173cefc814dec81e9836ecc866cdba154e693cd
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Tue Nov 22 09:16:59 2022 +0000

    xen/netback: Ensure protocol headers don't fall in the non-linear area
    
    [ Upstream commit ad7f402ae4f466647c3a669b8a6f3e5d4271c84a ]
    
    In some cases, the frontend may send a packet where the protocol headers
    are spread across multiple slots. This would result in netback creating
    an skb where the protocol headers spill over into the non-linear area.
    Some drivers and NICs don't handle this properly resulting in an
    interface reset or worse.
    
    This issue was introduced by the removal of an unconditional skb pull in
    the tx path to improve performance.  Fix this without reintroducing the
    pull by setting up grant copy ops for as many slots as needed to reach
    the XEN_NETBACK_TX_COPY_LEN size. Adjust the rest of the code to handle
    multiple copy operations per skb.
    
    This is XSA-423 / CVE-2022-3643.
    
    Fixes: 7e5d7753956b ("xen-netback: remove unconditional __pskb_pull_tail() in guest Tx path")
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Reviewed-by: Paul Durrant <paul@xen.org>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fba11fb6d0c92a25e5d62ac682dc90605f3cebbd
Author: Davide Tronchin <davide.tronchin.94@gmail.com>
Date:   Mon Nov 21 13:54:55 2022 +0100

    net: usb: qmi_wwan: add u-blox 0x1342 composition
    
    [ Upstream commit a487069e11b6527373f7c6f435d8998051d0b5d9 ]
    
    Add RmNet support for LARA-L6.
    
    LARA-L6 module can be configured (by AT interface) in three different
    USB modes:
    * Default mode (Vendor ID: 0x1546 Product ID: 0x1341) with 4 serial
    interfaces
    * RmNet mode (Vendor ID: 0x1546 Product ID: 0x1342) with 4 serial
    interfaces and 1 RmNet virtual network interface
    * CDC-ECM mode (Vendor ID: 0x1546 Product ID: 0x1343) with 4 serial
    interface and 1 CDC-ECM virtual network interface
    
    In RmNet mode LARA-L6 exposes the following interfaces:
    If 0: Diagnostic
    If 1: AT parser
    If 2: AT parser
    If 3: AT parset/alternative functions
    If 4: RMNET interface
    
    Signed-off-by: Davide Tronchin <davide.tronchin.94@gmail.com>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24e846a1a028bd30bce69ccedcb195db4c903529
Author: Andreas Kemnade <andreas@kemnade.info>
Date:   Sun Nov 20 23:12:08 2022 +0100

    regulator: twl6030: fix get status of twl6032 regulators
    
    [ Upstream commit 31a6297b89aabc81b274c093a308a7f5b55081a7 ]
    
    Status is reported as always off in the 6032 case. Status
    reporting now matches the logic in the setters. Once of
    the differences to the 6030 is that there are no groups,
    therefore the state needs to be read out in the lower bits.
    
    Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
    Link: https://lore.kernel.org/r/20221120221208.3093727-3-andreas@kemnade.info
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4dd21a79dbb862d2ebcf9ed90e646416009ff0d
Author: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
Date:   Tue Nov 22 12:01:13 2022 +0530

    ASoC: soc-pcm: Add NULL check in BE reparenting
    
    [ Upstream commit db8f91d424fe0ea6db337aca8bc05908bbce1498 ]
    
    Add NULL check in dpcm_be_reparent API, to handle
    kernel NULL pointer dereference error.
    The issue occurred in fuzzing test.
    
    Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
    Link: https://lore.kernel.org/r/1669098673-29703-1-git-send-email-quic_srivasam@quicinc.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e385360705a0b346bdb57ce938249175d0613b8a
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Nov 18 15:23:50 2022 -0800

    ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event
    
    [ Upstream commit 05530ef7cf7c7d700f6753f058999b1b5099a026 ]
    
    With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
    indirect call targets are validated against the expected function
    pointer prototype to make sure the call target is valid to help mitigate
    ROP attacks. If they are not identical, there is a failure at run time,
    which manifests as either a kernel panic or thread getting killed.
    
    seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes
    matching snd_seq_dump_func_t. Adjust this and remove the casts. There
    are not resulting binary output differences.
    
    This was found as a result of Clang's new -Wcast-function-type-strict
    flag, which is more sensitive than the simpler -Wcast-function-type,
    which only checks for type width mismatches.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/lkml/202211041527.HD8TLSE1-lkp@intel.com
    Cc: Jaroslav Kysela <perex@perex.cz>
    Cc: Takashi Iwai <tiwai@suse.com>
    Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
    Cc: alsa-devel@alsa-project.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221118232346.never.380-kees@kernel.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 992a37d814809e9ea9e10f387f4e86c09e8e3ba9
Author: Johan Jonker <jbx6244@gmail.com>
Date:   Sun Oct 30 21:56:29 2022 +0100

    ARM: dts: rockchip: disable arm_global_timer on rk3066 and rk3188
    
    [ Upstream commit da74858a475782a3f16470907814c8cc5950ad68 ]
    
    The clock source and the sched_clock provided by the arm_global_timer
    on Rockchip rk3066a/rk3188 are quite unstable because their rates
    depend on the CPU frequency.
    
    Recent changes to the arm_global_timer driver makes it impossible to use.
    
    On the other side, the arm_global_timer has a higher rating than the
    ROCKCHIP_TIMER, it will be selected by default by the time framework
    while we want to use the stable Rockchip clock source.
    
    Keep the arm_global_timer disabled in order to have the
    DW_APB_TIMER (rk3066a) or ROCKCHIP_TIMER (rk3188) selected by default.
    
    Signed-off-by: Johan Jonker <jbx6244@gmail.com>
    Link: https://lore.kernel.org/r/f275ca8d-fd0a-26e5-b978-b7f3df815e0a@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 791d3a5322ff7379c7f8651f92b640c719229ef6
Author: Giulio Benetti <giulio.benetti@benettiengineering.com>
Date:   Fri Nov 4 21:46:18 2022 +0100

    ARM: 9266/1: mm: fix no-MMU ZERO_PAGE() implementation
    
    [ Upstream commit 340a982825f76f1cff0daa605970fe47321b5ee7 ]
    
    Actually in no-MMU SoCs(i.e. i.MXRT) ZERO_PAGE(vaddr) expands to
    ```
    virt_to_page(0)
    ```
    that in order expands to:
    ```
    pfn_to_page(virt_to_pfn(0))
    ```
    and then virt_to_pfn(0) to:
    ```
            ((((unsigned long)(0) - PAGE_OFFSET) >> PAGE_SHIFT) +
             PHYS_PFN_OFFSET)
    ```
    where PAGE_OFFSET and PHYS_PFN_OFFSET are the DRAM offset(0x80000000) and
    PAGE_SHIFT is 12. This way we obtain 16MB(0x01000000) summed to the base of
    DRAM(0x80000000).
    When ZERO_PAGE(0) is then used, for example in bio_add_page(), the page
    gets an address that is out of DRAM bounds.
    So instead of using fake virtual page 0 let's allocate a dedicated
    zero_page during paging_init() and assign it to a global 'struct page *
    empty_zero_page' the same way mmu.c does and it's the same approach used
    in m68k with commit dc068f462179 as discussed here[0]. Then let's move
    ZERO_PAGE() definition to the top of pgtable.h to be in common between
    mmu.c and nommu.c.
    
    [0]: https://lore.kernel.org/linux-m68k/2a462b23-5b8e-bbf4-ec7d-778434a3b9d7@google.com/T/#m1266ceb63
    ad140743174d6b3070364d3c9a5179b
    
    Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e519b09cb620398a83a77c0c3eda267d5c4e3e0
Author: Tomislav Novak <tnovak@fb.com>
Date:   Mon Sep 26 16:09:12 2022 +0100

    ARM: 9251/1: perf: Fix stacktraces for tracepoint events in THUMB2 kernels
    
    [ Upstream commit 612695bccfdbd52004551308a55bae410e7cd22f ]
    
    Store the frame address where arm_get_current_stackframe() looks for it
    (ARM_r7 instead of ARM_fp if CONFIG_THUMB2_KERNEL=y). Otherwise frame->fp
    gets set to 0, causing unwind_frame() to fail.
    
      # bpftrace -e 't:sched:sched_switch { @[kstack] = count(); exit(); }'
      Attaching 1 probe...
      @[
          __schedule+1059
      ]: 1
    
    A typical first unwind instruction is 0x97 (SP = R7), so after executing
    it SP ends up being 0 and -URC_FAILURE is returned.
    
      unwind_frame(pc = ac9da7d7 lr = 00000000 sp = c69bdda0 fp = 00000000)
      unwind_find_idx(ac9da7d7)
      unwind_exec_insn: insn = 00000097
      unwind_exec_insn: fp = 00000000 sp = 00000000 lr = 00000000 pc = 00000000
    
    With this patch:
    
      # bpftrace -e 't:sched:sched_switch { @[kstack] = count(); exit(); }'
      Attaching 1 probe...
      @[
          __schedule+1059
          __schedule+1059
          schedule+79
          schedule_hrtimeout_range_clock+163
          schedule_hrtimeout_range+17
          ep_poll+471
          SyS_epoll_wait+111
          sys_epoll_pwait+231
          __ret_fast_syscall+1
      ]: 1
    
    Link: https://lore.kernel.org/r/20220920230728.2617421-1-tnovak@fb.com/
    
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Tomislav Novak <tnovak@fb.com>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70ebc092cec2e4e8da3d3932b2b290a85b31beca
Author: Johan Jonker <jbx6244@gmail.com>
Date:   Thu Oct 27 10:58:22 2022 +0200

    ARM: dts: rockchip: fix ir-receiver node names
    
    [ Upstream commit dd847fe34cdf1e89afed1af24986359f13082bfb ]
    
    Fix ir-receiver node names on Rockchip boards,
    so that they match with regex: '^ir(-receiver)?(@[a-f0-9]+)?$'
    
    Signed-off-by: Johan Jonker <jbx6244@gmail.com>
    Link: https://lore.kernel.org/r/ea5af279-f44c-afea-023d-bb37f5a0d58d@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44e412ff39a512e0f98ef08aec0f556bab4f1b95
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date:   Mon Oct 24 18:55:46 2022 +0200

    arm: dts: rockchip: fix node name for hym8563 rtc
    
    [ Upstream commit 17b57beafccb4569accbfc8c11390744cf59c021 ]
    
    Fix the node name for hym8563 in all arm rockchip devicetrees.
    
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Link: https://lore.kernel.org/r/20221024165549.74574-4-sebastian.reichel@collabora.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>