| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister()
gdsc_unregister() removes the OF provider entry and tears down the
parent/subdomain wiring, but never calls pm_genpd_remove() on the
individual generic_pm_domain structures registered by gdsc_init():
void gdsc_unregister(struct gdsc_desc *desc)
{
struct device *dev = desc->dev;
size_t num = desc->num;
gdsc_pm_subdomain_remove(desc, num);
of_genpd_del_provider(dev->of_node);
}
That leaves dangling entries on the global gpd_list. After a provider
unbind/rebind cycle (deferred-probe replay during early boot, real
module unload of a clk driver that owns GDSCs, or an OF-overlay tear-
down) the next gdsc_init() will end up trying to re-register a name
that is still in the list and pm_genpd_init() returns -EEXIST.
While we are here, flip the order so the consumer-facing OF provider
entry is the first thing removed -- otherwise a fresh
of_genpd_get_from_provider() call racing with the teardown could
attach to a domain that is mid-removal.
Iterate the scs[] array and pm_genpd_remove() each registered domain
after the subdomain links are torn down. The regulators stay devm-
managed (devm_regulator_get_optional() in gdsc_register()), so the
release happens automatically when the underlying device is unbound;
just the genpd accounting needs to be undone explicitly. |
| A vulnerability was found in O-RAN-SC SMO OAM 2025-06-10. Affected by this vulnerability is an unknown functionality of the component VES Collector. Performing a manipulation results in allocation of resources. The attack may be initiated remotely. The exploit has been made public and could be used. The project was informed of the problem early through a bug report but has not responded yet. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/bng_re: return a timeout when firmware responses stall
__wait_for_resp() documents that it returns a non-zero error when a
firmware command does not complete, and bng_re_rcfw_send_message() already
marks the firmware as stalled when the helper returns -ENODEV.
However, the helper ignores wait_event_timeout() expiry. If the response
slot remains in use after the timeout and after the polled CREQ service
attempt, the loop starts another full timeout period and can repeat
forever.
Return -ENODEV after a timed out wait that still has no response. The
existing caller then marks FIRMWARE_STALL_DETECTED and returns
-ETIMEDOUT to the command issuer. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: debug: fix off by on in rtw89_ppdu_str()
This > comparison should be >= to avoid an out of bounds access. |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep()
In riscv_acpi_add_prt_dep(), the acpi_get_handle() call can fail which
would leave link_handle uninitialized.
Fix it by checking the acpi_get_handle() return status and skip the entry
if it fails. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Clear VM_MAYWRITE on DBR/toggle page mmap
bnxt_re_mmap() rejects VM_WRITE for the DBR_PAGE and TOGGLE_PAGE mmap
flags, but a read-only mapping can still retain VM_MAYWRITE. nd later
be upgraded with mprotect(PROT_WRITE). This can bypass the write check
that only runs at mmap time.
Clear VM_MAYWRITE before vm_insert_page() in the shared DBR/toggle-page
branch, matching the existing policy that userspace writes are not
expected for these pages. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Validate connected lane counts
The connected lane count is used by TX equalization code to index arrays
sized by UFS_MAX_LANES. Reject zero and out-of-range RX or TX lane counts
before they can be propagated. |
| In the Linux kernel, the following vulnerability has been resolved:
iomap: release the folio batch on iomap callback failures
A sashiko review of an unrelated patch points out that the folio
batch mechanism used for iomap zero range fails to release the batch
in a couple error scenarios. If either calls to ->iomap_end() or
->iomap_begin() fail, the direct return paths bypass the batch
cleanup.
The ->iomap_end() case is not a practical issue at the moment
because there is no user of the mechanism that returns an error from
this path. The ->iomap_begin() case is theoretically possible
because XFS can invoke the fill helper and error out at various
points thereafter. This subtly complicates things because XFS does
not transfer iomap_flags to the iomap data structure in the error
path.
To deal with both of these issues, first make sure to invoke the
cleanup helper in the error path for either fs callback. Second,
update the helper to clear the flag unconditionally and release the
batch so long as it is populated. This more clearly delineates the
purpose of the flag to control the I/O path and not necessarily the
status of the fbatch, so add a comment around this as well. |
| In the Linux kernel, the following vulnerability has been resolved:
block: fix dio leak on metadata mapping error
A failed integrity mapping holds a dio reference, so we need to go
through the full bio ending in case there were previously submitted
bio's in the sequence. |
| In the Linux kernel, the following vulnerability has been resolved:
fat: release buffer head after rebuilding parent
fat_scan_logstart() leaves the matching directory entry's buffer head in
sinfo.bh for the caller to release, just like fat_scan().
fat_rebuild_parent() uses the directory entry to rebuild the parent inode
for the nostale_ro NFS export path, but does not release sinfo.bh after a
successful scan. Release it once fat_build_inode() has consumed the
directory entry data. |
| In the Linux kernel, the following vulnerability has been resolved:
phonet: pep: do not write beyond optlen in getsockopt
pep_getsockopt() clamps the reported length to the caller's buffer with
min_t(), but then stores the value with put_user(val, (int __user *)
optval), which always writes sizeof(int) bytes. A getsockopt() call with
an optlen smaller than sizeof(int) thus reports the clamped length yet
writes a full int, one to three bytes past the user buffer.
Write the value with copy_to_user() bounded by len, so at most optlen
bytes are copied, matching the length reported back to userspace. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: clean up color-change beacon data on errors
nl80211_color_change() calls nl80211_parse_beacon() for the beacon_next
template, which can allocate params.beacon_next.mbssid_ies and .rnr_ies.
A parsing failure returned directly instead of using the out: cleanup,
leaking any allocations completed before the error.
Allocate the nested attribute table before parsing beacon_next. Its
allocation failure can then return before beacon data exists, while a
later parsing failure uses out: to release the parsed data. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: release hif2 reference on probe IRQ failure
The hif2 reference obtained by mt7915_pci_init_hif2() is only released on
error paths that key off dev->hif2, which is not assigned until after the
IRQ setup. If pci_alloc_irq_vectors() or the primary devm_request_irq()
fails, the reference leaks. Drop it explicitly on those paths via
mt7915_put_hif2(). |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: defrag: fix deadlock between defrag and delalloc space reservation
While running fsstress with autodefrag and flushoncommit, hit a deadlock
due to the fact that defrag reserves delalloc space while it's holding
dirty and locked folios, besides the extent range lock. The stack traces
are the following:
[958.624] task:kworker/u50:3 state:D stack:0 pid:20365 tgid:20365 ppid:2 task_flags:0x4208060 flags:0x00080000
[958.626] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]
[958.627] Call Trace:
[958.628] <TASK>
[958.628] __schedule+0x4be/0x10f0
[958.629] ? preempt_count_add+0x69/0xa0
[958.630] schedule+0x26/0xd0
[958.631] wait_current_trans+0x102/0x160 [btrfs]
[958.632] ? __pfx_autoremove_wake_function+0x10/0x10
[958.633] start_transaction+0x374/0x900 [btrfs]
[958.634] btrfs_commit_current_transaction+0x1d/0x70 [btrfs]
[958.635] flush_space+0xca/0x5e0 [btrfs]
[958.636] ? _raw_spin_unlock+0x15/0x30
[958.637] ? btrfs_reduce_alloc_profile+0x8c/0x190 [btrfs]
[958.639] ? _raw_spin_unlock+0x15/0x30
[958.640] ? calc_available_free_space.isra.0+0x6f/0x110 [btrfs]
[958.641] do_async_reclaim_metadata_space+0x84/0x190 [btrfs]
[958.642] btrfs_async_reclaim_metadata_space+0x64/0x80 [btrfs]
[958.644] process_one_work+0x19d/0x3a0
[958.644] worker_thread+0x1c4/0x330
[958.645] ? __pfx_worker_thread+0x10/0x10
[958.646] kthread+0xfc/0x130
[958.647] ? __pfx_kthread+0x10/0x10
[958.648] ret_from_fork+0x1f7/0x2c0
[958.648] ? __pfx_kthread+0x10/0x10
[958.649] ret_from_fork_asm+0x1a/0x30
[958.650] </TASK>
[958.651] task:kworker/u49:7 state:D stack:0 pid:52990 tgid:52990 ppid:2 task_flags:0x4208060 flags:0x00080000
[958.653] Workqueue: writeback wb_workfn (flush-btrfs-334)
[958.655] Call Trace:
[958.655] <TASK>
[958.656] __schedule+0x4be/0x10f0
[958.657] ? __blk_flush_plug+0xe9/0x140
[958.658] schedule+0x26/0xd0
[958.658] io_schedule+0x42/0x70
[958.659] folio_wait_bit_common+0x12b/0x330
[958.660] ? folio_wait_bit_common+0x100/0x330
[958.662] ? __pfx_wake_page_function+0x10/0x10
[958.663] extent_write_cache_pages+0x599/0x830 [btrfs]
[958.664] ? acpi_fwnode_get_reference_args+0x1fa/0x270
[958.665] btrfs_writepages+0x77/0x130 [btrfs]
[958.666] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs]
[958.667] do_writepages+0xc6/0x160
[958.668] __writeback_single_inode+0x42/0x310
[958.669] writeback_sb_inodes+0x231/0x570
[958.670] wb_writeback+0x8a/0x340
[958.671] wb_workfn+0xbf/0x450
[958.672] ? finish_task_switch.isra.0+0xc1/0x350
[958.673] process_one_work+0x19d/0x3a0
[958.673] worker_thread+0x1c4/0x330
[958.674] ? __pfx_worker_thread+0x10/0x10
[958.675] kthread+0xfc/0x130
[958.676] ? __pfx_kthread+0x10/0x10
[958.676] ret_from_fork+0x1f7/0x2c0
[958.677] ? __pfx_kthread+0x10/0x10
[958.678] ret_from_fork_asm+0x1a/0x30
[958.679] </TASK>
[958.679] task:btrfs-cleaner state:D stack:0 pid:296750 tgid:296750 ppid:2 task_flags:0x208040 flags:0x00080000
[958.681] Call Trace:
[958.682] <TASK>
[958.682] __schedule+0x4be/0x10f0
[958.683] schedule+0x26/0xd0
[958.684] handle_reserve_ticket+0x1b9/0x2c0 [btrfs]
[958.685] ? __pfx_autoremove_wake_function+0x10/0x10
[958.686] reserve_bytes+0x283/0x4c0 [btrfs]
[958.687] btrfs_reserve_metadata_bytes+0x18/0xb0 [btrfs]
[958.688] btrfs_delalloc_reserve_metadata+0x121/0x320 [btrfs]
[958.690] btrfs_delalloc_reserve_space+0x46/0xb0 [btrfs]
[958.691] btrfs_defrag_file+0x903/0x1110 [btrfs]
[958.692] btrfs_run_defrag_inodes+0x334/0x430 [btrfs]
[958.694] cleaner_kthread+0x97/0x1c0 [btrfs]
[958.694] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs]
[958.696] kthread+0xfc/0x130
[958.696] ? __pfx_kthread+0x10/0x10
[958.697] ret_
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
cpufreq: imx6q: fix devres accumulation across driver rebind
imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev
is the CPU device from get_cpu_device(0). That device is never unbound, so
its devres list is never released, and imx6q_cpufreq_remove() does not free
the array either. Every probe therefore adds an allocation that stays for
the lifetime of the system.
Allocate against the platform device instead. Its devres is released when
the driver is unbound, which is exactly the lifetime the array wants:
imx6q_set_target() reads it, and nothing may reach that after
cpufreq_unregister_driver().
That makes the array actually go away on unbind, so also clear the
file-scope pointer in remove and on the failed-probe path, rather than
leave it pointing at memory devres is about to release.
Tested by rebinding the driver on qemu's mcimx6ul-evk. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: haptic: don't write an uninitialized value to unhandled usages
fill_effect_buf() initializes value only for the four haptic usages
handled by its switch, but writes it to field->value[] for every usage.
An unhandled usage can therefore receive either an uninitialized value
or one left over from the previous usage. hid_output_report() then
serializes that value into the effect's report buffer.
Skip unhandled usages instead. This also matches switch_mode(), which
only updates fields it recognizes.
Found with Clang's -Wconditional-uninitialized. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix max_qid race between configfs and controller allocation
The function nvmet_subsys_attr_qid_max_store() can race against
nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified.
Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes:
ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1);
and at this exact point, a userspace process changes max_qid to 128,
nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It
attempts to delete active controllers to force a reconnect, but the
new controller won't be deleted because it hasn't been added to the
subsys->ctrls list yet.
nvmet_alloc_ctrl() then proceeds and adds the new controller to the
subsys->ctrls list. Later, when nvmet_install_queue() is called, it
will see max_qid set to 128, but the memory allocated for sqs is only
sized for 64 entries. This results in a KASAN out-of-bounds warning
and potential memory corruptions.
Fix this by protecting the queue allocations and list insertion in
nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because
nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem)
to modify the attribute, this safely prevents the configfs writer from
modifying max_qid during controller creation.
Copy the max_qid from the subsystem to the controller's structure
during the allocation; ctrl->max_qid never changes as long as the
controller remains in LIVE state, so this will prevent similar race
conditions. |
| In the Linux kernel, the following vulnerability has been resolved:
clocksource/drivers/samsung_pwm: Switch to raw_spinlock_t type
Samsung PWM timer might be used as a clock source on some legacy systems.
When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a
sleeping lock (mutex-based), which must not be used in atomic context
such as hard interrupt handlers. Switch the samsung_pwm_lock to the
raw_spinlock, which remains a true non-sleeping spinlock even
under PREEMPT_RT. |
| Contributor Cross Site Scripting (XSS) in JetElements For Elementor <= 2.9.2.1 versions. |
| Contributor Cross Site Scripting (XSS) in Element Pack Elementor Addons <= 8.8.3 versions. |
