Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: wacom: fix when get product name maybe null pointer<br /> <br /> Due to incorrect dev-&gt;product reporting by certain devices, null<br /> pointer dereferences occur when dev-&gt;product is empty, leading to<br /> potential system crashes.<br /> <br /> This issue was found on EXCELSIOR DL37-D05 device with<br /> Loongson-LS3A6000-7A2000-DL37 motherboard.<br /> <br /> Kernel logs:<br /> [ 56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci<br /> [ 56.671638] usb 4-3: string descriptor 0 read error: -22<br /> [ 56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07<br /> [ 56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br /> [ 56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0<br /> [ 56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80<br /> [ 56.697732] Oops[#1]:<br /> [ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015<br /> [ 56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024<br /> [ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0<br /> [ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000<br /> [ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000<br /> [ 56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005<br /> [ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000<br /> [ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028<br /> [ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000<br /> [ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000<br /> [ 56.697753] ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom]<br /> [ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120<br /> [ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> [ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE)<br /> [ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)<br /> [ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)<br /> [ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)<br /> [ 56.697835] BADV: 0000000000000000<br /> [ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)<br /> [ 56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit<br /> [ 56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3)<br /> [ 56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000<br /> [ 56.697896] 0000000000000000 00000011fffffffd 0000000000000000 0000000000000000<br /> [ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0<br /> [ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c<br /> [ 56.697911] 90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440<br /> [ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0<br /> [ 56.697921] 0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c<br /> [ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000<br /> [ 56.697931] 90000001000bb8d0 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: free inode when ocfs2_get_init_inode() fails<br /> <br /> syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826<br /> ("ocfs2: Handle error from dquot_initialize()") forgot to call iput() when<br /> new_inode() succeeded and dquot_initialize() failed.