| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
idpf: fix error handling in the init_task on load
If the init_task fails during a driver load, we end up without vports and
netdevs, effectively failing the entire process. In that state a
subsequent reset will result in a crash as the service task attempts to
access uninitialized resources. Following trace is from an error in the
init_task where the CREATE_VPORT (op 501) is rejected by the FW:
[40922.763136] idpf 0000:83:00.0: Device HW Reset initiated
[40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)
[40958.148190] idpf 0000:83:00.0: HW reset detected
[40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8
...
[40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf]
[40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]
...
[40958.177932] Call Trace:
[40958.178491] <TASK>
[40958.179040] process_one_work+0x226/0x6d0
[40958.179609] worker_thread+0x19e/0x340
[40958.180158] ? __pfx_worker_thread+0x10/0x10
[40958.180702] kthread+0x10f/0x250
[40958.181238] ? __pfx_kthread+0x10/0x10
[40958.181774] ret_from_fork+0x251/0x2b0
[40958.182307] ? __pfx_kthread+0x10/0x10
[40958.182834] ret_from_fork_asm+0x1a/0x30
[40958.183370] </TASK>
Fix the error handling in the init_task to make sure the service and
mailbox tasks are disabled if the error happens during load. These are
started in idpf_vc_core_init(), which spawns the init_task and has no way
of knowing if it failed. If the error happens on reset, following
successful driver load, the tasks can still run, as that will allow the
netdevs to attempt recovery through another reset. Stop the PTP callbacks
either way as those will be restarted by the call to idpf_vc_core_init()
during a successful reset. |
| In the Linux kernel, the following vulnerability has been resolved:
net: usb: pegasus: fix memory leak in update_eth_regs_async()
When asynchronously writing to the device registers and if usb_submit_urb()
fail, the code fail to release allocated to this point resources. |
| In the Linux kernel, the following vulnerability has been resolved:
idpf: fix memory leak in idpf_vc_core_deinit()
Make sure to free hw->lan_regs. Reported by kmemleak during reset:
unreferenced object 0xff1b913d02a936c0 (size 96):
comm "kworker/u258:14", pid 2174, jiffies 4294958305
hex dump (first 32 bytes):
00 00 00 c0 a8 ba 2d ff 00 00 00 00 00 00 00 00 ......-.........
00 00 40 08 00 00 00 00 00 00 25 b3 a8 ba 2d ff ..@.......%...-.
backtrace (crc 36063c4f):
__kmalloc_noprof+0x48f/0x890
idpf_vc_core_init+0x6ce/0x9b0 [idpf]
idpf_vc_event_task+0x1fb/0x350 [idpf]
process_one_work+0x226/0x6d0
worker_thread+0x19e/0x340
kthread+0x10f/0x250
ret_from_fork+0x251/0x2b0
ret_from_fork_asm+0x1a/0x30 |
| In the Linux kernel, the following vulnerability has been resolved:
idpf: fix memory leak in idpf_vport_rel()
Free vport->rx_ptype_lkup in idpf_vport_rel() to avoid leaking memory
during a reset. Reported by kmemleak:
unreferenced object 0xff450acac838a000 (size 4096):
comm "kworker/u258:5", pid 7732, jiffies 4296830044
hex dump (first 32 bytes):
00 00 00 00 00 10 00 00 00 10 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 ................
backtrace (crc 3da81902):
__kmalloc_cache_noprof+0x469/0x7a0
idpf_send_get_rx_ptype_msg+0x90/0x570 [idpf]
idpf_init_task+0x1ec/0x8d0 [idpf]
process_one_work+0x226/0x6d0
worker_thread+0x19e/0x340
kthread+0x10f/0x250
ret_from_fork+0x251/0x2b0
ret_from_fork_asm+0x1a/0x30 |
| In the Linux kernel, the following vulnerability has been resolved:
idpf: fix memory leak of flow steer list on rmmod
The flow steering list maintains entries that are added and removed as
ethtool creates and deletes flow steering rules. Module removal with active
entries causes memory leak as the list is not properly cleaned up.
Prevent this by iterating through the remaining entries in the list and
freeing the associated memory during module removal. Add a spinlock
(flow_steer_list_lock) to protect the list access from multiple threads. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()
Fix a memory leak in gpi_peripheral_config() where the original memory
pointed to by gchan->config could be lost if krealloc() fails.
The issue occurs when:
1. gchan->config points to previously allocated memory
2. krealloc() fails and returns NULL
3. The function directly assigns NULL to gchan->config, losing the
reference to the original memory
4. The original memory becomes unreachable and cannot be freed
Fix this by using a temporary variable to hold the krealloc() result
and only updating gchan->config when the allocation succeeds.
Found via static analysis and code review. |
| In the Linux kernel, the following vulnerability has been resolved:
phy: rockchip: inno-usb2: Fix a double free bug in rockchip_usb2phy_probe()
The for_each_available_child_of_node() calls of_node_put() to
release child_np in each success loop. After breaking from the
loop with the child_np has been released, the code will jump to
the put_child label and will call the of_node_put() again if the
devm_request_threaded_irq() fails. These cause a double free bug.
Fix by returning directly to avoid the duplicate of_node_put(). |
| In the Linux kernel, the following vulnerability has been resolved:
null_blk: fix kmemleak by releasing references to fault configfs items
When CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blk
driver sets up fault injection support by creating the timeout_inject,
requeue_inject, and init_hctx_fault_inject configfs items as children
of the top-level nullbX configfs group.
However, when the nullbX device is removed, the references taken to
these fault-config configfs items are not released. As a result,
kmemleak reports a memory leak, for example:
unreferenced object 0xc00000021ff25c40 (size 32):
comm "mkdir", pid 10665, jiffies 4322121578
hex dump (first 32 bytes):
69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_
69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject..........
backtrace (crc 1a018c86):
__kmalloc_node_track_caller_noprof+0x494/0xbd8
kvasprintf+0x74/0xf4
config_item_set_name+0xf0/0x104
config_group_init_type_name+0x48/0xfc
fault_config_init+0x48/0xf0
0xc0080000180559e4
configfs_mkdir+0x304/0x814
vfs_mkdir+0x49c/0x604
do_mkdirat+0x314/0x3d0
sys_mkdir+0xa0/0xd8
system_call_exception+0x1b0/0x4f0
system_call_vectored_common+0x15c/0x2ec
Fix this by explicitly releasing the references to the fault-config
configfs items when dropping the reference to the top-level nullbX
configfs group. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: omap-dma: fix dma_pool resource leak in error paths
The dma_pool created by dma_pool_create() is not destroyed when
dma_async_device_register() or of_dma_controller_register() fails,
causing a resource leak in the probe error paths.
Add dma_pool_destroy() in both error paths to properly release the
allocated dma_pool resource. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/userq: Fix fence reference leak on queue teardown v2
The user mode queue keeps a pointer to the most recent fence in
userq->last_fence. This pointer holds an extra dma_fence reference.
When the queue is destroyed, we free the fence driver and its xarray,
but we forgot to drop the last_fence reference.
Because of the missing dma_fence_put(), the last fence object can stay
alive when the driver unloads. This leaves an allocated object in the
amdgpu_userq_fence slab cache and triggers
This is visible during driver unload as:
BUG amdgpu_userq_fence: Objects remaining on __kmem_cache_shutdown()
kmem_cache_destroy amdgpu_userq_fence: Slab cache still has objects
Call Trace:
kmem_cache_destroy
amdgpu_userq_fence_slab_fini
amdgpu_exit
__do_sys_delete_module
Fix this by putting userq->last_fence and clearing the pointer during
amdgpu_userq_fence_driver_free().
This makes sure the fence reference is released and the slab cache is
empty when the module exits.
v2: Update to only release userq->last_fence with dma_fence_put()
(Christian)
(cherry picked from commit 8e051e38a8d45caf6a866d4ff842105b577953bb) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/gud: fix NULL fb and crtc dereferences on USB disconnect
On disconnect drm_atomic_helper_disable_all() is called which
sets both the fb and crtc for a plane to NULL before invoking a commit.
This causes a kernel oops on every display disconnect.
Add guards for those dereferences. |
| During the installation of the Native Access application, a privileged helper `com.native-instruments.NativeAccess.Helper2`, which is used by Native Access to trigger functions via XPC communication like copy-file, remove or set-permissions, is deployed as well. The communication with the XPC service of the privileged helper is only allowed if the client process is signed with the corresponding certificate and fulfills the following code signing requirement:
"anchor trusted and certificate leaf[subject.CN] = \"Developer ID Application: Native Instruments GmbH (83K5EG6Z9V)\""
The Native Access application was found to be signed with the `com.apple.security.cs.allow-dyld-environment-variables` and `com.apple.security.cs.disable-library-validation` entitlements leading to DYLIB injection and therefore command execution in the context of this application. A low privileged user can exploit the DYLIB injection to trigger functions of the privileged helper XPC service resulting in privilege escalation by first deleting the /etc/sudoers file and then copying a malicious version of that file to /etc/sudoers. |
| It was found that the XPC service offered by the privileged helper of Native Access uses the PID of the connecting client to verify its code signature. This is considered insecure and can be exploited by PID reuse attacks. The connection handler function uses _xpc_connection_get_pid(arg2) as argument for the hasValidSignature function. This value can not be trusted since it is vulnerable to PID reuse attacks. |
| SunFounder Pironman Dashboard (pm_dashboard) version 1.3.13 and prior contain a path traversal vulnerability in the log file API endpoints. An unauthenticated remote attacker can supply traversal sequences via the filename parameter to read and delete arbitrary files. Successful exploitation can disclose sensitive information and delete critical system files, resulting in data loss and potential system compromise or denial of service. |
| A vulnerability in MagicInfo9 Server allows authorized users to upload HTML files without authentication, leading to Stored XSS, which can result in account takeover
This issue affects MagicINFO 9 Server: less than 21.1090.1. |
| An unauthenticated user can upload arbitrary files to execute remote code, leading to privilege escalation in MagicInfo9 Server.
This issue affects MagicINFO 9 Server: less than 21.1090.1. |
| The database account and password are hardcoded, allowing login with the account to manipulate the database in MagicInfo9 Server.This issue affects MagicINFO 9 Server: less than 21.1090.1. |
| OpenClaw (aka clawdbot or Moltbot) before 2026.1.29 obtains a gatewayUrl value from a query string and automatically makes a WebSocket connection without prompting, sending a token value. |
| BOOTP Turbo 2.0.1214 contains an unquoted service path vulnerability that allows local attackers to potentially execute arbitrary code with elevated system privileges. Attackers can exploit the unquoted executable path to inject malicious code that will be executed when the service starts with LocalSystem permissions. |
| In Modem, there is a possible system crash due to a missing bounds check. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01689254 (Note: For N15 and NR16) / MOLY01689259 (Note: For NR17 and NR17R); Issue ID: MSV-4843. |
