| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Vulnerability in tapestry-core in Apache Tapestry 5.5.0+ on all platforms allows attackers to download clsspath assets via specially crafted URLs.
Users are recommended to upgrade to version 5.9.1, which fixes this issue. |
| An LDAP Injection vulnerability in WatchGuard Fireware OS may allow a remote unauthenticated attacker to retrieve sensitive information from a connected LDAP authentication server through an exposed authentication or management web interface. This vulnerability may also allow a remote attacker to authenticate as an LDAP user with a partial identifier if they additionally have that user's valid passphrase. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Use sender devcom for MPV master-up
After PCIe DPC recovery, mlx5 reloads the affected functions and
replays multiport affiliation events. In the reported failure, the
first relevant device error was:
pcieport 0000:10:01.1: DPC: containment event
pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal)
pcieport 0000:10:01.1: [ 5] SDES (First)
mlx5 recovered the PCI functions and resumed 0000:11:00.1. During
that resume, RDMA multiport binding replayed
MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent
MPV_DEVCOM_MASTER_UP. The host then panicked with:
BUG: kernel NULL pointer dereference, address: 0000000000000010
RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core]
RDI: 0000000000000000
Call trace included:
mlx5_devcom_comp_set_ready
mlx5e_devcom_event_mpv
mlx5_devcom_send_event
mlx5_ib_bind_slave_port
mlx5r_mp_probe
mlx5_pci_resume
MPV devcom registration publishes mlx5e private data to the component
peer list before mlx5e_devcom_init_mpv() stores the returned component
device in priv->devcom. A concurrent master-up event can therefore
reach a peer whose private data is visible but whose priv->devcom
backpointer is still NULL.
MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private
data as event_data. The ready bit is stored on the shared devcom
component, not on an individual peer. Use the sender devcom when
marking the MPV component ready.
This preserves the readiness transition while avoiding a NULL
dereference of the peer devcom pointer during affiliation replay after
PCI error recovery. |
| A flaw was found in multicluster-global-hub. During a ManagedClusterMigration, the system incorrectly grants all managed hubs read access to a shared communication topic. This allows a compromised managed hub to intercept and collect sensitive bootstrap kubeconfigs, which contain API server tokens intended for other hubs. These tokens have an extended validity of approximately 9.86 years, significantly increasing the risk of unauthorized access and information disclosure to other managed clusters. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915/bios: range check LFP Data Block panel_type2
While the panel_type from LFP Data Block is range checked, panel_type2
is not. Add a few helpers for range checking, and use them to not only
check panel_type2, but also improve clarity and correctness in the panel
type selection.
Discovered using AI-assisted static analysis confirmed by Intel Product
Security.
v2:
- Fix commit message typo (Michał)
- Add is_panel_type_pnp() (Ville)
(cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df) |
| The Admin Safety Guard — Login Security, Limit Logins, 2FA & Brute Force Protection WordPress plugin before 1.4.0 does not perform any capability check on one of its REST API endpoints, allowing unauthenticated attackers to retrieve the full list of registered users including their usernames, email addresses, roles, and two-factor authentication enrollment status. |
| The WP Directory Kit WordPress plugin before 1.5.5 does not perform authorization or nonce checks on one of its authenticated AJAX actions, allowing any authenticated user such as a Subscriber to retrieve stored contact messages and associated user data belonging to other users. |
| The WPC Order Tip for WooCommerce WordPress plugin before 3.3.1 does not perform authorisation or nonce checks in one of its reporting features, allowing unauthenticated attackers to retrieve sensitive order data belonging to any customer of the store, such as billing names, order IDs and statuses, fee amounts and order dates. |
| The InfiniteWP Client WordPress plugin before 1.13.6 does not properly verify the site-connection state and the authenticity of requests to its remote-management endpoint on WordPress Multisite installations, allowing unauthenticated attackers to bind their own key, hijack an administrator session, and take over the entire network, leading to remote code execution. |
| The PiWeb Cancel order / Refund request for WooCommerce WordPress plugin before 1.3.4.34 does not have authorization or ownership checks when adding the contents of a previous order to the cart, allowing unauthenticated users to disclose the contents of other customers' orders, as well as to clear and repopulate a logged in user's cart via a crafted link. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix kernel panic during driver load failure
Avoid kernel panic if MES init fails during driver load. The KIQ ring is
falsely marked as ready as ASICs that use MES, KIQ is owned by MES.
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu]
Call Trace:
gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu]
amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu]
amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu]
amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu]
amdgpu_gart_unbind+0x72/0x90 [amdgpu]
amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu]
amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu]
amdttm_tt_unpopulate+0x29/0x70 [amdttm]
ttm_bo_put+0x1eb/0x360 [amdttm]
amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu]
amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu]
amdgpu_irq_fini_hw+0x58/0x80 [amdgpu]
amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu]
amdgpu_driver_load_kms+0x60/0xa0 [amdgpu]
amdgpu_pci_probe+0x28e/0x6d0 [amdgpu]
pci_device_probe+0x19f/0x220
really_probe+0x1ed/0x340
driver_probe_device+0x1e/0x80
__driver_attach+0xd3/0x1a0
bus_for_each_dev+0x68/0xa0
bus_add_driver+0x19f/0x270
driver_register+0x5d/0xf0
do_one_initcall+0xac/0x200
do_init_module+0x1ec/0x280
__se_sys_finit_module+0x2de/0x310
do_syscall_64+0x6a/0x250
entry_SYSCALL_64_after_hwframe+0x4b/0x53
(cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48) |
| In the Linux kernel, the following vulnerability has been resolved:
ovpn: fix peer refcount leak in TCP error paths
When either the TCP RX or TX error path calls ovpn_peer_hold() followed
by schedule_work(&peer->tcp.defer_del_work), and the work item is already
pending from the other path, schedule_work() returns false and the work
runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put()
exactly once, the extra reference taken by the losing path is never
dropped, leaking the peer object.
The race window:
CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error):
ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2
schedule_work() <- queued schedule_work() <- NO-OP
(work already pending)
ovpn_tcp_peer_del_work runs:
ovpn_peer_del()
ovpn_peer_put() <- refcnt+1
<- peer never freed
Fix by checking the return value of schedule_work() in both paths and
calling ovpn_peer_put() to drop the extra reference if the work was
already pending. ovpn_peer_hold() is kept unconditional in the TX path
as it cannot fail at that point. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict
If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM
reference acquired earlier is not released, resulting in a reference
leak.
Fix this by dropping the MM reference on the kvmalloc_array()
failure path. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Account for NULL and handle pages in ttm_pool_backup
Pages in ttm_pool_backup can be NULL or backup handles
(ttm_backup_page_ptr_is_handle()), neither of which can be passed to
set_pages_array_wb() or freed. Add a dedicated WB pass before the
dma/purge loop that walks allocations using the same i += num_pages
stride, skipping NULL and handle entries, and calls set_pages_array_wb()
once per contiguous run of real pages. Apply the same NULL/handle guard
to the dma/purge loop.
Fixes the following oops:
Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI
RIP: 0010:__cpa_process_fault+0xf8/0x770
RSP: 0018:ffffc90000a87718 EFLAGS: 00010287
RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000
RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34
RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0
R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000
R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0
FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0
PKRU: 55555554
Call Trace:
<TASK>
__change_page_attr_set_clr+0x989/0xe90
? __purge_vmap_area_lazy+0x6c/0x3a0
? _vm_unmap_aliases+0x250/0x2a0
set_pages_array_wb+0x7f/0x120
ttm_pool_backup+0x4c9/0x5b0 [ttm]
? dma_resv_wait_timeout+0x3b/0xf0
ttm_tt_backup+0x32/0x60 [ttm]
ttm_bo_shrink+0x66/0x110 [ttm]
xe_bo_shrink_purge+0x12b/0x1b0 [xe]
xe_bo_shrink+0xbb/0x270 [xe]
__xe_shrinker_walk+0xf7/0x160 [xe]
xe_shrinker_walk+0x9d/0xc0 [xe]
xe_shrinker_scan+0x11f/0x210 [xe]
do_shrink_slab+0x13b/0x270
shrink_slab+0xf1/0x400
shrink_node+0x352/0x8a0
balance_pgdat+0x32c/0x700
kswapd+0x205/0x2f0
? __pfx_autoremove_wake_function+0x10/0x10
? __pfx_kswapd+0x10/0x10
kthread+0xd1/0x110
? __pfx_kthread+0x10/0x10
ret_from_fork+0x1b1/0x200
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Check bounds in allocate_event_notification_slot
The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT
allocate_event_notification_slot has an option to specify
an event id to allocate at, used by CRIU. We weren't checking
the bounds on that value.
Check them.
v2: Lower bounds check is unecessary because of idr_alloc
already rejecting negative numbers. Upper bounds check should
be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might
not yet exist
(cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50) |
| The LWS Optimize WordPress plugin before 4.1.2 does not properly escape a value submitted through an unauthenticated analytics endpoint before storing it and rendering it in an administrative dashboard, allowing unauthenticated attackers to inject arbitrary web scripts that execute when an administrator views the affected dashboard page. |
| The WP MAPS PRO WordPress plugin before 6.1.3 does not perform a capability check in one of its AJAX actions, which is also available to unauthenticated users, and does not restrict the operation it dispatches, allowing unauthenticated attackers to trigger uncontrolled recursion that exhausts server resources, resulting in a Denial of Service. |
| An Out-of-bounds Write vulnerability in WatchGuard Fireware OS's CLI could allow an authenticated privileged user to execute arbitrary code via a specially crafted CLI command. |
| A path traversal vulnerability in the WatchGuard Fireware OS Management Web UI allows a privileged authenticated attacker to write arbitrary files on the Firebox's filesystem. |
