| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
iio: imu: adis16400: fix unprotected debugfs reads
adis16400_serial_number_fops is open coded and never calls
debugfs_file_get(), so debugfs_remove_recursive() does not wait for a
read in progress and unbind frees the iio_dev underneath it.
Commit ae1d37a9bb4b ("iio: imu: adis16400: use DEFINE_DEBUGFS_ATTRIBUTE
instead of DEFINE_SIMPLE_ATTRIBUTE") converted product_id and
flash_count to DEFINE_DEBUGFS_ATTRIBUTE, which protects itself, but
moved all three files to debugfs_create_file_unsafe().
serial_number prints three registers as "%.4x-%.4x-%.4x" and
DEFINE_DEBUGFS_ATTRIBUTE() formats a single u64, so it cannot be
converted without changing what the file returns. adis16475 and
adis16550 already use debugfs_create_file() for their open coded
files. Use it here too. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: imu: adis16480: fix unprotected debugfs reads
The firmware_revision and firmware_date file operations are open coded
and never call debugfs_file_get(), which debugfs_create_file_unsafe()
requires. debugfs_remove_recursive() therefore does not wait for a read
in progress, and unbind frees the iio_dev underneath it.
Use debugfs_create_file() instead. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: light: gp2ap020a00f: drain irq_work after free_irq
The threaded IRQ handler queues data->work through irq_work_queue() so
the trigger is polled from a per-CPU context. free_irq() does not flush
an irq_work the handler already queued, so after gp2ap020a00f_remove()
returns that work may still run and call iio_trigger_poll() on data->trig,
which the devm cleanup has already freed, causing a use-after-free.
Add irq_work_sync(&data->work) after free_irq() in remove() and in the
probe error path, mirroring commit 78601726d4a5 ("iio: trigger: sysfs:
fix use-after-free on remove").
Found by an in-house static analysis tool, confirmed by manual review. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: light: rohm-bu27034: Fix infinite delay on error
When reading an integration-time fails, the code will use error code to
compute the sleep time.
Fix this by using the smallest integration time as a default if
reading fails. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: pressure: bmp280: fix out-of-bounds access in sampling frequency lookup
The sampling frequency tables store each frequency as an integer part and
a fractional part in micro units. num_sampling_freq_avail is initialized
to the number of flattened integer elements because read_avail() returns
the table as a flat array.
bmp280_write_sampling_frequency(), however, indexes the same table as a
two-dimensional array and uses num_sampling_freq_avail as the number of
rows. Convert the flattened element count back to the number of rows
before iterating over the table. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: pressure: rohm-bm1390: Return error when read fails
The data reading function ignores the cached error value, and
unconditionally returns 0. Return cached 'ret' -value after stopping
the measurement so user knows if read failed and data is garbage. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: proximity: aw96103: validate firmware data length
The firmware parser reads a length from the binary header and then uses
it to walk six-byte register/value entries. A truncated firmware image
can make the parser read beyond the copied firmware buffer. A value
smaller than the four-byte count field also underflows, producing a very
large length.
Read the little-endian field with get_unaligned_le32(), as previously
proposed by David Lechner. Validate the header size, reject an
underflowed length, ensure the resulting payload is contained in the
firmware image, and require it to contain whole register/value entries. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: proximity: pulsedlight: fix iio_device left registered on PM setup failure
pm_runtime_set_active() failing in probe() jumps to error_unreg_buffer,
which only calls iio_triggered_buffer_cleanup() -- it does not undo the
iio_device_register() that already succeeded a few lines above. probe()
then returns the error, the devm-managed indio_dev is freed, but the
iio core still has it registered: the sysfs/chardev nodes stay live and
point at freed memory.
Add an error_unreg_dev label that unregisters the iio device before
falling through to the existing buffer cleanup, mirroring the teardown
order already used in lidar_remove(). |
| In the Linux kernel, the following vulnerability has been resolved:
iio: trigger: cancel reenable_work before freeing trigger
iio_trigger_notify_done_atomic() defers ->reenable() into
trig->reenable_work on the system workqueue, and the worker dereferences
the owning trigger through container_of(). Nothing cancels this work
before iio_trig_release() frees the trigger, so a worker armed by the
last in-flight IRQ can outlive the free and touch freed memory.
Cancel it at the top of iio_trig_release(), which every free path
reaches through the device core's final put_device().
Found by an in-house static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
perf: Require kernel access for text poke events
Perf events with exclude_kernel=1 can be opened without kernel perf
access. However, exclude_kernel does not suppress text-poke sideband
records. Every PERF_RECORD_TEXT_POKE is marked PERF_RECORD_MISC_KERNEL
and contains a raw kernel instruction address.
An unprivileged task can therefore open and mmap a task-local software
event with text_poke=1. Both opening a count-only tracepoint event and
configuring UDP GRO for ESP-in-UDP cause updates to inline static calls;
the observer receives the relocated addresses of the modified instructions.
For a known kernel image, any such address reveals the runtime kernel
text base despite KASLR.
Call perf_allow_kernel() whenever attr.text_poke is set, regardless of
exclude_kernel. Events that neither monitor kernel execution nor request
text-poke records retain their existing permissions. |
| An integer underflow in OpenVPN version 2.7_alpha3 through 2.7.7 on Windows and Android allows remote authenticated servers to cause a denial of service or memory disclosure via crafted domain search options |
| Authentication bypass using an alternate path or channel vulnerability in Progress MOVEit Transfer.
This issue affects MOVEit Transfer: before 2025.1.6 and from 2026.0.0 before 2026.0.4. |
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Progress MOVEit Transfer (Ad Hoc module).
This issue affects MOVEit Transfer: before 2025.1.6 and from 2026.0.0 before 2026.0.4. |
| Incorrect Authorization vulnerability in Progress MOVEit Transfer (Client Certificates module).
This issue affects MOVEit Transfer: before 2025.1.6 and from 2026.0.0 before 2026.0.4. |
| The Tutor LMS – eLearning and online course solution plugin for WordPress is vulnerable to DOM-Based Cross-Site Scripting via the 'redirect_url' parameter in versions up to, and including, 4.0.8 This is due to insufficient input validation in the Topbar component's back button handler. This makes it possible for unauthenticated attackers to inject arbitrary web scripts that execute in the victim's browser whenever the victim accesses a page that includes the malicious payload. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Atomize IRQ register read/modify/write ops
[Why]
The OTG_GLOBAL_SYNC_STATUS register controls various HW IRQ sources for
the output timing generator (OTG). VUPDATE_NO_LOCK is one of them.
To enable the IRQ, driver sets the VUPDATE_NO_LOCK_EN bit in the
GLOBAL_SYNC_STATUS register.
To ack the IRQ after it fires, the driver sets the VUPDATE_NO_LOCK_CLEAR
bit in the same GLOBAL_SYNC_STATUS register.
The bit sets are done through read/modify/write operations, which are
not atomic. Thus, the following race is possible:
Thread A: IRQ handler:
*HW IRQ fires*
# IRQ disable
val = read(GLOBAL_SYNC_STATUS)
unset(val, VUPDATE_NO_LOCK_EN)
write(val, GLOBAL_SYNC_STATUS)
# ACK reads VUPDATE_NO_LOCK_EN unset
val1 = read(GLOBAL_SYNC_STATUS)
set(val1, VUPDATE_NO_LOCK_CLEAR)
# IRQ enable
val = read(GLOBAL_SYNC_STATUS)
set(val, VUPDATE_NO_LOCK_EN)
write(val, GLOBAL_SYNC_STATUS)
# BAD! clears VUPDATE_NO_LOCK_EN
write(val1, GLOBAL_SYNC_STATUS)
Regarding the tagged Fixes: change, it appears the change made this race
more likely to occur. Since VUPDATE_NO_LOCK is now the sole IRQ source
for vblank handling, a single race on high refresh panels can lead to a
time out.
[How]
The GLOBAL_SYNC_STATUS register is only one example, other IRQ control
registers also share the same scheme. On top of GLOBAL_SYNC_STATUS,
let's clean up those as well.
To keep things simple, Let's atomize the IRQ rmw ops via a single
driver-wide spinlock. Due to the small scope of this lock, it is
unlikely to cause noticeable overhead on top of all the existing locking
within the IRQ set/handle paths.
Since DM is responsible for locking, wrap dc_interrupt_set/ack with the
spinlock in the new amdgpu_dm_irq_set/ack functions. Migrate/drop all
references in DM to dc_interrupt_set/ack to use amdgpu_dm_irq_set/ack
instead.
(cherry picked from commit 70de0a0216583a53c946155f8c8adedfdca6b4e7) |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix _gaccess_shadow_fault()
In some circumstances, it is possible that the page of nested guest
memory that is being shadowed is not present at all in the parent guest
gmap. dat_entry_walk() will not find any leaf entry and return with
-ENOENT, which will erroneously be propagated all the way to userspace.
Fix by manually calling gmap_link() on the memory of the nested guest
that is being shadowed if the mapping was not already present. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Add missing srcu in kvm_s390_set_irq_state()
Like kvm_s390_inject_vcpu(), kvm_s390_set_irq_state() also needs the
kvm->srcu or the slots lock when performing the Store status operation.
Fix by taking kvm->srcu in kvm_s390_set_irq_state(). |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Properly handle NULL pointer in dat_cond_set_storage_key()
Some callers pass NULL as oldkey. Calling page_cond_set_storage_key()
will cause that NULL pointer to get dereferenced.
Fix by checking for NULL and assigning the pointer to a dummy local
variable to avoid crashes. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix potential races in dat skey functions
When dat_cond_set_storage_key() finds a large page, it will
conditionally set the storage key in absolute memory using
large_crste_to_phys() to get the absolute address.
There is a race window between dat_entry_walk() and
large_crste_to_phys(): the large page could have been split
concurrently, and large_crste_to_phys() might be called with a crste
that does not designate a large page, leading to crashes.
Similar issues were also present in dat_set_storage_key().
dat_get_storage_key() and dat_reset_reference_bit() did instead check
for a potential concurrent splitting of the large page, but then
handled it incorrectly.
Fix by performing a READ_ONCE on the crste pointer, checking and using
the result, instead of dereferencing the pointer again. In case a race
is detacted, try dat_entry_walk() again. |
