| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
media: ti: vpe: unwind v4l2 device registration on probe error
If the vpe_top resource is missing, vpe_probe() returns -ENODEV after
v4l2_device_register() has succeeded. Probe failures do not call the
driver's remove callback, so the v4l2 device remains registered on that
error path.
Route that failure through the existing v4l2_device_unregister() unwind
label, matching the other errors after v4l2_device_register(). |
| Improper validation of length fields in the Apache IoTDB RPC service may allow a remote unauthenticated attacker to cause a denial of service. By sending a crafted malformed Thrift frame, an attacker can cause IoTDB to allocate an excessive amount of memory and crash with an OutOfMemoryError.
This issue affects Apache IoTDB: before 1.3.8, from 2.0.0 before 2.0.9.
Users are recommended to upgrade to version 2.0.10, which fixes the issue. |
| Remote Code Execution via Arbitrary Class Instantiation in plugin-schema-registry component in Apache Ranger <= 2.8.0.
Users are recommended to upgrade to version 2.9.0, which fixes this issue. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: Protect UUID list traversal
The hci_sync conversion moved class-of-device and EIR generation from an
HCI request built under hdev->lock to asynchronous command sync work.
The worker holds hdev->req_lock, but that lock does not serialize access
to hdev->uuids against add_uuid() and remove_uuid(), which update the
list under hdev->lock.
The following interleaving can therefore occur:
CPU0 (command sync work) CPU1 (management socket)
fetch uuid from the list
list_del(&uuid->list)
kfree(uuid)
read uuid->size
KASAN reports the resulting use-after-free:
BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0
Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
eir_create+0xb8f/0xee0
hci_update_eir_sync+0x1c0/0x330
hci_cmd_sync_work+0x13c/0x290
process_one_work+0x63a/0x1070
worker_thread+0x45b/0xd10
Allocated by task 86:
__kasan_kmalloc+0x8f/0xa0
add_uuid+0x18a/0x4b0
hci_sock_sendmsg+0x1033/0x1ea0
Freed by task 92:
__kasan_slab_free+0x43/0x70
kfree+0x131/0x3c0
remove_uuid+0x25e/0x560
hci_sock_sendmsg+0x1033/0x1ea0
Hold hdev->lock while generating and committing the class-of-device and
EIR snapshots. Release it before sending an HCI command, so controller
waits do not happen under the device lock. This protects all UUID list
walks in these paths and restores the serialization lost in the command
sync conversion. |
| In the Linux kernel, the following vulnerability has been resolved:
comedi: comedi_parport: deal with premature interrupt
Syzbot reported a general protection fault in
`comedi_get_is_subdevice_running()`, which was called from the interrupt
handler `parport_interrupt()` in the "comedi_parport" driver, but it
does not currently have a C reproducer for the problem. It's
probably due to a premature interrupt for one of two reasons:
1. The driver sets up the interrupt handler before the comedi subdevices
used by the interrupt handler have been allocated, but does not
disable the interrupt in the parallel port's CTRL register first.
2. The driver uses a user-supplied I/O port base address which Syzbot
would have supplied, but it might not be backed by real parallel port
hardware.
Change the initialization order in the driver's comedi "attach" handler
(`parport_attach()`) so that the hardware registers are initialized
before the interrupt handler is requested. This should prevent
premature interrupts occurring for real hardware.
Also add a test to the interrupt handler to ensure the comedi device is
fully attached and return early if it isn't. |
| In the Linux kernel, the following vulnerability has been resolved:
ublk: wait on ublk_dev_ready() instead of ub->completion
ub->completion is only re-armed by a successful START_USER_RECOVERY. If
the ublk server sends END_USER_RECOVERY without one - e.g. its START
failed with -EBUSY and the error was ignored - the wait is satisfied by
the stale completion of the previous recovery cycle, and the device is
marked LIVE and the requeue list kicked while the FETCH stream is still
running and ubq->canceling is still set. The kick redispatches a
previously requeued request, __ublk_queue_rq_common() sees ->canceling
and parks it again via __ublk_abort_rq(), and after the last FETCH
clears ->canceling nothing ever kicks the requeue list again: the
request is stranded there while holding its tag. If it is the flush
machinery's flush_rq, every subsequent fsync piles up in uninterruptible
sleep and teardown hangs on tag draining. This matches a report of a
lost PREFLUSH with ext4 on top of ublk after daemon crash recovery.
ub->completion is an edge-triggered latch used as a proxy for the level
condition "every queue has fetched all I/O commands", which can regress
(F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop
it and wait on the real condition instead: the new helper
ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via
wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then
re-checks it under ub->mutex, waiting again on regression, and returns
with the mutex held and readiness guaranteed.
Readiness becomes true in the same ub->mutex critical section that
clears the last queue's ->canceling, so END_USER_RECOVERY marks the
device LIVE and kicks the requeue list strictly after ->canceling
clears. The wait stays interruptible, so a server whose daemon died can
still be signalled out. For ublk_ctrl_start_dev() this replaces the
fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting
until the device is ready again. |
| Frappe is a full-stack web application framework. Prior to 16.20.0 and 15.112.0, unrestricted access to a Document Follow API (update_follow) is possible for an authenticated user.
This issue is fixed in versions 16.20.0 and 15.112.0. |
| In the Linux kernel, the following vulnerability has been resolved:
libceph: Reject monmaps advertising zero monitors
A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a
monitor to the client. This monmap contains information about the
existing monitors in the cluster. Currently, a monmap indicating that
there are zero monitors in the cluster is treated as valid. However, it
is impossible to have zero monitors in the cluster and still receive a
valid monmap from a monitor. Therefore, such a monmap must be corrupted
and should be treated as invalid. Furthermore, a monmap with a monitor
count of zero can subsequently crash the client when attempting to open
a session with a monitor in __open_session(). This happens because the
"BUG_ON(monc->monmap->num_mon < 1)" assertion in pick_new_mon() is
triggered.
This patch extends a check in ceph_monmap_decode() to also reject
arriving mon_maps with num_mon == 0 rather than only with
num_mon > CEPH_MAX_MON.
[ idryomov: drop "log output for unusual values of num_mon" part ] |
| In the Linux kernel, the following vulnerability has been resolved:
ftrace: Add global mutex to serialize trace_parser access
In ftrace, the trace_parser structure is allocated and initialized when
a trace file is opened, and is subsequently used across write and release
handlers to parse user input.
The affected handler paths and their specific functions are:
- Open paths: ftrace_regex_open(), ftrace_graph_open()
- Write paths: ftrace_regex_write(), ftrace_graph_write()
- Release paths: ftrace_regex_release(), ftrace_graph_release()
If userspace opens a trace file descriptor and shares it across multiple
threads, concurrent write calls will race on the parser's internal state,
specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted
input or undefined behavior.
Fix this by adding a global mutex, parser_lock, to serialize all access
to trace_parser across write and release paths, preventing concurrent
corruption of parser state. |
| In the Linux kernel, the following vulnerability has been resolved:
iomap: fix out-of-bounds bitmap_set() with zero-length range
ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk
as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the
unsigned subtraction underflows to SIZE_MAX, producing a huge
last_blk and nr_blks value that causes bitmap_set() to write far
beyond the ifs->state allocation.
Regarding ifs_set_range_uptodate(), it is temporarily safe because len
cannot be passed in as 0. However, for ifs_set_range_dirty() this is
reachable from __iomap_write_end(): when copy_folio_from_iter_atomic()
returns 0 (e.g. user buffer fault) and the folio is already uptodate,
the guard at the top of __iomap_write_end() does not trigger because
!folio_test_uptodate() is false, and iomap_set_range_dirty() is called
with copied == 0.
Add a !len guard to both functions before the computation, so that a
zero-length range is a no-op. |
| In the Linux kernel, the following vulnerability has been resolved:
phonet: pep: fix use-after-free in pep_get_sb()
pep_get_sb() doesn't consider that pskb_may_pull() might have relocated
the skb data, and continue to access the older pointer, causing UAF.
Reproduced under KASAN:
BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0
Read of size 1 at addr ff11000105510f50 by task repro/157
pep_get_sb+0x234/0x3b0
pipe_handler_do_rcv+0x5f7/0xa10
pep_do_rcv+0x203/0x410
__sk_receive_skb+0x471/0x4a0
phonet_rcv+0x5b3/0x6c0
__netif_receive_skb+0xcc/0x1d0
Refetch the header with skb_header_pointer() after pskb_may_pull(), so
the possibly stale pointer is no longer dereferenced. There are better
ways to solve this, but, this is the less instrusive one. |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
super: fix emergency thaw deadlock on frozen block devices
do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount
exclusively. If the block device was frozen via bdev_freeze() dropping
the last block layer freeze reference calls fs_bdev_thaw() which
reacquires s_umount:
do_thaw_all_callback(sb)
super_lock_excl(sb) # holds sb->s_umount
bdev_thaw(sb->s_bdev)
mutex_lock(&bdev->bd_fsfreeze_mutex)
# bd_fsfreeze_count drops 1 -> 0
bd_holder_ops->thaw == fs_bdev_thaw
get_bdev_super(bdev)
bdev_super_lock(bdev, true)
super_lock(sb, true)
down_write(&sb->s_umount) # same task: deadlock
The emergency thaw worker deadlocks against itself holding both
s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount,
freeze, or thaw of that filesystem and block device.
[ 81.878470] sysrq: Show Blocked State
[ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000
[ 81.884876] Workqueue: events do_thaw_all
[ 81.886656] Call Trace:
[ 81.887759] <TASK>
[ 81.888763] __schedule+0x579/0x1420
[ 81.890372] schedule+0x3a/0x100
[ 81.891794] schedule_preempt_disabled+0x15/0x30
[ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900
[ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10
[ 81.896528] down_write+0xbd/0xc0
[ 81.897505] super_lock+0x91/0x180
[ 81.898457] ? __mutex_lock+0xa99/0x1140
[ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400
[ 81.902069] bdev_super_lock+0x5b/0x150
[ 81.903132] get_bdev_super+0x10/0x60
[ 81.904042] fs_bdev_thaw+0x23/0xf0
[ 81.904755] bdev_thaw+0x82/0x100
[ 81.905484] do_thaw_all_callback+0x2c/0x50
[ 81.906298] __iterate_supers+0x5d/0x130
[ 81.907067] do_thaw_all+0x20/0x40
[ 81.907739] process_one_work+0x206/0x5e0
[ 81.908545] worker_thread+0x1e2/0x3c0
[ 81.909339] ? __pfx_worker_thread+0x10/0x10
[ 81.910171] kthread+0xf4/0x130
[ 81.910799] ? __pfx_kthread+0x10/0x10
[ 81.911528] ret_from_fork+0x2e2/0x3b0
[ 81.912259] ? __pfx_kthread+0x10/0x10
[ 81.913010] ret_from_fork_asm+0x1a/0x30
[ 81.913806] </TASK>
bdev_super_lock() even documents the violated requirement with
lockdep_assert_not_held(&sb->s_umount).
Acquiring bd_fsfreeze_mutex under s_umount also inverts the
bd_fsfreeze_mutex vs. s_umount ordering established by
bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer
freeze even when the recursive path isn't hit.
Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin
the superblock with an active reference instead as
filesystems_freeze_callback() does. The active reference keeps the
superblock from being shut down and so ->s_bdev stays valid without
holding s_umount. The block-layer-held freeze is dropped by
fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as
a regular unfreeze would and thaw_super_locked() handles
filesystem-level freezes as before.
The emergency thaw path has deadlocked like this in one form or
another for a long long time but the current exclusively-held
shape dates back to commit [1] where thaw_bdev() already ended in
thaw_super() with s_umount held by do_thaw_all_callback(). |
| In the Linux kernel, the following vulnerability has been resolved:
gve: fix Rx queue stall on alloc failure
When the system is under extreme memory pressure, page allocations can
fail during the Rx buffer refill loop. If the number of buffers posted
to hardware falls below a critical low threshold and the refill loop
exits due to allocation failures, the queue can stall:
1. The device drops incoming packets because there are no descriptors.
2. Since no packets are processed, no Rx completions are generated.
3. Because no completions occur, NAPI is never scheduled, preventing
the refill loop from running again even after memory is freed.
This results in a permanent queue stall.
Resolve this by introducing a starvation recovery timer for each Rx queue.
If the number of buffers posted to hardware falls below a critical low
threshold, start a timer to periodically reschedule NAPI. Once NAPI runs
and successfully refills the queue above the threshold, the timer is
not rescheduled.
The threshold is set to 32 because a single maximum-sized Receive Segment
Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path.
Lower thresholds (such as 8 or 16) would be insufficient to process a
complete maximum-sized RSC packet, risking packet drops or unexpected
hardware behavior under memory pressure. Setting the threshold to 32
guarantees a safe margin to handle at least one full RSC packet. |
| The Code Embed WordPress plugin prior to version 2.6.1 is vulnerable to stored Cross-Site Scripting (XSS) through the external URL embed feature in post content. The vulnerable code scans rendered content for URL embed tokens, fetches the remote URL, and inserts the remote response body into the page without output sanitization or an `unfiltered_html` capability check. This allows a Contributor attacker to submit a pending post containing an inert-looking URL token that executes attacker-controlled JavaScript when an Administrator or Editor previews or reviews the post. This is distinct from CVE-2026-2512, which affected custom field meta values up to version 2.5.1. This vector affects version 2.6 and uses the documented external URL embed feature in post content. This particular issue is patched in version 2.6.1. |
| In the Linux kernel, the following vulnerability has been resolved:
pppoe: reload header pointer after dev_hard_header()
pppoe_sendmsg() saves a pointer to the PPPoE header before calling
dev_hard_header(). Device header callbacks are allowed to reallocate the
skb head, invalidating pointers into it.
This can happen when a send is blocked in copy_from_user() while the first
non-Ethernet port is added to an empty team device. The team's delegated
GRE header callback then expands the skb head. PPPoE subsequently writes
six bytes through the stale pointer into the freed head.
Reload the PPPoE header through the skb's network-header offset after
device header creation. pskb_expand_head() updates that offset when it
relocates the head. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx12.1: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit e4d99e04b2e9b13b97d3b17804c735f62689db23) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/vcn4: avoid rereading IB param length
Reuse the parameter length returned by
vcn_v4_0_enc_find_ib_param() instead of rereading it from
the IB.
This avoids a potential TOCTOU issue if the IB contents
change between reads.
(cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: invoke pm_genpd_remove() before freeing genpd
Call pm_genpd_remove() to unregister from global list prior to releasing
acp_genpd memory, and clear the pointer after free.
(cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2) |
