Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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 /> 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg<br /> <br /> The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging<br /> tosend bytes, which is either msg-&gt;sg.size or a smaller value apply_bytes.<br /> <br /> Potential problems with this strategy are as follows:<br /> <br /> - If the actual sent bytes are smaller than tosend, we need to charge some<br /> bytes back, as in line 487, which is okay but seems not clean.<br /> <br /> - When tosend is set to apply_bytes, as in line 417, and (ret sg.size - apply_bytes) bytes.<br /> <br /> [...]<br /> 415 tosend = msg-&gt;sg.size;<br /> 416 if (psock-&gt;apply_bytes &amp;&amp; psock-&gt;apply_bytes apply_bytes;<br /> [...]<br /> 443 sk_msg_return(sk, msg, tosend);<br /> 444 release_sock(sk);<br /> 446 origsize = msg-&gt;sg.size;<br /> 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,<br /> 448 msg, tosend, flags);<br /> 449 sent = origsize - msg-&gt;sg.size;<br /> [...]<br /> 454 lock_sock(sk);<br /> 455 if (unlikely(ret

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: sg: Fix slab-use-after-free read in sg_release()<br /> <br /> Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:<br /> <br /> BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30<br /> kernel/locking/lockdep.c:5838<br /> __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912<br /> sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407<br /> <br /> In sg_release(), the function kref_put(&amp;sfp-&gt;f_ref, sg_remove_sfp) is<br /> called before releasing the open_rel_lock mutex. The kref_put() call may<br /> decrement the reference count of sfp to zero, triggering its cleanup<br /> through sg_remove_sfp(). This cleanup includes scheduling deferred work<br /> via sg_remove_sfp_usercontext(), which ultimately frees sfp.<br /> <br /> After kref_put(), sg_release() continues to unlock open_rel_lock and may<br /> reference sfp or sdp. If sfp has already been freed, this results in a<br /> slab-use-after-free error.<br /> <br /> Move the kref_put(&amp;sfp-&gt;f_ref, sg_remove_sfp) call after unlocking the<br /> open_rel_lock mutex. This ensures:<br /> <br /> - No references to sfp or sdp occur after the reference count is<br /> decremented.<br /> <br /> - Cleanup functions such as sg_remove_sfp() and<br /> sg_remove_sfp_usercontext() can safely execute without impacting the<br /> mutex handling in sg_release().<br /> <br /> The fix has been tested and validated by syzbot. This patch closes the<br /> bug reported at the following syzkaller link and ensures proper<br /> sequencing of resource cleanup and mutex operations, eliminating the<br /> risk of use-after-free errors in sg_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/dp_mst: Fix MST sideband message body length check<br /> <br /> Fix the MST sideband message body length check, which must be at least 1<br /> byte accounting for the message body CRC (aka message data CRC) at the<br /> end of the message.<br /> <br /> This fixes a case where an MST branch device returns a header with a<br /> correct header CRC (indicating a correctly received body length), with<br /> the body length being incorrectly set to 0. This will later lead to a<br /> memory corruption in drm_dp_sideband_append_payload() and the following<br /> errors in dmesg:<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25<br /> index -1 is out of range for type &amp;#39;u8 [48]&amp;#39;<br /> Call Trace:<br /> drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper]<br /> drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]<br /> drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]<br /> <br /> memcpy: detected field-spanning write (size 18446744073709551615) of single field "&amp;msg-&gt;msg[msg-&gt;curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256)<br /> Call Trace:<br /> drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper]<br /> drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]<br /> drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: sysfs: Prevent div by zero<br /> <br /> Prevent a division by 0 when monitoring is not enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: fix OOB devmap writes when deleting elements<br /> <br /> Jordy reported issue against XSKMAP which also applies to DEVMAP - the<br /> index used for accessing map entry, due to being a signed integer,<br /> causes the OOB writes. Fix is simple as changing the type from int to<br /> u32, however, when compared to XSKMAP case, one more thing needs to be<br /> addressed.<br /> <br /> When map is released from system via dev_map_free(), we iterate through<br /> all of the entries and an iterator variable is also an int, which<br /> implies OOB accesses. Again, change it to be u32.<br /> <br /> Example splat below:<br /> <br /> [ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000<br /> [ 160.731662] #PF: supervisor read access in kernel mode<br /> [ 160.736876] #PF: error_code(0x0000) - not-present page<br /> [ 160.742095] PGD 0 P4D 0<br /> [ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP<br /> [ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487<br /> [ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019<br /> [ 160.767642] Workqueue: events_unbound bpf_map_free_deferred<br /> [ 160.773308] RIP: 0010:dev_map_free+0x77/0x170<br /> [ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff<br /> [ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202<br /> [ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024<br /> [ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000<br /> [ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001<br /> [ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122<br /> [ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000<br /> [ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000<br /> [ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0<br /> [ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 160.874092] PKRU: 55555554<br /> [ 160.876847] Call Trace:<br /> [ 160.879338] <br /> [ 160.881477] ? __die+0x20/0x60<br /> [ 160.884586] ? page_fault_oops+0x15a/0x450<br /> [ 160.888746] ? search_extable+0x22/0x30<br /> [ 160.892647] ? search_bpf_extables+0x5f/0x80<br /> [ 160.896988] ? exc_page_fault+0xa9/0x140<br /> [ 160.900973] ? asm_exc_page_fault+0x22/0x30<br /> [ 160.905232] ? dev_map_free+0x77/0x170<br /> [ 160.909043] ? dev_map_free+0x58/0x170<br /> [ 160.912857] bpf_map_free_deferred+0x51/0x90<br /> [ 160.917196] process_one_work+0x142/0x370<br /> [ 160.921272] worker_thread+0x29e/0x3b0<br /> [ 160.925082] ? rescuer_thread+0x4b0/0x4b0<br /> [ 160.929157] kthread+0xd4/0x110<br /> [ 160.932355] ? kthread_park+0x80/0x80<br /> [ 160.936079] ret_from_fork+0x2d/0x50<br /> [ 160.943396] ? kthread_park+0x80/0x80<br /> [ 160.950803] ret_from_fork_asm+0x11/0x20<br /> [ 160.958482]