Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix general protection fault in __smc_diag_dump<br /> <br /> The syzbot report a crash:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xfbd5a5d5a0000003: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: maybe wild-memory-access in range [0xdead4ead00000018-0xdead4ead0000001f]<br /> CPU: 1 UID: 0 PID: 6949 Comm: syz.0.335 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025<br /> RIP: 0010:smc_diag_msg_common_fill net/smc/smc_diag.c:44 [inline]<br /> RIP: 0010:__smc_diag_dump.constprop.0+0x3ca/0x2550 net/smc/smc_diag.c:89<br /> Call Trace:<br /> <br /> smc_diag_dump_proto+0x26d/0x420 net/smc/smc_diag.c:217<br /> smc_diag_dump+0x27/0x90 net/smc/smc_diag.c:234<br /> netlink_dump+0x539/0xd30 net/netlink/af_netlink.c:2327<br /> __netlink_dump_start+0x6d6/0x990 net/netlink/af_netlink.c:2442<br /> netlink_dump_start include/linux/netlink.h:341 [inline]<br /> smc_diag_handler_dump+0x1f9/0x240 net/smc/smc_diag.c:251<br /> __sock_diag_cmd net/core/sock_diag.c:249 [inline]<br /> sock_diag_rcv_msg+0x438/0x790 net/core/sock_diag.c:285<br /> netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]<br /> netlink_unicast+0x5a7/0x870 net/netlink/af_netlink.c:1346<br /> netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> __sock_sendmsg net/socket.c:729 [inline]<br /> ____sys_sendmsg+0xa95/0xc70 net/socket.c:2614<br /> ___sys_sendmsg+0x134/0x1d0 net/socket.c:2668<br /> __sys_sendmsg+0x16d/0x220 net/socket.c:2700<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x4e0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> The process like this:<br /> <br /> (CPU1) | (CPU2)<br /> ---------------------------------|-------------------------------<br /> inet_create() |<br /> // init clcsock to NULL |<br /> sk = sk_alloc() |<br /> |<br /> // unexpectedly change clcsock |<br /> inet_init_csk_locks() |<br /> |<br /> // add sk to hash table |<br /> smc_inet_init_sock() |<br /> smc_sk_init() |<br /> smc_hash_sk() |<br /> | // traverse the hash table<br /> | smc_diag_dump_proto<br /> | __smc_diag_dump()<br /> | // visit wrong clcsock<br /> | smc_diag_msg_common_fill()<br /> // alloc clcsock |<br /> smc_create_clcsk |<br /> sock_create_kern |<br /> <br /> With CONFIG_DEBUG_LOCK_ALLOC=y, the smc-&gt;clcsock is unexpectedly changed<br /> in inet_init_csk_locks(). The INET_PROTOSW_ICSK flag is no need by smc,<br /> just remove it.<br /> <br /> After removing the INET_PROTOSW_ICSK flag, this patch alse revert<br /> commit 6fd27ea183c2 ("net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC")<br /> to avoid casting smc_sock to inet_connection_sock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: stacktrace: Disable KASAN checks for non-current tasks<br /> <br /> Unwinding the stack of a task other than current, KASAN would report<br /> "BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460"<br /> <br /> There is a same issue on x86 and has been resolved by the commit<br /> 84936118bdf3 ("x86/unwind: Disable KASAN checks for non-current tasks")<br /> The solution could be applied to RISC-V too.<br /> <br /> This patch also can solve the issue:<br /> https://seclists.org/oss-sec/2025/q4/23<br /> <br /> [pjw@kernel.org: clean up checkpatch issues]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel: Fix KASAN global-out-of-bounds warning<br /> <br /> When running "perf mem record" command on CWF, the below KASAN<br /> global-out-of-bounds warning is seen.<br /> <br /> ==================================================================<br /> BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0<br /> Read of size 4 at addr ffffffffb721d000 by task dtlb/9850<br /> <br /> Call Trace:<br /> <br /> kasan_report+0xb8/0xf0<br /> cmt_latency_data+0x176/0x1b0<br /> setup_arch_pebs_sample_data+0xf49/0x2560<br /> intel_pmu_drain_arch_pebs+0x577/0xb00<br /> handle_pmi_common+0x6c4/0xc80<br /> <br /> The issue is caused by below code in __grt_latency_data(). The code<br /> tries to access x86_hybrid_pmu structure which doesn&amp;#39;t exist on<br /> non-hybrid platform like CWF.<br /> <br /> WARN_ON_ONCE(hybrid_pmu(event-&gt;pmu)-&gt;pmu_type == hybrid_big)<br /> <br /> So add is_hybrid() check before calling this WARN_ON_ONCE to fix the<br /> global-out-of-bounds access issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sysfb: Do not dereference NULL pointer in plane reset<br /> <br /> The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not<br /> deref that pointer, but forward NULL to the other plane-reset helpers.<br /> Clears plane-&gt;state to NULL.<br /> <br /> v2:<br /> - fix typo in commit description (Javier)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()<br /> <br /> Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()<br /> which causes the code to proceed with NULL clock pointers. The current<br /> logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both<br /> valid pointers and NULL, leading to potential NULL pointer dereference<br /> in clk_get_rate().<br /> <br /> Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:<br /> "The error code within @ptr if it is an error pointer; 0 otherwise."<br /> <br /> This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL<br /> pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)<br /> when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be<br /> called when of_clk_get() returns NULL.<br /> <br /> Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid<br /> pointers, preventing potential NULL pointer dereference in clk_get_rate().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: enetc: fix the deadlock of enetc_mdio_lock<br /> <br /> After applying the workaround for err050089, the LS1028A platform<br /> experiences RCU stalls on RT kernel. This issue is caused by the<br /> recursive acquisition of the read lock enetc_mdio_lock. Here list some<br /> of the call stacks identified under the enetc_poll path that may lead to<br /> a deadlock:<br /> <br /> enetc_poll<br /> -&gt; enetc_lock_mdio<br /> -&gt; enetc_clean_rx_ring OR napi_complete_done<br /> -&gt; napi_gro_receive<br /> -&gt; enetc_start_xmit<br /> -&gt; enetc_lock_mdio<br /> -&gt; enetc_map_tx_buffs<br /> -&gt; enetc_unlock_mdio<br /> -&gt; enetc_unlock_mdio<br /> <br /> After enetc_poll acquires the read lock, a higher-priority writer attempts<br /> to acquire the lock, causing preemption. The writer detects that a<br /> read lock is already held and is scheduled out. However, readers under<br /> enetc_poll cannot acquire the read lock again because a writer is already<br /> waiting, leading to a thread hang.<br /> <br /> Currently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent<br /> recursive lock acquisition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slab: Avoid race on slab-&gt;obj_exts in alloc_slab_obj_exts<br /> <br /> If two competing threads enter alloc_slab_obj_exts() and one of them<br /> fails to allocate the object extension vector, it might override the<br /> valid slab-&gt;obj_exts allocated by the other thread with<br /> OBJEXTS_ALLOC_FAIL. This will cause the thread that lost this race and<br /> expects a valid pointer to dereference a NULL pointer later on.<br /> <br /> Update slab-&gt;obj_exts atomically using cmpxchg() to avoid<br /> slab-&gt;obj_exts overrides by racing threads.<br /> <br /> Thanks for Vlastimil and Suren&amp;#39;s help with debugging.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: validate record offset in hfsplus_bmap_alloc<br /> <br /> hfsplus_bmap_alloc can trigger a crash if a<br /> record offset or length is larger than node_size<br /> <br /> [ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0<br /> [ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183<br /> [ 15.265949]<br /> [ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary)<br /> [ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 15.266167] Call Trace:<br /> [ 15.266168] <br /> [ 15.266169] dump_stack_lvl+0x53/0x70<br /> [ 15.266173] print_report+0xd0/0x660<br /> [ 15.266181] kasan_report+0xce/0x100<br /> [ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0<br /> [ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0<br /> [ 15.266217] hfsplus_brec_insert+0x870/0xb00<br /> [ 15.266222] __hfsplus_ext_write_extent+0x428/0x570<br /> [ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910<br /> [ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200<br /> [ 15.266233] hfsplus_file_extend+0x5a7/0x1000<br /> [ 15.266237] hfsplus_get_block+0x12b/0x8c0<br /> [ 15.266238] __block_write_begin_int+0x36b/0x12c0<br /> [ 15.266251] block_write_begin+0x77/0x110<br /> [ 15.266252] cont_write_begin+0x428/0x720<br /> [ 15.266259] hfsplus_write_begin+0x51/0x100<br /> [ 15.266262] cont_write_begin+0x272/0x720<br /> [ 15.266270] hfsplus_write_begin+0x51/0x100<br /> [ 15.266274] generic_perform_write+0x321/0x750<br /> [ 15.266285] generic_file_write_iter+0xc3/0x310<br /> [ 15.266289] __kernel_write_iter+0x2fd/0x800<br /> [ 15.266296] dump_user_range+0x2ea/0x910<br /> [ 15.266301] elf_core_dump+0x2a94/0x2ed0<br /> [ 15.266320] vfs_coredump+0x1d85/0x45e0<br /> [ 15.266349] get_signal+0x12e3/0x1990<br /> [ 15.266357] arch_do_signal_or_restart+0x89/0x580<br /> [ 15.266362] irqentry_exit_to_user_mode+0xab/0x110<br /> [ 15.266364] asm_exc_page_fault+0x26/0x30<br /> [ 15.266366] RIP: 0033:0x41bd35<br /> [ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f<br /> [ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283<br /> [ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100<br /> [ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000<br /> [ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> [ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000<br /> [ 15.266376] <br /> <br /> When calling hfsplus_bmap_alloc to allocate a free node, this function<br /> first retrieves the bitmap from header node and map node using node-&gt;page<br /> together with the offset and length from hfs_brec_lenoff<br /> <br /> ```<br /> len = hfs_brec_lenoff(node, 2, &amp;off16);<br /> off = off16;<br /> <br /> off += node-&gt;page_offset;<br /> pagep = node-&gt;page + (off &gt;&gt; PAGE_SHIFT);<br /> data = kmap_local_page(*pagep);<br /> ```<br /> <br /> However, if the retrieved offset or length is invalid(i.e. exceeds<br /> node_size), the code may end up accessing pages outside the allocated<br /> range for this node.<br /> <br /> This patch adds proper validation of both offset and length before use,<br /> preventing out-of-bounds page access. Move is_bnode_offset_valid and<br /> check_and_correct_requested_length to hfsplus_fs.h, as they may be<br /> required by other functions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ<br /> <br /> XDP programs can change the layout of an xdp_buff through<br /> bpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver<br /> cannot assume the size of the linear data area nor fragments. Fix the<br /> bug in mlx5 by generating skb according to xdp_buff after XDP programs<br /> run.<br /> <br /> Currently, when handling multi-buf XDP, the mlx5 driver assumes the<br /> layout of an xdp_buff to be unchanged. That is, the linear data area<br /> continues to be empty and fragments remain the same. This may cause<br /> the driver to generate erroneous skb or triggering a kernel<br /> warning. When an XDP program added linear data through<br /> bpf_xdp_adjust_head(), the linear data will be ignored as<br /> mlx5e_build_linear_skb() builds an skb without linear data and then<br /> pull data from fragments to fill the linear data area. When an XDP<br /> program has shrunk the non-linear data through bpf_xdp_adjust_tail(),<br /> the delta passed to __pskb_pull_tail() may exceed the actual nonlinear<br /> data size and trigger the BUG_ON in it.<br /> <br /> To fix the issue, first record the original number of fragments. If the<br /> number of fragments changes after the XDP program runs, rewind the end<br /> fragment pointer by the difference and recalculate the truesize. Then,<br /> build the skb with the linear data area matching the xdp_buff. Finally,<br /> only pull data in if there is non-linear data and fill the linear part<br /> up to 256 bytes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()<br /> <br /> The syzbot reported issue in hfsplus_delete_cat():<br /> <br /> [ 70.682285][ T9333] =====================================================<br /> [ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220<br /> [ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220<br /> [ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0<br /> [ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310<br /> [ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810<br /> [ 70.685447][ T9333] do_rmdir+0x964/0xea0<br /> [ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0<br /> [ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0<br /> [ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0<br /> [ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 70.687646][ T9333]<br /> [ 70.687856][ T9333] Uninit was stored to memory at:<br /> [ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0<br /> [ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800<br /> [ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600<br /> [ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70<br /> [ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0<br /> [ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30<br /> [ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0<br /> [ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0<br /> [ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0<br /> [ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 70.692773][ T9333]<br /> [ 70.692990][ T9333] Uninit was stored to memory at:<br /> [ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0<br /> [ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800<br /> [ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700<br /> [ 70.694911][ T9333] mount_bdev+0x37b/0x530<br /> [ 70.695320][ T9333] hfsplus_mount+0x4d/0x60<br /> [ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0<br /> [ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0<br /> [ 70.696588][ T9333] do_new_mount+0x73e/0x1630<br /> [ 70.697013][ T9333] path_mount+0x6e3/0x1eb0<br /> [ 70.697425][ T9333] __se_sys_mount+0x733/0x830<br /> [ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150<br /> [ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0<br /> [ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0<br /> [ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 70.699730][ T9333]<br /> [ 70.699946][ T9333] Uninit was created at:<br /> [ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60<br /> [ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0<br /> [ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0<br /> [ 70.701774][ T9333] allocate_slab+0x30e/0x1390<br /> [ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0<br /> [ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20<br /> [ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0<br /> [ 70.703598][ T9333] alloc_inode+0x82/0x490<br /> [ 70.703984][ T9333] iget_locked+0x22e/0x1320<br /> [ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0<br /> [ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0<br /> [ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700<br /> [ 70.705776][ T9333] mount_bdev+0x37b/0x530<br /> [ 70.706171][ T9333] hfsplus_mount+0x4d/0x60<br /> [ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0<br /> [ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0<br /> [ 70.707444][ T9333] do_new_mount+0x73e/0x1630<br /> [ 70.707865][ T9333] path_mount+0x6e3/0x1eb0<br /> [ 70.708270][ T9333] __se_sys_mount+0x733/0x830<br /> [ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150<br /> [ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0<br /> [ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0<br /> [ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 70.710611][ T9333]<br /> [ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17<br /> [ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 70.712490][ T9333] =====================================================<br /> [ 70.713085][ T9333] Disabling lock debugging due to kernel taint<br /> [ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ...<br /> [ 70.714159][ T9333] <br /> ---truncated---

WaveView client allows users to execute restricted set of predefined commands and scripts on the connected WaveStore Server. A malicious attacker with high-privileges is able to read or delete files, with the permissions of dvr user, on the server using path traversal in the alog script.<br /> <br /> This issue was fixed in version 6.44.44

WaveView client allows users to execute restricted set of predefined commands and scripts on the connected WaveStore Server. A malicious attacker with high-privileges is able to read or delete any file on the server using path traversal in the ilog script. This script is being run with root privileges.<br /> <br /> This issue was fixed in version 6.44.44