Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hsr: avoid potential out-of-bound access in fill_frame_info()<br /> <br /> syzbot is able to feed a packet with 14 bytes, pretending<br /> it is a vlan one.<br /> <br /> Since fill_frame_info() is relying on skb-&gt;mac_len already,<br /> extend the check to cover this case.<br /> <br /> BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]<br /> BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724<br /> fill_frame_info net/hsr/hsr_forward.c:709 [inline]<br /> hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724<br /> hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235<br /> __netdev_start_xmit include/linux/netdevice.h:5002 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5011 [inline]<br /> xmit_one net/core/dev.c:3590 [inline]<br /> dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606<br /> __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434<br /> dev_queue_xmit include/linux/netdevice.h:3168 [inline]<br /> packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276<br /> packet_snd net/packet/af_packet.c:3146 [inline]<br /> packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:726<br /> __sys_sendto+0x594/0x750 net/socket.c:2197<br /> __do_sys_sendto net/socket.c:2204 [inline]<br /> __se_sys_sendto net/socket.c:2200 [inline]<br /> __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200<br /> x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4091 [inline]<br /> slab_alloc_node mm/slub.c:4134 [inline]<br /> kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186<br /> kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587<br /> __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678<br /> alloc_skb include/linux/skbuff.h:1323 [inline]<br /> alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612<br /> sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881<br /> packet_alloc_skb net/packet/af_packet.c:2995 [inline]<br /> packet_snd net/packet/af_packet.c:3089 [inline]<br /> packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:726<br /> __sys_sendto+0x594/0x750 net/socket.c:2197<br /> __do_sys_sendto net/socket.c:2204 [inline]<br /> __se_sys_sendto net/socket.c:2200 [inline]<br /> __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200<br /> x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: enetc: Do not configure preemptible TCs if SIs do not support<br /> <br /> Both ENETC PF and VF drivers share enetc_setup_tc_mqprio() to configure<br /> MQPRIO. And enetc_setup_tc_mqprio() calls enetc_change_preemptible_tcs()<br /> to configure preemptible TCs. However, only PF is able to configure<br /> preemptible TCs. Because only PF has related registers, while VF does not<br /> have these registers. So for VF, its hw-&gt;port pointer is NULL. Therefore,<br /> VF will access an invalid pointer when accessing a non-existent register,<br /> which will cause a crash issue. The simplified log is as follows.<br /> <br /> root@ls1028ardb:~# tc qdisc add dev eno0vf0 parent root handle 100: \<br /> mqprio num_tc 4 map 0 0 1 1 2 2 3 3 queues 1@0 1@1 1@2 1@3 hw 1<br /> [ 187.290775] Unable to handle kernel paging request at virtual address 0000000000001f00<br /> [ 187.424831] pc : enetc_mm_commit_preemptible_tcs+0x1c4/0x400<br /> [ 187.430518] lr : enetc_mm_commit_preemptible_tcs+0x30c/0x400<br /> [ 187.511140] Call trace:<br /> [ 187.513588] enetc_mm_commit_preemptible_tcs+0x1c4/0x400<br /> [ 187.518918] enetc_setup_tc_mqprio+0x180/0x214<br /> [ 187.523374] enetc_vf_setup_tc+0x1c/0x30<br /> [ 187.527306] mqprio_enable_offload+0x144/0x178<br /> [ 187.531766] mqprio_init+0x3ec/0x668<br /> [ 187.535351] qdisc_create+0x15c/0x488<br /> [ 187.539023] tc_modify_qdisc+0x398/0x73c<br /> [ 187.542958] rtnetlink_rcv_msg+0x128/0x378<br /> [ 187.547064] netlink_rcv_skb+0x60/0x130<br /> [ 187.550910] rtnetlink_rcv+0x18/0x24<br /> [ 187.554492] netlink_unicast+0x300/0x36c<br /> [ 187.558425] netlink_sendmsg+0x1a8/0x420<br /> [ 187.606759] ---[ end trace 0000000000000000 ]---<br /> <br /> In addition, some PFs also do not support configuring preemptible TCs,<br /> such as eno1 and eno3 on LS1028A. It won&amp;#39;t crash like it does for VFs,<br /> but we should prevent these PFs from accessing these unimplemented<br /> registers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: fix LED ID check in led_tg_check()<br /> <br /> Syzbot has reported the following BUG detected by KASAN:<br /> <br /> BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70<br /> Read of size 1 at addr ffff8881022da0c8 by task repro/5879<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x241/0x360<br /> ? __pfx_dump_stack_lvl+0x10/0x10<br /> ? __pfx__printk+0x10/0x10<br /> ? _printk+0xd5/0x120<br /> ? __virt_addr_valid+0x183/0x530<br /> ? __virt_addr_valid+0x183/0x530<br /> print_report+0x169/0x550<br /> ? __virt_addr_valid+0x183/0x530<br /> ? __virt_addr_valid+0x183/0x530<br /> ? __virt_addr_valid+0x45f/0x530<br /> ? __phys_addr+0xba/0x170<br /> ? strlen+0x58/0x70<br /> kasan_report+0x143/0x180<br /> ? strlen+0x58/0x70<br /> strlen+0x58/0x70<br /> kstrdup+0x20/0x80<br /> led_tg_check+0x18b/0x3c0<br /> xt_check_target+0x3bb/0xa40<br /> ? __pfx_xt_check_target+0x10/0x10<br /> ? stack_depot_save_flags+0x6e4/0x830<br /> ? nft_target_init+0x174/0xc30<br /> nft_target_init+0x82d/0xc30<br /> ? __pfx_nft_target_init+0x10/0x10<br /> ? nf_tables_newrule+0x1609/0x2980<br /> ? nf_tables_newrule+0x1609/0x2980<br /> ? rcu_is_watching+0x15/0xb0<br /> ? nf_tables_newrule+0x1609/0x2980<br /> ? nf_tables_newrule+0x1609/0x2980<br /> ? __kmalloc_noprof+0x21a/0x400<br /> nf_tables_newrule+0x1860/0x2980<br /> ? __pfx_nf_tables_newrule+0x10/0x10<br /> ? __nla_parse+0x40/0x60<br /> nfnetlink_rcv+0x14e5/0x2ab0<br /> ? __pfx_validate_chain+0x10/0x10<br /> ? __pfx_nfnetlink_rcv+0x10/0x10<br /> ? __lock_acquire+0x1384/0x2050<br /> ? netlink_deliver_tap+0x2e/0x1b0<br /> ? __pfx_lock_release+0x10/0x10<br /> ? netlink_deliver_tap+0x2e/0x1b0<br /> netlink_unicast+0x7f8/0x990<br /> ? __pfx_netlink_unicast+0x10/0x10<br /> ? __virt_addr_valid+0x183/0x530<br /> ? __check_object_size+0x48e/0x900<br /> netlink_sendmsg+0x8e4/0xcb0<br /> ? __pfx_netlink_sendmsg+0x10/0x10<br /> ? aa_sock_msg_perm+0x91/0x160<br /> ? __pfx_netlink_sendmsg+0x10/0x10<br /> __sock_sendmsg+0x223/0x270<br /> ____sys_sendmsg+0x52a/0x7e0<br /> ? __pfx_____sys_sendmsg+0x10/0x10<br /> __sys_sendmsg+0x292/0x380<br /> ? __pfx___sys_sendmsg+0x10/0x10<br /> ? lockdep_hardirqs_on_prepare+0x43d/0x780<br /> ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10<br /> ? exc_page_fault+0x590/0x8c0<br /> ? do_syscall_64+0xb6/0x230<br /> do_syscall_64+0xf3/0x230<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> ...<br /> <br /> <br /> Since an invalid (without &amp;#39;\0&amp;#39; byte at all) byte sequence may be passed<br /> from userspace, add an extra check to ensure that such a sequence is<br /> rejected as possible ID and so never passed to &amp;#39;kstrdup()&amp;#39; and further.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: hi311x: hi3110_can_ist(): fix potential use-after-free<br /> <br /> The commit a22bd630cfff ("can: hi311x: do not report txerr and rxerr<br /> during bus-off") removed the reporting of rxerr and txerr even in case<br /> of correct operation (i. e. not bus-off).<br /> <br /> The error count information added to the CAN frame after netif_rx() is<br /> a potential use after free, since there is no guarantee that the skb<br /> is in the same state. It might be freed or reused.<br /> <br /> Fix the issue by postponing the netif_rx() call in case of txerr and<br /> rxerr reporting.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dccp: Fix memory leak in dccp_feat_change_recv<br /> <br /> If dccp_feat_push_confirm() fails after new value for SP feature was accepted<br /> without reconciliation (&amp;#39;entry == NULL&amp;#39; branch), memory allocated for that value<br /> with dccp_feat_clone_sp_val() is never freed.<br /> <br /> Here is the kmemleak stack for this:<br /> <br /> unreferenced object 0xffff88801d4ab488 (size 8):<br /> comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s)<br /> hex dump (first 8 bytes):<br /> 01 b4 4a 1d 80 88 ff ff ..J.....<br /> backtrace:<br /> [] kmemdup+0x23/0x50 mm/util.c:128<br /> [] kmemdup include/linux/string.h:465 [inline]<br /> [] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline]<br /> [] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline]<br /> [] dccp_feat_change_recv net/dccp/feat.c:1145 [inline]<br /> [] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416<br /> [] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125<br /> [] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650<br /> [] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688<br /> [] sk_backlog_rcv include/net/sock.h:1041 [inline]<br /> [] __release_sock+0x139/0x3b0 net/core/sock.c:2570<br /> [] release_sock+0x54/0x1b0 net/core/sock.c:3111<br /> [] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline]<br /> [] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696<br /> [] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735<br /> [] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865<br /> [] __sys_connect+0x165/0x1a0 net/socket.c:1882<br /> [] __do_sys_connect net/socket.c:1892 [inline]<br /> [] __se_sys_connect net/socket.c:1889 [inline]<br /> [] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889<br /> [] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46<br /> [] entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> <br /> Clean up the allocated memory in case of dccp_feat_push_confirm() failure<br /> and bail out with an error reset code.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: grgpio: Add NULL check in grgpio_probe<br /> <br /> devm_kasprintf() can return a NULL pointer on failure,but this<br /> returned value in grgpio_probe is not checked.<br /> Add NULL check in grgpio_probe, to handle kernel NULL<br /> pointer dereference error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> geneve: do not assume mac header is set in geneve_xmit_skb()<br /> <br /> We should not assume mac header is set in output path.<br /> <br /> Use skb_eth_hdr() instead of eth_hdr() to fix the issue.<br /> <br /> sysbot reported the following :<br /> <br /> WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline]<br /> WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline]<br /> WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline]<br /> WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline]<br /> RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline]<br /> RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline]<br /> RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039<br /> Code: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ff<br /> RSP: 0018:ffffc90003b2f870 EFLAGS: 00010283<br /> RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000<br /> RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003<br /> RBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffff<br /> R10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000<br /> R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23<br /> FS: 00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __netdev_start_xmit include/linux/netdevice.h:5002 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5011 [inline]<br /> __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490<br /> dev_direct_xmit include/linux/netdevice.h:3181 [inline]<br /> packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285<br /> packet_snd net/packet/af_packet.c:3146 [inline]<br /> packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg net/socket.c:726 [inline]<br /> __sys_sendto+0x488/0x4f0 net/socket.c:2197<br /> __do_sys_sendto net/socket.c:2204 [inline]<br /> __se_sys_sendto net/socket.c:2200 [inline]<br /> __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: Hold module reference while requesting a module<br /> <br /> User space may unload ip_set.ko while it is itself requesting a set type<br /> backend module, leading to a kernel crash. The race condition may be<br /> provoked by inserting an mdelay() right after the nfnl_unlock() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_inner: incorrect percpu area handling under softirq<br /> <br /> Softirq can interrupt ongoing packet from process context that is<br /> walking over the percpu area that contains inner header offsets.<br /> <br /> Disable bh and perform three checks before restoring the percpu inner<br /> header offsets to validate that the percpu area is valid for this<br /> skbuff:<br /> <br /> 1) If the NFT_PKTINFO_INNER_FULL flag is set on, then this skbuff<br /> has already been parsed before for inner header fetching to<br /> register.<br /> <br /> 2) Validate that the percpu area refers to this skbuff using the<br /> skbuff pointer as a cookie. If there is a cookie mismatch, then<br /> this skbuff needs to be parsed again.<br /> <br /> 3) Finally, validate if the percpu area refers to this tunnel type.<br /> <br /> Only after these three checks the percpu area is restored to a on-stack<br /> copy and bh is enabled again.<br /> <br /> After inner header fetching, the on-stack copy is stored back to the<br /> percpu area.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hsr: must allocate more bytes for RedBox support<br /> <br /> Blamed commit forgot to change hsr_init_skb() to allocate<br /> larger skb for RedBox case.<br /> <br /> Indeed, send_hsr_supervision_frame() will add<br /> two additional components (struct hsr_sup_tlv<br /> and struct hsr_sup_payload)<br /> <br /> syzbot reported the following crash:<br /> skbuff: skb_over_panic: text:ffffffff8afd4b0a len:34 put:6 head:ffff88802ad29e00 data:ffff88802ad29f22 tail:0x144 end:0x140 dev:gretap0<br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/skbuff.c:206 !<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 2 UID: 0 PID: 7611 Comm: syz-executor Not tainted 6.12.0-syzkaller #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:skb_panic+0x157/0x1d0 net/core/skbuff.c:206<br /> Code: b6 04 01 84 c0 74 04 3c 03 7e 21 8b 4b 70 41 56 45 89 e8 48 c7 c7 a0 7d 9b 8c 41 57 56 48 89 ee 52 4c 89 e2 e8 9a 76 79 f8 90 0b 4c 89 4c 24 10 48 89 54 24 08 48 89 34 24 e8 94 76 fb f8 4c<br /> RSP: 0018:ffffc90000858ab8 EFLAGS: 00010282<br /> RAX: 0000000000000087 RBX: ffff8880598c08c0 RCX: ffffffff816d3e69<br /> RDX: 0000000000000000 RSI: ffffffff816de786 RDI: 0000000000000005<br /> RBP: ffffffff8c9b91c0 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000000000302 R11: ffffffff961cc1d0 R12: ffffffff8afd4b0a<br /> R13: 0000000000000006 R14: ffff88804b938130 R15: 0000000000000140<br /> FS: 000055558a3d6500(0000) GS:ffff88806a800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f1295974ff8 CR3: 000000002ab6e000 CR4: 0000000000352ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> skb_over_panic net/core/skbuff.c:211 [inline]<br /> skb_put+0x174/0x1b0 net/core/skbuff.c:2617<br /> send_hsr_supervision_frame+0x6fa/0x9e0 net/hsr/hsr_device.c:342<br /> hsr_proxy_announce+0x1a3/0x4a0 net/hsr/hsr_device.c:436<br /> call_timer_fn+0x1a0/0x610 kernel/time/timer.c:1794<br /> expire_timers kernel/time/timer.c:1845 [inline]<br /> __run_timers+0x6e8/0x930 kernel/time/timer.c:2419<br /> __run_timer_base kernel/time/timer.c:2430 [inline]<br /> __run_timer_base kernel/time/timer.c:2423 [inline]<br /> run_timer_base+0x111/0x190 kernel/time/timer.c:2439<br /> run_timer_softirq+0x1a/0x40 kernel/time/timer.c:2449<br /> handle_softirqs+0x213/0x8f0 kernel/softirq.c:554<br /> __do_softirq kernel/softirq.c:588 [inline]<br /> invoke_softirq kernel/softirq.c:428 [inline]<br /> __irq_exit_rcu kernel/softirq.c:637 [inline]<br /> irq_exit_rcu+0xbb/0x120 kernel/softirq.c:649<br /> instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]<br /> sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: initialize close_work early to avoid warning<br /> <br /> We encountered a warning that close_work was canceled before<br /> initialization.<br /> <br /> WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0<br /> Workqueue: events smc_lgr_terminate_work [smc]<br /> RIP: 0010:__flush_work+0x19e/0x1b0<br /> Call Trace:<br /> ? __wake_up_common+0x7a/0x190<br /> ? work_busy+0x80/0x80<br /> __cancel_work_timer+0xe3/0x160<br /> smc_close_cancel_work+0x1a/0x70 [smc]<br /> smc_close_active_abort+0x207/0x360 [smc]<br /> __smc_lgr_terminate.part.38+0xc8/0x180 [smc]<br /> process_one_work+0x19e/0x340<br /> worker_thread+0x30/0x370<br /> ? process_one_work+0x340/0x340<br /> kthread+0x117/0x130<br /> ? __kthread_cancel_work+0x50/0x50<br /> ret_from_fork+0x22/0x30<br /> <br /> This is because when smc_close_cancel_work is triggered, e.g. the RDMA<br /> driver is rmmod and the LGR is terminated, the conn-&gt;close_work is<br /> flushed before initialization, resulting in WARN_ON(!work-&gt;func).<br /> <br /> __smc_lgr_terminate | smc_connect_{rdma|ism}<br /> -------------------------------------------------------------<br /> | smc_conn_create<br /> | \- smc_lgr_register_conn<br /> for conn in lgr-&gt;conns_all |<br /> \- smc_conn_kill |<br /> \- smc_close_active_abort |<br /> \- smc_close_cancel_work |<br /> \- cancel_work_sync |<br /> \- __flush_work |<br /> (close_work) |<br /> | smc_close_init<br /> | \- INIT_WORK(&amp;close_work)<br /> <br /> So fix this by initializing close_work before establishing the<br /> connection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: avoid potential UAF in default_operstate()<br /> <br /> syzbot reported an UAF in default_operstate() [1]<br /> <br /> Issue is a race between device and netns dismantles.<br /> <br /> After calling __rtnl_unlock() from netdev_run_todo(),<br /> we can not assume the netns of each device is still alive.<br /> <br /> Make sure the device is not in NETREG_UNREGISTERED state,<br /> and add an ASSERT_RTNL() before the call to<br /> __dev_get_by_index().<br /> <br /> We might move this ASSERT_RTNL() in __dev_get_by_index()<br /> in the future.<br /> <br /> [1]<br /> <br /> BUG: KASAN: slab-use-after-free in __dev_get_by_index+0x5d/0x110 net/core/dev.c:852<br /> Read of size 8 at addr ffff888043eba1b0 by task syz.0.0/5339<br /> <br /> CPU: 0 UID: 0 PID: 5339 Comm: syz.0.0 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:489<br /> kasan_report+0x143/0x180 mm/kasan/report.c:602<br /> __dev_get_by_index+0x5d/0x110 net/core/dev.c:852<br /> default_operstate net/core/link_watch.c:51 [inline]<br /> rfc2863_policy+0x224/0x300 net/core/link_watch.c:67<br /> linkwatch_do_dev+0x3e/0x170 net/core/link_watch.c:170<br /> netdev_run_todo+0x461/0x1000 net/core/dev.c:10894<br /> rtnl_unlock net/core/rtnetlink.c:152 [inline]<br /> rtnl_net_unlock include/linux/rtnetlink.h:133 [inline]<br /> rtnl_dellink+0x760/0x8d0 net/core/rtnetlink.c:3520<br /> rtnetlink_rcv_msg+0x791/0xcf0 net/core/rtnetlink.c:6911<br /> netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2541<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]<br /> netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1347<br /> netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1891<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:726<br /> ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583<br /> ___sys_sendmsg net/socket.c:2637 [inline]<br /> __sys_sendmsg+0x269/0x350 net/socket.c:2669<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f2a3cb80809<br /> 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 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f2a3d9cd058 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f2a3cd45fa0 RCX: 00007f2a3cb80809<br /> RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000008<br /> RBP: 00007f2a3cbf393e R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f2a3cd45fa0 R15: 00007ffd03bc65c8<br /> <br /> <br /> Allocated by task 5339:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4314<br /> kmalloc_noprof include/linux/slab.h:901 [inline]<br /> kmalloc_array_noprof include/linux/slab.h:945 [inline]<br /> netdev_create_hash net/core/dev.c:11870 [inline]<br /> netdev_init+0x10c/0x250 net/core/dev.c:11890<br /> ops_init+0x31e/0x590 net/core/net_namespace.c:138<br /> setup_net+0x287/0x9e0 net/core/net_namespace.c:362<br /> copy_net_ns+0x33f/0x570 net/core/net_namespace.c:500<br /> create_new_namespaces+0x425/0x7b0 kernel/nsproxy.c:110<br /> unshare_nsproxy_namespaces+0x124/0x180 kernel/nsproxy.c:228<br /> ksys_unshare+0x57d/0xa70 kernel/fork.c:3314<br /> __do_sys_unshare kernel/fork.c:3385 [inline]<br /> __se_sys_unshare kernel/fork.c:3383 [inline]<br /> __x64_sys_unshare+0x38/0x40 kernel/fork.c:3383<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x8<br /> ---truncated---