Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Do not validate SSPP when it is not ready<br /> <br /> Current code will validate current plane and previous plane to<br /> confirm they can share a SSPP with multi-rect mode. The SSPP<br /> is already allocated for previous plane, while current plane<br /> is not associated with any SSPP yet. Null pointer is referenced<br /> when validating the SSPP of current plane. Skip SSPP validation<br /> for current plane.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=0000000888ac3000<br /> [0000000000000020] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> Modules linked in:<br /> CPU: 4 UID: 0 PID: 1891 Comm: modetest Tainted: G S 6.15.0-rc2-g3ee3f6e1202e #335 PREEMPT<br /> Tainted: [S]=CPU_OUT_OF_SPEC<br /> Hardware name: SM8650 EV1 rev1 4slam 2et (DT)<br /> pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : dpu_plane_is_multirect_capable+0x68/0x90<br /> lr : dpu_assign_plane_resources+0x288/0x410<br /> sp : ffff800093dcb770<br /> x29: ffff800093dcb770 x28: 0000000000002000 x27: ffff000817c6c000<br /> x26: ffff000806b46368 x25: ffff0008013f6080 x24: ffff00080cbf4800<br /> x23: ffff000810842680 x22: ffff0008013f1080 x21: ffff00080cc86080<br /> x20: ffff000806b463b0 x19: ffff00080cbf5a00 x18: 00000000ffffffff<br /> x17: 707a5f657a696c61 x16: 0000000000000003 x15: 0000000000002200<br /> x14: 00000000ffffffff x13: 00aaaaaa00aaaaaa x12: 0000000000000000<br /> x11: ffff000817c6e2b8 x10: 0000000000000000 x9 : ffff80008106a950<br /> x8 : ffff00080cbf48f4 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 0000000000000000 x4 : 0000000000000438 x3 : 0000000000000438<br /> x2 : ffff800082e245e0 x1 : 0000000000000008 x0 : 0000000000000000<br /> Call trace:<br /> dpu_plane_is_multirect_capable+0x68/0x90 (P)<br /> dpu_crtc_atomic_check+0x5bc/0x650<br /> drm_atomic_helper_check_planes+0x13c/0x220<br /> drm_atomic_helper_check+0x58/0xb8<br /> msm_atomic_check+0xd8/0xf0<br /> drm_atomic_check_only+0x4a8/0x968<br /> drm_atomic_commit+0x50/0xd8<br /> drm_atomic_helper_update_plane+0x140/0x188<br /> __setplane_atomic+0xfc/0x148<br /> drm_mode_setplane+0x164/0x378<br /> drm_ioctl_kernel+0xc0/0x140<br /> drm_ioctl+0x20c/0x500<br /> __arm64_sys_ioctl+0xbc/0xf8<br /> invoke_syscall+0x50/0x120<br /> el0_svc_common.constprop.0+0x48/0xf8<br /> do_el0_svc+0x28/0x40<br /> el0_svc+0x30/0xd0<br /> el0t_64_sync_handler+0x144/0x168<br /> el0t_64_sync+0x198/0x1a0<br /> Code: b9402021 370fffc1 f9401441 3707ff81 (f94010a1)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/669224/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: start using dst_dev_rcu()<br /> <br /> Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.<br /> <br /> Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),<br /> ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: Add a upper bound on max_vclocks<br /> <br /> syzbot reported WARNING in max_vclocks_store.<br /> <br /> This occurs when the argument max is too large for kcalloc to handle.<br /> <br /> Extend the guard to guard against values that are too large for<br /> kcalloc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Disallow dirty tracking if incoherent page walk<br /> <br /> Dirty page tracking relies on the IOMMU atomically updating the dirty bit<br /> in the paging-structure entry. For this operation to succeed, the paging-<br /> structure memory must be coherent between the IOMMU and the CPU. In<br /> another word, if the iommu page walk is incoherent, dirty page tracking<br /> doesn&amp;#39;t work.<br /> <br /> The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:<br /> <br /> "Remapping hardware encountering the need to atomically update A/EA/D bits<br /> in a paging-structure entry that is not snooped will result in a non-<br /> recoverable fault."<br /> <br /> To prevent an IOMMU from being incorrectly configured for dirty page<br /> tracking when it is operating in an incoherent mode, mark SSADS as<br /> supported only when both ecap_slads and ecap_smpwc are supported.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: Fix incorrect handling for return value of devm_kzalloc<br /> <br /> The return value of devm_kzalloc could be an null pointer,<br /> use "!desc.pdata" to fix incorrect handling return value<br /> of devm_kzalloc.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: trbe: Return NULL pointer for allocation failures<br /> <br /> When the TRBE driver fails to allocate a buffer, it currently returns<br /> the error code "-ENOMEM". However, the caller etm_setup_aux() only<br /> checks for a NULL pointer, so it misses the error. As a result, the<br /> driver continues and eventually causes a kernel panic.<br /> <br /> Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() on<br /> allocation failures. This allows that the callers can properly handle<br /> the failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix race in do_task() when draining<br /> <br /> When do_task() exhausts its iteration budget (!ret), it sets the state<br /> to TASK_STATE_IDLE to reschedule, without a secondary check on the<br /> current task-&gt;state. This can overwrite the TASK_STATE_DRAINING state<br /> set by a concurrent call to rxe_cleanup_task() or rxe_disable_task().<br /> <br /> While state changes are protected by a spinlock, both rxe_cleanup_task()<br /> and rxe_disable_task() release the lock while waiting for the task to<br /> finish draining in the while(!is_done(task)) loop. The race occurs if<br /> do_task() hits its iteration limit and acquires the lock in this window.<br /> The cleanup logic may then proceed while the task incorrectly<br /> reschedules itself, leading to a potential use-after-free.<br /> <br /> This bug was introduced during the migration from tasklets to workqueues,<br /> where the special handling for the draining case was lost.<br /> <br /> Fix this by restoring the original pre-migration behavior. If the state is<br /> TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to<br /> force a new loop iteration. This allows the task to finish its work, so<br /> that a subsequent iteration can reach the switch statement and correctly<br /> transition the state to TASK_STATE_DRAINED, stopping the task as intended.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: hisilicon/qm - set NULL to qm-&gt;debug.qm_diff_regs<br /> <br /> When the initialization of qm-&gt;debug.acc_diff_reg fails,<br /> the probe process does not exit. However, after qm-&gt;debug.qm_diff_regs is<br /> freed, it is not set to NULL. This can lead to a double free when the<br /> remove process attempts to free it again. Therefore, qm-&gt;debug.qm_diff_regs<br /> should be set to NULL after it is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: comp - Use same definition of context alloc and free ops<br /> <br /> In commit 42d9f6c77479 ("crypto: acomp - Move scomp stream allocation<br /> code into acomp"), the crypto_acomp_streams struct was made to rely on<br /> having the alloc_ctx and free_ctx operations defined in the same order<br /> as the scomp_alg struct. But in that same commit, the alloc_ctx and<br /> free_ctx members of scomp_alg may be randomized by structure layout<br /> randomization, since they are contained in a pure ops structure<br /> (containing only function pointers). If the pointers within scomp_alg<br /> are randomized, but those in crypto_acomp_streams are not, then<br /> the order may no longer match. This fixes the problem by removing the<br /> union from scomp_alg so that both crypto_acomp_streams and scomp_alg<br /> will share the same definition of alloc_ctx and free_ctx, ensuring<br /> they will always have the same layout.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smc: Fix use-after-free in __pnet_find_base_ndev().<br /> <br /> syzbot reported use-after-free of net_device in __pnet_find_base_ndev(),<br /> which was called during connect(). [0]<br /> <br /> smc_pnet_find_ism_resource() fetches sk_dst_get(sk)-&gt;dev and passes<br /> down to pnet_find_base_ndev(), where RTNL is held. Then, UAF happened<br /> at __pnet_find_base_ndev() when the dev is first used.<br /> <br /> This means dev had already been freed before acquiring RTNL in<br /> pnet_find_base_ndev().<br /> <br /> While dev is going away, dst-&gt;dev could be swapped with blackhole_netdev,<br /> and the dev&amp;#39;s refcnt by dst will be released.<br /> <br /> We must hold dev&amp;#39;s refcnt before calling smc_pnet_find_ism_resource().<br /> <br /> Also, smc_pnet_find_roce_resource() has the same problem.<br /> <br /> Let&amp;#39;s use __sk_dst_get() and dst_dev_rcu() in the two functions.<br /> <br /> [0]:<br /> BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926<br /> Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609<br /> <br /> CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xca/0x240 mm/kasan/report.c:482<br /> kasan_report+0x118/0x150 mm/kasan/report.c:595<br /> __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926<br /> pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline]<br /> smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline]<br /> smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154<br /> smc_find_ism_device net/smc/af_smc.c:1030 [inline]<br /> smc_find_proposal_devices net/smc/af_smc.c:1115 [inline]<br /> __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545<br /> smc_connect+0x877/0xd90 net/smc/af_smc.c:1715<br /> __sys_connect_file net/socket.c:2086 [inline]<br /> __sys_connect+0x313/0x440 net/socket.c:2105<br /> __do_sys_connect net/socket.c:2111 [inline]<br /> __se_sys_connect net/socket.c:2108 [inline]<br /> __x64_sys_connect+0x7a/0x90 net/socket.c:2108<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f47cbf8eba9<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:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002a<br /> RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9<br /> RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b<br /> RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8<br /> <br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac<br /> flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)<br /> raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000<br /> raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> page_owner tracks the page as freed<br /> page last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466<br /> set_page_owner include/linux/page_owner.h:32 [inline]<br /> post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851<br /> prep_new_page mm/page_alloc.c:1859 [inline]<br /> get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858<br /> __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148<br /> alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416<br /> ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317<br /> __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348<br /> __do_kmalloc_node mm/slub.c:4364 [inline]<br /> __kvmalloc_node<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: KVM: Write hgatp register with valid mode bits<br /> <br /> According to the RISC-V Privileged Architecture Spec, when MODE=Bare<br /> is selected,software must write zero to the remaining fields of hgatp.<br /> <br /> We have detected the valid mode supported by the HW before, So using a<br /> valid mode to detect how many vmid bits are supported.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Squashfs: fix uninit-value in squashfs_get_parent<br /> <br /> Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.<br /> <br /> This is caused by open_by_handle_at() being called with a file handle<br /> containing an invalid parent inode number. In particular the inode number<br /> is that of a symbolic link, rather than a directory.<br /> <br /> Squashfs_get_parent() gets called with that symbolic link inode, and<br /> accesses the parent member field.<br /> <br /> unsigned int parent_ino = squashfs_i(inode)-&gt;parent;<br /> <br /> Because non-directory inodes in Squashfs do not have a parent value, this<br /> is uninitialised, and this causes an uninitialised value access.<br /> <br /> The fix is to initialise parent with the invalid inode 0, which will cause<br /> an EINVAL error to be returned.<br /> <br /> Regular inodes used to share the parent field with the block_list_start<br /> field. This is removed in this commit to enable the parent field to<br /> contain the invalid inode number 0.