Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Perform lockless command completion in abort path<br /> <br /> While adding and removing the controller, the following call trace was<br /> observed:<br /> <br /> WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50<br /> CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1<br /> RIP: 0010:dma_free_attrs+0x33/0x50<br /> <br /> Call Trace:<br /> qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx]<br /> qla2x00_abort_srb+0x8e/0x250 [qla2xxx]<br /> ? ql_dbg+0x70/0x100 [qla2xxx]<br /> __qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx]<br /> qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx]<br /> qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx]<br /> qla2x00_remove_one+0x364/0x400 [qla2xxx]<br /> pci_device_remove+0x36/0xa0<br /> __device_release_driver+0x17a/0x230<br /> device_release_driver+0x24/0x30<br /> pci_stop_bus_device+0x68/0x90<br /> pci_stop_and_remove_bus_device_locked+0x16/0x30<br /> remove_store+0x75/0x90<br /> kernfs_fop_write_iter+0x11c/0x1b0<br /> new_sync_write+0x11f/0x1b0<br /> vfs_write+0x1eb/0x280<br /> ksys_write+0x5f/0xe0<br /> do_syscall_64+0x5c/0x80<br /> ? do_user_addr_fault+0x1d8/0x680<br /> ? do_syscall_64+0x69/0x80<br /> ? exc_page_fault+0x62/0x140<br /> ? asm_exc_page_fault+0x8/0x30<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The command was completed in the abort path during driver unload with a<br /> lock held, causing the warning in abort path. Hence complete the command<br /> without any lock held.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Do not set DRR on pipe Commit<br /> <br /> [WHY]<br /> Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a<br /> pipe commit can cause underflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: qcom: sc7280: Mark PCIe controller as cache coherent<br /> <br /> If the controller is not marked as cache coherent, then kernel will<br /> try to ensure coherency during dma-ops and that may cause data corruption.<br /> So, mark the PCIe node as dma-coherent as the devices on PCIe bus are<br /> cache coherent.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace<br /> <br /> Call kvm_init() only after _all_ setup is complete, as kvm_init() exposes<br /> /dev/kvm to userspace and thus allows userspace to create VMs (and call<br /> other ioctls). E.g. KVM will encounter a NULL pointer when attempting to<br /> add a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able to<br /> create a VM before vmx_init() configures said list.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0002 [#1] SMP<br /> CPU: 6 PID: 1143 Comm: stable Not tainted 6.0.0-rc7+ #988<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:vmx_vcpu_load_vmcs+0x68/0x230 [kvm_intel]<br /> <br /> vmx_vcpu_load+0x16/0x60 [kvm_intel]<br /> kvm_arch_vcpu_load+0x32/0x1f0 [kvm]<br /> vcpu_load+0x2f/0x40 [kvm]<br /> kvm_arch_vcpu_create+0x231/0x310 [kvm]<br /> kvm_vm_ioctl+0x79f/0xe10 [kvm]<br /> ? handle_mm_fault+0xb1/0x220<br /> __x64_sys_ioctl+0x80/0xb0<br /> do_syscall_64+0x2b/0x50<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f5a6b05743b<br /> <br /> Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel(+) kvm irqbypass

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix call trace warning and hang when removing amdgpu device<br /> <br /> On GPUs with RAS enabled, below call trace and hang are observed when<br /> shutting down device.<br /> <br /> v2: use DRM device unplugged flag instead of shutdown flag as the check to<br /> prevent memory wipe in shutdown stage.<br /> <br /> [ +0.000000] RIP: 0010:amdgpu_vram_mgr_fini+0x18d/0x1c0 [amdgpu]<br /> [ +0.000001] PKRU: 55555554<br /> [ +0.000001] Call Trace:<br /> [ +0.000001] <br /> [ +0.000002] amdgpu_ttm_fini+0x140/0x1c0 [amdgpu]<br /> [ +0.000183] amdgpu_bo_fini+0x27/0xa0 [amdgpu]<br /> [ +0.000184] gmc_v11_0_sw_fini+0x2b/0x40 [amdgpu]<br /> [ +0.000163] amdgpu_device_fini_sw+0xb6/0x510 [amdgpu]<br /> [ +0.000152] amdgpu_driver_release_kms+0x16/0x30 [amdgpu]<br /> [ +0.000090] drm_dev_release+0x28/0x50 [drm]<br /> [ +0.000016] devm_drm_dev_init_release+0x38/0x60 [drm]<br /> [ +0.000011] devm_action_release+0x15/0x20<br /> [ +0.000003] release_nodes+0x40/0xc0<br /> [ +0.000001] devres_release_all+0x9e/0xe0<br /> [ +0.000001] device_unbind_cleanup+0x12/0x80<br /> [ +0.000003] device_release_driver_internal+0xff/0x160<br /> [ +0.000001] driver_detach+0x4a/0x90<br /> [ +0.000001] bus_remove_driver+0x6c/0xf0<br /> [ +0.000001] driver_unregister+0x31/0x50<br /> [ +0.000001] pci_unregister_driver+0x40/0x90<br /> [ +0.000003] amdgpu_exit+0x15/0x120 [amdgpu]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Bad drive in topology results kernel crash<br /> <br /> When the SAS Transport Layer support is enabled and a device exposed to<br /> the OS by the driver fails INQUIRY commands, the driver frees up the memory<br /> allocated for an internal HBA port data structure. However, in some places,<br /> the reference to the freed memory is not cleared. When the firmware sends<br /> the Device Info change event for the same device again, the freed memory is<br /> accessed and that leads to memory corruption and OS crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Check kzalloc() in lpfc_sli4_cgn_params_read()<br /> <br /> If kzalloc() fails in lpfc_sli4_cgn_params_read(), then we rely on<br /> lpfc_read_object()&amp;#39;s routine to NULL check pdata.<br /> <br /> Currently, an early return error is thrown from lpfc_read_object() to<br /> protect us from NULL ptr dereference, but the errno code is -ENODEV.<br /> <br /> Change the errno code to a more appropriate -ENOMEM.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix kernel-infoleak in nilfs_ioctl_wrap_copy()<br /> <br /> The ioctl helper function nilfs_ioctl_wrap_copy(), which exchanges a<br /> metadata array to/from user space, may copy uninitialized buffer regions<br /> to user space memory for read-only ioctl commands NILFS_IOCTL_GET_SUINFO<br /> and NILFS_IOCTL_GET_CPINFO.<br /> <br /> This can occur when the element size of the user space metadata given by<br /> the v_size member of the argument nilfs_argv structure is larger than the<br /> size of the metadata element (nilfs_suinfo structure or nilfs_cpinfo<br /> structure) on the file system side.<br /> <br /> KMSAN-enabled kernels detect this issue as follows:<br /> <br /> BUG: KMSAN: kernel-infoleak in instrument_copy_to_user<br /> include/linux/instrumented.h:121 [inline]<br /> BUG: KMSAN: kernel-infoleak in _copy_to_user+0xc0/0x100 lib/usercopy.c:33<br /> instrument_copy_to_user include/linux/instrumented.h:121 [inline]<br /> _copy_to_user+0xc0/0x100 lib/usercopy.c:33<br /> copy_to_user include/linux/uaccess.h:169 [inline]<br /> nilfs_ioctl_wrap_copy+0x6fa/0xc10 fs/nilfs2/ioctl.c:99<br /> nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline]<br /> nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290<br /> nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343<br /> __do_compat_sys_ioctl fs/ioctl.c:968 [inline]<br /> __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910<br /> __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]<br /> __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178<br /> do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203<br /> do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246<br /> entry_SYSENTER_compat_after_hwframe+0x70/0x82<br /> <br /> Uninit was created at:<br /> __alloc_pages+0x9f6/0xe90 mm/page_alloc.c:5572<br /> alloc_pages+0xab0/0xd80 mm/mempolicy.c:2287<br /> __get_free_pages+0x34/0xc0 mm/page_alloc.c:5599<br /> nilfs_ioctl_wrap_copy+0x223/0xc10 fs/nilfs2/ioctl.c:74<br /> nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline]<br /> nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290<br /> nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343<br /> __do_compat_sys_ioctl fs/ioctl.c:968 [inline]<br /> __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910<br /> __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]<br /> __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178<br /> do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203<br /> do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246<br /> entry_SYSENTER_compat_after_hwframe+0x70/0x82<br /> <br /> Bytes 16-127 of 3968 are uninitialized<br /> ...<br /> <br /> This eliminates the leak issue by initializing the page allocated as<br /> buffer using get_zeroed_page().

Vault Community and Vault Enterprise Key/Value (kv) Version 2 plugin may unintentionally expose sensitive information in server and audit logs when users submit malformed payloads during secret creation or update operations via the Vault REST API. This vulnerability, identified as CVE-2025-4166, is fixed in Vault Community 1.19.3 and Vault Enterprise 1.19.3, 1.18.9, 1.17.16, 1.16.20.

Wavlink WL-WN530H4 20220801 was found to contain a command injection vulnerability in the ping_test function of the adm.cgi via the pingIp parameter. This vulnerability allows attackers to execute arbitrary commands via a crafted request.

Tenda AC9 V15.03.06.42_multi was found to contain a command injection vulnerability in the formsetUsbUnload function via the deviceName parameter. This vulnerability allows attackers to execute arbitrary commands via a crafted request.