Vulnerabilities

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 /> 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 /> net/smc: fix LGR and link use-after-free issue<br /> <br /> We encountered a LGR/link use-after-free issue, which manifested as<br /> the LGR/link refcnt reaching 0 early and entering the clear process,<br /> making resource access unsafe.<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140<br /> Workqueue: events smc_lgr_terminate_work [smc]<br /> Call trace:<br /> refcount_warn_saturate+0x9c/0x140<br /> __smc_lgr_terminate.part.45+0x2a8/0x370 [smc]<br /> smc_lgr_terminate_work+0x28/0x30 [smc]<br /> process_one_work+0x1b8/0x420<br /> worker_thread+0x158/0x510<br /> kthread+0x114/0x118<br /> <br /> or<br /> <br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140<br /> Workqueue: smc_hs_wq smc_listen_work [smc]<br /> Call trace:<br /> refcount_warn_saturate+0xf0/0x140<br /> smcr_link_put+0x1cc/0x1d8 [smc]<br /> smc_conn_free+0x110/0x1b0 [smc]<br /> smc_conn_abort+0x50/0x60 [smc]<br /> smc_listen_find_device+0x75c/0x790 [smc]<br /> smc_listen_work+0x368/0x8a0 [smc]<br /> process_one_work+0x1b8/0x420<br /> worker_thread+0x158/0x510<br /> kthread+0x114/0x118<br /> <br /> It is caused by repeated release of LGR/link refcnt. One suspect is that<br /> smc_conn_free() is called repeatedly because some smc_conn_free() from<br /> server listening path are not protected by sock lock.<br /> <br /> e.g.<br /> <br /> Calls under socklock | smc_listen_work<br /> -------------------------------------------------------<br /> lock_sock(sk) | smc_conn_abort<br /> smc_conn_free | \- smc_conn_free<br /> \- smcr_link_put | \- smcr_link_put (duplicated)<br /> release_sock(sk)<br /> <br /> So here add sock lock protection in smc_listen_work() path, making it<br /> exclusive with other connection operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: Fix use-after-free of kernel socket in cleanup_bearer().<br /> <br /> syzkaller reported a use-after-free of UDP kernel socket<br /> in cleanup_bearer() without repro. [0][1]<br /> <br /> When bearer_disable() calls tipc_udp_disable(), cleanup<br /> of the UDP kernel socket is deferred by work calling<br /> cleanup_bearer().<br /> <br /> tipc_exit_net() waits for such works to finish by checking<br /> tipc_net(net)-&gt;wq_count. However, the work decrements the<br /> count too early before releasing the kernel socket,<br /> unblocking cleanup_net() and resulting in use-after-free.<br /> <br /> Let&amp;#39;s move the decrement after releasing the socket in<br /> cleanup_bearer().<br /> <br /> [0]:<br /> ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at<br /> sk_alloc+0x438/0x608<br /> inet_create+0x4c8/0xcb0<br /> __sock_create+0x350/0x6b8<br /> sock_create_kern+0x58/0x78<br /> udp_sock_create4+0x68/0x398<br /> udp_sock_create+0x88/0xc8<br /> tipc_udp_enable+0x5e8/0x848<br /> __tipc_nl_bearer_enable+0x84c/0xed8<br /> tipc_nl_bearer_enable+0x38/0x60<br /> genl_family_rcv_msg_doit+0x170/0x248<br /> genl_rcv_msg+0x400/0x5b0<br /> netlink_rcv_skb+0x1dc/0x398<br /> genl_rcv+0x44/0x68<br /> netlink_unicast+0x678/0x8b0<br /> netlink_sendmsg+0x5e4/0x898<br /> ____sys_sendmsg+0x500/0x830<br /> <br /> [1]:<br /> BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]<br /> BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979<br /> udp_hashslot include/net/udp.h:85 [inline]<br /> udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979<br /> sk_common_release+0xaf/0x3f0 net/core/sock.c:3820<br /> inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437<br /> inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489<br /> __sock_release net/socket.c:658 [inline]<br /> sock_release+0xa0/0x210 net/socket.c:686<br /> cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310<br /> worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391<br /> kthread+0x531/0x6b0 kernel/kthread.c:389<br /> ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244<br /> <br /> Uninit was created at:<br /> slab_free_hook mm/slub.c:2269 [inline]<br /> slab_free mm/slub.c:4580 [inline]<br /> kmem_cache_free+0x207/0xc40 mm/slub.c:4682<br /> net_free net/core/net_namespace.c:454 [inline]<br /> cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310<br /> worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391<br /> kthread+0x531/0x6b0 kernel/kthread.c:389<br /> ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244<br /> <br /> CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> Workqueue: events cleanup_bearer

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: fix the memleak while create new ctrl failed<br /> <br /> Now while we create new ctrl failed, we have not free the<br /> tagset occupied by admin_q, here try to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: dev: can_set_termination(): allow sleeping GPIOs<br /> <br /> In commit 6e86a1543c37 ("can: dev: provide optional GPIO based<br /> termination support") GPIO based termination support was added.<br /> <br /> For no particular reason that patch uses gpiod_set_value() to set the<br /> GPIO. This leads to the following warning, if the systems uses a<br /> sleeping GPIO, i.e. behind an I2C port expander:<br /> <br /> | WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c<br /> | CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c<br /> <br /> Replace gpiod_set_value() by gpiod_set_value_cansleep() to allow the<br /> use of sleeping GPIOs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write<br /> <br /> An offset from client could be a negative value, It could allows<br /> to write data outside the bounds of the allocated buffer.<br /> Note that this issue is coming when setting<br /> &amp;#39;vfs objects = streams_xattr parameter&amp;#39; in ksmbd.conf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read<br /> <br /> An offset from client could be a negative value, It could lead<br /> to an out-of-bounds read from the stream_buf.<br /> Note that this issue is coming when setting<br /> &amp;#39;vfs objects = streams_xattr parameter&amp;#39; in ksmbd.conf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Add architecture specific huge_pte_clear()<br /> <br /> When executing mm selftests run_vmtests.sh, there is such an error:<br /> <br /> BUG: Bad page state in process uffd-unit-tests pfn:00000<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0<br /> flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff)<br /> raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set<br /> Modules linked in: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat<br /> virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse<br /> nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs<br /> CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022<br /> Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000<br /> 900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8<br /> 900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001<br /> 0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000<br /> 0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000<br /> 000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940<br /> 0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000<br /> 0000000000000000 90000000028f8940 ffff800000000000 0000000000000000<br /> 0000000000000000 0000000000000000 9000000000223a94 000000012001839c<br /> 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d<br /> ...<br /> Call Trace:<br /> [] show_stack+0x5c/0x180<br /> [] dump_stack_lvl+0x6c/0xa0<br /> [] bad_page+0x1a0/0x1f0<br /> [] free_unref_folios+0xbf0/0xd20<br /> [] folios_put_refs+0x1a4/0x2b8<br /> [] free_pages_and_swap_cache+0x164/0x260<br /> [] tlb_batch_pages_flush+0xa8/0x1c0<br /> [] tlb_finish_mmu+0xa8/0x218<br /> [] exit_mmap+0x1a0/0x360<br /> [] __mmput+0x78/0x200<br /> [] do_exit+0x43c/0xde8<br /> [] do_group_exit+0x68/0x110<br /> [] sys_exit_group+0x1c/0x20<br /> [] do_syscall+0x94/0x130<br /> [] handle_syscall+0xb8/0x158<br /> Disabling lock debugging due to kernel taint<br /> BUG: non-zero pgtables_bytes on freeing mm: -16384<br /> <br /> On LoongArch system, invalid huge pte entry should be invalid_pte_table<br /> or a single _PAGE_HUGE bit rather than a zero value. And it should be<br /> the same with invalid pmd entry, since pmd_none() is called by function<br /> free_pgd_range() and pmd_none() return 0 by huge_pte_clear(). So single<br /> _PAGE_HUGE bit is also treated as a valid pte table and free_pte_range()<br /> will be called in free_pmd_range().<br /> <br /> free_pmd_range()<br /> pmd = pmd_offset(pud, addr);<br /> do {<br /> next = pmd_addr_end(addr, end);<br /> if (pmd_none_or_clear_bad(pmd))<br /> continue;<br /> free_pte_range(tlb, pmd, addr);<br /> } while (pmd++, addr = next, addr != end);<br /> <br /> Here invalid_pte_table is used for both invalid huge pte entry and<br /> pmd entry.