| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: Guard sysfs discipline callbacks against unallocated private data
Several sysfs show/store handlers call a discipline callback that
dereferences device->private, either directly or through the
DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline
is assigned before check_device() allocates device->private, so an
unprivileged read of one of these world-readable attributes in that window
dereferences a NULL pointer and panics.
Guard the dereference inside each callback that actually touches
device->private. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: plda: Fix use-after-free of event IRQs during teardown
plda_pcie_irq_domain_deinit() removes pcie->event_domain via
irq_domain_remove(), but the per-event IRQs mapped from that domain
are requested with devm_request_irq() in plda_init_interrupts(). The
actual free_irq() for a devm-managed IRQ is deferred by devres until
after the calling probe()/remove() function returns.
This means irq_domain_remove() can free the domain's internal data
before the deferred free_irq() for IRQs still mapped into it has run.
When devres later processes that deferred cleanup, it can end up
dereferencing the already-freed domain.
Free each event IRQ explicitly with devm_free_irq() before removing
the domain. This triggers the free immediately and removes the IRQ
from the devres tracking list, so devres will not attempt to free it
a second time later.
Also dispose of the event, INTx, and MSI IRQ mappings with
irq_dispose_mapping() before their owning domains are removed.
Finally, guard the calls to irq_set_chained_handler_and_data() for
pcie->irq, pcie->msi_irq, and pcie->intx_irq so they only run when
those fields hold a valid (>0) IRQ number.
This is a pre-existing issue, flagged by automated review during work
on an earlier, unrelated patch to this driver.
Build-tested and boot-tested on StarFive VisionFive v1.2A board |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: plda: Fix IRQ domain leaks in the error paths of plda_init_interrupts()
plda_init_interrupts() initializes IRQ domains and creates IRQ mapping but
does not unwind them when later step fails.
If platform_get_irq() or either irq_create_mapping() fails
in plda_init_interrupts(), the domains are never deinitialized. If
irq_create_mapping() fails, port->intx_irq stays initialized.
Hence, remove the IRQ domains in the error path by calling
plda_pcie_irq_domain_deinit().
Since plda_pcie_irq_domain_deinit() now disposes of the intx_irq and
msi_irq mappings itself before removing their domains, the msi_irq
mapping failure path can go directly to err_irq_domain_deinit instead of
disposing of port->intx_irq separately first.
This issue was found by automated review of sashiko-bot
[mani: commit log] |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Put PCI device after handling PPR faults
iommu_call_iopf_notifier() looks up the requester with
pci_get_domain_bus_and_slot(), which returns a PCI device with its
reference count incremented.
Neither the successful iommu_report_device_fault() path nor the abort
path drops that reference, so every handled PPR request leaks a PCI
device reference.
This is the same ownership rule that was fixed for the old iommu_v2
ppr_notifier() path by commit 6cf0981c2233 ("iommu/amd: Fix pci device
refcount leak in ppr_notifier()"), but iommu_call_iopf_notifier() was
added later as a separate PPR/IOPF notifier path.
Drop the PCI device reference after handling the PPR entry. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/sva: Set handle->dev before the SVA handle is visible
iommu_attach_device_pasid() installs the new SVA attach handle in the
group PASID lookup before iommu_sva_bind_device() returns. A concurrent
bind can therefore find and reuse the same handle after iommu_sva_lock is
dropped.
handle->dev was initialized after dropping iommu_sva_lock. This leaves a
window where a racing bind can return a handle whose dev pointer is still
NULL. A subsequent iommu_sva_unbind_device() can then dereference it via
handle->dev->iommu_group.
Initialize handle->dev before releasing iommu_sva_lock so any visible SVA
handle is fully initialized. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu: Fix dev_iommu memory leak when device_add fails in iommu_mock_device_add
iommu_mock_device_add() first calls iommu_fwspec_init(), which on
success allocates both dev->iommu (via dev_iommu_get()) and
dev->iommu->fwspec. If the subsequent device_add(dev) call fails,
the error path only calls iommu_fwspec_free(dev), which frees
fwspec but leaves dev->iommu still allocated.
This triggers the following kmemleak report when fuzzing with Syzkaller:
BUG: memory leak
unreferenced object 0xffff888011e0a200 (size 192):
comm "syz.1.1695", pid 24885, jiffies 4295222527
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .............N..
ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff ................
backtrace (crc 25df5bb3):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4575 [inline]
slab_alloc_node mm/slub.c:4899 [inline]
__kmalloc_cache_noprof+0x47a/0x710 mm/slub.c:5415
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
dev_iommu_get+0x10c/0x1a0 drivers/iommu/iommu.c:408
iommu_fwspec_init+0x288/0x4d0 drivers/iommu/iommu.c:3087
iommu_mock_device_add+0x46/0xb0 drivers/iommu/iommu.c:385
mock_dev_create drivers/iommu/iommufd/selftest.c:1025 [inline]
iommufd_test_mock_domain drivers/iommu/iommufd/selftest.c:1066 [inline]
iommufd_test+0x2f8a/0x6190 drivers/iommu/iommufd/selftest.c:2072
iommufd_fops_ioctl+0x367/0x540 drivers/iommu/iommufd/main.c:533
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fix this by calling dev_iommu_free(dev) instead of iommu_fwspec_free(dev)
in the device_add() failure path. dev_iommu_free() frees both fwspec
and the outer dev_iommu struct and clears dev->iommu. |
| In the Linux kernel, the following vulnerability has been resolved:
iommufd: Avoid locking internal accesses during unmap
iommufd_access_notify_unmap() skips internal accesses because they do
not have an external unmap callback to invoke.
However, the current test calls iommufd_lock_obj() before checking
whether the access is internal. If iommufd_lock_obj() succeeds, the loop
then sees the internal access and continues, bypassing the matching
iommufd_put_object() used by the normal unmap path. This leaks the
object reference taken by iommufd_lock_obj().
Check for internal accesses first so skipped entries are never locked. |
| In the Linux kernel, the following vulnerability has been resolved:
iommufd: Release current IOAS on xa_store() failure
iommufd_take_all_iova_rwsem() takes an object reference and the
iova_rwsem write lock before storing the IOAS in the temporary ioas_list
xarray.
If xa_store() fails, the current IOAS has not been inserted into
ioas_list yet. iommufd_release_all_iova_rwsem() only unwinds IOAS
objects already present in that xarray, so it cannot release the current
IOAS.
Release the current IOAS rwsem and object reference before unwinding the
previously stored entries. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer
set_attribute() populates the security area of the BIOS attribute request
buffer with the current admin password via populate_security_buffer(), then
dumps the whole request buffer with print_hex_dump_bytes(). This can expose
the plaintext admin password in the kernel log.
The same issue was fixed for the password attribute path by
commit d1a196e0a6dc ("platform/x86: dell-wmi-sysman: Don't hex dump
plaintext password data"). Remove the remaining dump from the BIOS
attribute path. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: ISST: Add a NULL check for sst_inst[]
To be consistent with other places, add a NULL check for failed socket
loading by checking isst_common.sst_inst[]. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: ISST: Validate logical CPU id and clos id
Validate max CLOS ID and logical CPU ID for core power feature.
Reject any clos level or logical CPU number greater than the
supported maximum. These are used to calculate MMIO offset. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: int1092: Fix potential memory leak in sar_probe()
The memory allocated for device_mode_info in parse_package() called by
sar_get_data() is not freed in some of the error paths in sar_probe().
Fix that by converting to use device managed allocations. |
| Inclusion of functionality from an untrusted control sphere in the Kiro Powers feature in Amazon Kiro IDE before version 0.8.135 might allow remote unauthenticated actors to obtain sensitive information from a developer workstation. Crafted repository content can cause the agent to modify the workspace settings file, which redirects the Kiro Powers registry request to an actor controlled endpoint and sends workspace data to that endpoint when the Powers panel is opened.
To remediate this issue, users should upgrade to Kiro IDE version 0.8.135 or later. Users who opened a project in an earlier version should also rotate any credentials that were present in that project. |
| AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 contains a stored cross-site scripting vulnerability in the Bookmark plugin where chapter names are not encoded before being concatenated into public watch-page HTML. A video owner can inject malicious scripts via the bookmark name parameter, and every visitor of that video executes the payload in the AVideo origin. |
| WWBN AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 contains a reflected cross-site scripting vulnerability in confirmLivePassword.php that copies REQUEST_URI into a form action attribute without encoding. Attackers can craft a malicious URL with a quote character to break out of the action attribute and inject event handlers that execute in the victim's browser within the site origin. |
| Forgejo before 16.0.4 allows use of restricted API tokens for unintended access to the "allow maintainer edit" feature. |
| An unrecovered panic in the event stream header decoder in Amazon AWS SDK for Go v2 before release-2026-03-23 might allow an unauthenticated remote actor to terminate the consuming application process via a crafted event stream response frame containing a header value type outside the valid range.
To remediate this issue, users should upgrade to release-2026-03-23 or later, and patch any forked or derivative code. |
| knowns through 0.33.0 fails to confine the path argument of the code.find MCP tool to the project root, allowing AI agent sessions to read source files anywhere on the host. Attackers can supply absolute paths or relative traversal sequences to the path argument and retrieve full file contents from outside the intended project directory. |
| CyberPanel before 3.0.5 fails to enforce two-factor authentication on API endpoints, allowing attackers to bypass TOTP requirements using password-derived tokens. Attackers who obtain an administrator's password can derive API tokens and perform administrative operations or create authenticated sessions without the second factor. |
| OpenPanel through commit cd24bb8 contains an SQL injection vulnerability in the analytics filter builder that fails to validate profile.* filter column identifiers before interpolating them into ClickHouse WHERE clauses. An authenticated attacker with project-scoped read or root export credentials can inject arbitrary ClickHouse SQL to bypass project isolation and read other organizations' analytics data and profile PII via blind boolean oracle techniques. |
