Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Check the TLS certificate fields in nfs_match_client()<br /> <br /> If the TLS security policy is of type RPC_XPRTSEC_TLS_X509, then the<br /> cert_serial and privkey_serial fields need to match as well since they<br /> define the client&amp;#39;s identity, as presented to the server.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTD<br /> <br /> On completion of i915_vma_pin_ww(), a synchronous variant of<br /> dma_fence_work_commit() is called. When pinning a VMA to GGTT address<br /> space on a Cherry View family processor, or on a Broxton generation SoC<br /> with VTD enabled, i.e., when stop_machine() is then called from<br /> intel_ggtt_bind_vma(), that can potentially lead to lock inversion among<br /> reservation_ww and cpu_hotplug locks.<br /> <br /> [86.861179] ======================================================<br /> [86.861193] WARNING: possible circular locking dependency detected<br /> [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U<br /> [86.861226] ------------------------------------------------------<br /> [86.861238] i915_module_loa/1432 is trying to acquire lock:<br /> [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50<br /> [86.861290]<br /> but task is already holding lock:<br /> [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915]<br /> [86.862233]<br /> which lock already depends on the new lock.<br /> [86.862251]<br /> the existing dependency chain (in reverse order) is:<br /> [86.862265]<br /> -&gt; #5 (reservation_ww_class_mutex){+.+.}-{3:3}:<br /> [86.862292] dma_resv_lockdep+0x19a/0x390<br /> [86.862315] do_one_initcall+0x60/0x3f0<br /> [86.862334] kernel_init_freeable+0x3cd/0x680<br /> [86.862353] kernel_init+0x1b/0x200<br /> [86.862369] ret_from_fork+0x47/0x70<br /> [86.862383] ret_from_fork_asm+0x1a/0x30<br /> [86.862399]<br /> -&gt; #4 (reservation_ww_class_acquire){+.+.}-{0:0}:<br /> [86.862425] dma_resv_lockdep+0x178/0x390<br /> [86.862440] do_one_initcall+0x60/0x3f0<br /> [86.862454] kernel_init_freeable+0x3cd/0x680<br /> [86.862470] kernel_init+0x1b/0x200<br /> [86.862482] ret_from_fork+0x47/0x70<br /> [86.862495] ret_from_fork_asm+0x1a/0x30<br /> [86.862509]<br /> -&gt; #3 (&amp;mm-&gt;mmap_lock){++++}-{3:3}:<br /> [86.862531] down_read_killable+0x46/0x1e0<br /> [86.862546] lock_mm_and_find_vma+0xa2/0x280<br /> [86.862561] do_user_addr_fault+0x266/0x8e0<br /> [86.862578] exc_page_fault+0x8a/0x2f0<br /> [86.862593] asm_exc_page_fault+0x27/0x30<br /> [86.862607] filldir64+0xeb/0x180<br /> [86.862620] kernfs_fop_readdir+0x118/0x480<br /> [86.862635] iterate_dir+0xcf/0x2b0<br /> [86.862648] __x64_sys_getdents64+0x84/0x140<br /> [86.862661] x64_sys_call+0x1058/0x2660<br /> [86.862675] do_syscall_64+0x91/0xe90<br /> [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [86.862703]<br /> -&gt; #2 (&amp;root-&gt;kernfs_rwsem){++++}-{3:3}:<br /> [86.862725] down_write+0x3e/0xf0<br /> [86.862738] kernfs_add_one+0x30/0x3c0<br /> [86.862751] kernfs_create_dir_ns+0x53/0xb0<br /> [86.862765] internal_create_group+0x134/0x4c0<br /> [86.862779] sysfs_create_group+0x13/0x20<br /> [86.862792] topology_add_dev+0x1d/0x30<br /> [86.862806] cpuhp_invoke_callback+0x4b5/0x850<br /> [86.862822] cpuhp_issue_call+0xbf/0x1f0<br /> [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320<br /> [86.862852] __cpuhp_setup_state+0xb0/0x220<br /> [86.862866] topology_sysfs_init+0x30/0x50<br /> [86.862879] do_one_initcall+0x60/0x3f0<br /> [86.862893] kernel_init_freeable+0x3cd/0x680<br /> [86.862908] kernel_init+0x1b/0x200<br /> [86.862921] ret_from_fork+0x47/0x70<br /> [86.862934] ret_from_fork_asm+0x1a/0x30<br /> [86.862947]<br /> -&gt; #1 (cpuhp_state_mutex){+.+.}-{3:3}:<br /> [86.862969] __mutex_lock+0xaa/0xed0<br /> [86.862982] mutex_lock_nested+0x1b/0x30<br /> [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320<br /> [86.863012] __cpuhp_setup_state+0xb0/0x220<br /> [86.863026] page_alloc_init_cpuhp+0x2d/0x60<br /> [86.863041] mm_core_init+0x22/0x2d0<br /> [86.863054] start_kernel+0x576/0xbd0<br /> [86.863068] x86_64_start_reservations+0x18/0x30<br /> [86.863084] x86_64_start_kernel+0xbf/0x110<br /> [86.863098] common_startup_64+0x13e/0x141<br /> [86.863114]<br /> -&gt; #0 (cpu_hotplug_lock){++++}-{0:0}:<br /> [86.863135] __lock_acquire+0x16<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: netpoll: fix incorrect refcount handling causing incorrect cleanup<br /> <br /> commit efa95b01da18 ("netpoll: fix use after free") incorrectly<br /> ignored the refcount and prematurely set dev-&gt;npinfo to NULL during<br /> netpoll cleanup, leading to improper behavior and memory leaks.<br /> <br /> Scenario causing lack of proper cleanup:<br /> <br /> 1) A netpoll is associated with a NIC (e.g., eth0) and netdev-&gt;npinfo is<br /> allocated, and refcnt = 1<br /> - Keep in mind that npinfo is shared among all netpoll instances. In<br /> this case, there is just one.<br /> <br /> 2) Another netpoll is also associated with the same NIC and<br /> npinfo-&gt;refcnt += 1.<br /> - Now dev-&gt;npinfo-&gt;refcnt = 2;<br /> - There is just one npinfo associated to the netdev.<br /> <br /> 3) When the first netpolls goes to clean up:<br /> - The first cleanup succeeds and clears np-&gt;dev-&gt;npinfo, ignoring<br /> refcnt.<br /> - It basically calls `RCU_INIT_POINTER(np-&gt;dev-&gt;npinfo, NULL);`<br /> - Set dev-&gt;npinfo = NULL, without proper cleanup<br /> - No -&gt;ndo_netpoll_cleanup() is either called<br /> <br /> 4) Now the second target tries to clean up<br /> - The second cleanup fails because np-&gt;dev-&gt;npinfo is already NULL.<br /> * In this case, ops-&gt;ndo_netpoll_cleanup() was never called, and<br /> the skb pool is not cleaned as well (for the second netpoll<br /> instance)<br /> - This leaks npinfo and skbpool skbs, which is clearly reported by<br /> kmemleak.<br /> <br /> Revert commit efa95b01da18 ("netpoll: fix use after free") and adds<br /> clarifying comments emphasizing that npinfo cleanup should only happen<br /> once the refcount reaches zero, ensuring stable and correct netpoll<br /> behavior.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: close accepted socket when per-IP limit rejects connection<br /> <br /> When the per-IP connection limit is exceeded in ksmbd_kthread_fn(),<br /> the code sets ret = -EAGAIN and continues the accept loop without<br /> closing the just-accepted socket. That leaks one socket per rejected<br /> attempt from a single IP and enables a trivial remote DoS.<br /> <br /> Release client_sk before continuing.<br /> <br /> This bug was found with ZeroPath.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> posix-timers: Plug potential memory leak in do_timer_create()<br /> <br /> When posix timer creation is set to allocate a given timer ID and the<br /> access to the user space value faults, the function terminates without<br /> freeing the already allocated posix timer structure.<br /> <br /> Move the allocation after the user space access to cure that.<br /> <br /> [ tglx: Massaged change log ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/cmd_net: fix wrong argument types for skb_queue_splice()<br /> <br /> If timestamp retriving needs to be retried and the local list of<br /> SKB&amp;#39;s already has entries, then it&amp;#39;s spliced back into the socket<br /> queue. However, the arguments for the splice helper are transposed,<br /> causing exactly the wrong direction of splicing into the on-stack<br /> list. Fix that up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot<br /> <br /> nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a<br /> kmemleak warning.<br /> <br /> Make sure this data is deallocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)<br /> <br /> According to UFS specifications, the power-off sequence for a UFS device<br /> includes:<br /> <br /> - Sending an SSU command with Power_Condition=3 and await a response.<br /> <br /> - Asserting RST_N low.<br /> <br /> - Turning off REF_CLK.<br /> <br /> - Turning off VCC.<br /> <br /> - Turning off VCCQ/VCCQ2.<br /> <br /> As part of ufs shutdown, after the SSU command completion, asserting<br /> hardware reset (HWRST) triggers the device firmware to wake up and<br /> execute its reset routine. This routine initializes hardware blocks and<br /> takes a few milliseconds to complete. During this time, the ICCQ draws a<br /> large current.<br /> <br /> This large ICCQ current may cause issues for the regulator which is<br /> supplying power to UFS, because the turn off request from UFS driver to<br /> the regulator framework will be immediately followed by low power<br /> mode(LPM) request by regulator framework. This is done by framework<br /> because UFS which is the only client is requesting for disable. So if<br /> the rail is still in the process of shutting down while ICCQ exceeds LPM<br /> current thresholds, and LPM mode is activated in hardware during this<br /> state, it may trigger an overcurrent protection (OCP) fault in the<br /> regulator.<br /> <br /> To prevent this, a 10ms delay is added after asserting HWRST. This<br /> allows the reset operation to complete while power rails remain active<br /> and in high-power mode.<br /> <br /> Currently there is no way for Host to query whether the reset is<br /> completed or not and hence this the delay is based on experiments with<br /> Qualcomm UFS controllers across multiple UFS vendors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtdchar: fix integer overflow in read/write ioctls<br /> <br /> The "req.start" and "req.len" variables are u64 values that come from the<br /> user at the start of the function. We mask away the high 32 bits of<br /> "req.len" so that&amp;#39;s capped at U32_MAX but the "req.start" variable can go<br /> up to U64_MAX which means that the addition can still integer overflow.<br /> <br /> Use check_add_overflow() to fix this bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: cadence: fix DMA device NULL pointer dereference<br /> <br /> The DMA device pointer `dma_dev` was being dereferenced before ensuring<br /> that `cdns_ctrl-&gt;dmac` is properly initialized.<br /> <br /> Move the assignment of `dma_dev` after successfully acquiring the DMA<br /> channel to ensure the pointer is valid before use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()<br /> <br /> If the allocation of tl_hba-&gt;sh fails in tcm_loop_driver_probe() and we<br /> attempt to dereference it in tcm_loop_tpg_address_show() we will get a<br /> segfault, see below for an example. So, check tl_hba-&gt;sh before<br /> dereferencing it.<br /> <br /> Unable to allocate struct scsi_host<br /> BUG: kernel NULL pointer dereference, address: 0000000000000194<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1<br /> Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024<br /> RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]<br /> ...<br /> Call Trace:<br /> <br /> configfs_read_iter+0x12d/0x1d0 [configfs]<br /> vfs_read+0x1b5/0x300<br /> ksys_read+0x6f/0xf0<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix gpu page fault after hibernation on PF passthrough<br /> <br /> On PF passthrough environment, after hibernate and then resume, coralgemm<br /> will cause gpu page fault.<br /> <br /> Mode1 reset happens during hibernate, but partition mode is not restored<br /> on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right<br /> after resume. When CP access the MQD BO, wrong stride size is used,<br /> this will cause out of bound access on the MQD BO, resulting page fault.<br /> <br /> The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called<br /> when resume from a hibernation.<br /> KFD resume is called separately during a reset recovery or resume from<br /> suspend sequence. Hence it&amp;#39;s not required to be called as part of<br /> partition switch.<br /> <br /> (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)