| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
tipc: fix u16 MTU truncation in media and bearer MTU validation
Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied
MTU values but only enforce a minimum bound, not a maximum. When a user
sets the MTU to a value exceeding U16_MAX (65535), it passes validation
but is silently truncated when assigned to u16 fields l->mtu and
l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000)
truncate to 0, causing a division by zero in tipc_link_set_queue_limits()
which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing
values (e.g. 65537-131071) produce small incorrect MTU values, resulting
in link malfunction behaviors.
Crash stack (triggered as unprivileged user via user namespace):
tipc_link_set_queue_limits net/tipc/link.c:2531
tipc_link_create net/tipc/link.c:520
tipc_node_check_dest net/tipc/node.c:1279
tipc_disc_rcv net/tipc/discover.c:252
tipc_rcv net/tipc/node.c:2129
tipc_udp_recv net/tipc/udp_media.c:392
Two independent paths lack the upper bound check:
1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET)
2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET)
Fix both by rejecting MTU values above U16_MAX. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Count paired job fence as dependency in prepare_job()
The DRM scheduler's prepare_job() callback counts the remaining
non-signaled native dependencies for a job, preventing job submission
until those (plus job data and fence update) can fit in the job queue's
CCCB.
This means checking which dependencies can be waited upon in the
firmware, i.e. whether they are backed by a UFO object, i.e. whether
their drm_sched_fence::parent has been assigned to a
pvr_queue_fence::base fence. That happens when the job owning the fence
is submitted to the firmware.
Paired geometry and fragment jobs are submitted at the same time, which
means the dependency between them can't be checked this way before
submission.
Update job_count_remaining_native_deps() to take into account the
dependency between paired jobs.
This fixes cases where prepare_job() underestimated the space left in
an almost full fragment CCCB, wrongly unblocking run_job(), which then
returned early without writing the full sequence of commands to the
CCCB.
The above lead to kernel warnings such as the following and potentially
job timeouts (depending on waiters on the missing commands):
[ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47
[ 375.703160] Modules linked in:
[ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT
[ 375.703613] Tainted: [W]=WARN
[ 375.703627] Hardware name: Texas Instruments AM625 SK (DT)
[ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched]
[ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr]
[ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr]
[ 375.703921] sp : ffff800084a97650
[ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000
[ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000
[ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008
[ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000
[ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000
[ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3
[ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008
[ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000
[ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f
[ 375.704317] Call trace:
[ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P)
[ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr]
[ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr]
[ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched]
[ 375.704623] process_one_work+0x520/0x1288
[ 375.704658] worker_thread+0x3f0/0xb3c
[ 375.704680] kthread+0x334/0x3d8
[ 375.704706] ret_from_fork+0x10/0x20
[ 375.704736] ---[ end trace 0000000000000000 ]--- |
| A security flaw has been discovered in SourceCodester Simple Doctors Appointment System 1.0. This vulnerability affects unknown code of the file /admin/ajax.php?action=delete_appointment. The manipulation of the argument ID results in sql injection. The attack may be launched remotely. The exploit has been released to the public and may be used for attacks. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()
The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks
for both runtime PM and system sleep. This causes the DSI clocks to be
disabled twice: once during runtime suspend and again during system
suspend, resulting in a WARN message from the clock framework when
attempting to disable already-disabled clocks.
[ 84.384540] clk:231:5 already disabled
[ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac
...
[ 84.579183] Call trace:
[ 84.581624] clk_core_disable+0xa4/0xac
[ 84.585457] clk_disable+0x30/0x4c
[ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi]
[ 84.593651] pm_generic_suspend+0x2c/0x44
[ 84.597661] ti_sci_pd_suspend+0xbc/0x15c
[ 84.601670] dpm_run_callback+0x8c/0x14c
[ 84.605588] __device_suspend+0x1a0/0x56c
[ 84.609594] dpm_suspend+0x17c/0x21c
[ 84.613165] dpm_suspend_start+0xa0/0xa8
[ 84.617083] suspend_devices_and_enter+0x12c/0x634
[ 84.621872] pm_suspend+0x1fc/0x368
To address this issue, replace UNIVERSAL_DEV_PM_OPS() with
RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime
PM, as the DRM framework manages system-wide power transitions through
the bridge enable() and disable() hooks. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Hold a dma-buf reference for imported BOs
An imported dma-buf BO is created as a ttm_bo_type_sg BO whose
reservation object is the exporter's dma_buf->resv. The importer,
however, only takes a dma-buf reference after a successful
dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive,
so if the exporter is freed while the BO still references its resv, a
later access to that resv is a use-after-free:
Oops: general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b6b9c
Workqueue: ttm ttm_bo_delayed_delete [ttm]
RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0
This can be reached on two paths:
- dma_buf_dynamic_attach() fails, or
- ttm_bo_init_reserved() fails during BO creation.
In both cases the BO already has bo->base.resv pointing at the exporter
resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which
locks bo->base.resv asynchronously - potentially after the exporter has
been freed.
Take the dma-buf reference in xe_bo_init_locked(), before
ttm_bo_init_reserved(), so it also covers a creation failure there, and
release it in xe_ttm_bo_destroy(). The reference is held for the whole
BO lifetime, keeping the shared resv alive on every path.
v2:
- Reworked the fix to avoid creating the imported sg BO before
dma_buf_dynamic_attach() succeeds.
- Attach with importer_priv == NULL and make invalidate_mappings ignore
incomplete imports.
v3:
- Dropped the xe-side reordering approach since importer_priv must be
valid when dma_buf_dynamic_attach() publishes the attachment.
- Per Christian's suggestion on the v1 thread, keyed the check on
import_attach rather than removing the sg guard entirely.
- Fixes both xe and amdgpu in a single TTM patch.
v4:
- Moved import_attach check to after dma_resv_copy_fences() so fences
are copied before returning for successful imports (Thomas).
- Removed exporter-alive claim from commit message (Thomas).
v5:
- Add drm/xe patch to keep imported sg BOs off the LRU before attach
succeeds; the TTM fix alone is not sufficient for xe if the BO is
already LRU-visible. (Thomas)
v4 patch:
https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2
- Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4.
v6:
- Reworked the fix based on Thomas' suggestion. Instead of the TTM resv
individualization (v1-v5) plus the xe off-LRU/placement handling (v5),
just hold a dma-buf reference for the imported BO lifetime so the
shared resv can never be freed while the BO still references it.
Single xe patch, no TTM change. (Thomas)
- Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved()
so a TTM creation failure is covered too (Thomas).
- Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach
also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost
BO that outlived the exporter.
Link to v5: https://patchwork.freedesktop.org/series/169984/
v7:
- Move changelog above --- so it stays in the commit message.
- Reorder changelog entries oldest-to-newest. (Thomas)
(cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU
Setting context engine slot N into I915_ENGINE_CLASS_INVALID /
I915_ENGINE_CLASS_INVALID_NONE and attempting to apply
I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL.
Fix that.
Discovered using AI-assisted static analysis confirmed by
Intel Product Security.
(cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/gpusvm: publish dpagemap early to avoid device mapping leak on error
drm_gpusvm_get_pages() only stored the local dpagemap into
svm_pages->dpagemap on the success path. If a later page failed (e.g.
-EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap,
svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped
device_unmap() and leaked the device mappings already created.
Assign svm_pages->dpagemap when the first device page is mapped so the
err_unmap path can device_unmap() those mappings.
This issue was found by Sashiko AI review. |
| 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:
media: airspy: Return queued buffers on start_streaming() failure
The vb2 framework hands buffers to the driver via buf_queue() before
calling start_streaming(). If start_streaming() returns an error
without first returning those buffers via vb2_buffer_done(),
vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued
buffers leak.
airspy_start_streaming() returned -ENODEV early when the USB device had
been disconnected (s->udev == NULL) without returning any buffers that
buf_queue() had already accepted. Take v4l2_lock first and jump to the
existing err_clear_bit label, which already drains s->queued_bufs via
vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure"). |
| TestLink 1.9.20 and prior contains an insecure direct object reference vulnerability that allows any authenticated user, including low-privilege guest accounts, to read arbitrary attachments by supplying an integer attachment ID to the attachmentdownload.php handler without any project or role authorization check. Attackers can enumerate sequential integer IDs through the attachment download endpoint to retrieve file contents from private projects they have no membership in, bypassing the per-project access control model and exposing test specifications, requirements documents, execution evidence, and other sensitive uploaded files across the entire installation. |
| In the Linux kernel, the following vulnerability has been resolved:
media: chips-media: wave5: Move src_buf Removal to finish_encode
During encoder processing, there is a case where the IRQ response could
return the buffer back to userspace via v4l2_m2m_buf_done call. In this
time, userspace could queue up this same buffer before start_encode removes
the index from the ready queue. This would then lead to a case where the
buffer in the ready queue could be a self loop due to the
WRITE_ONCE(prev->next, new) call in __list_add.
When __list_del is finally called, the loop is already made so nothing
points back to ready queue list head and pointers are poisoned.
A buffer should not be marked as DONE before the buffer is removed from
m2m ready queue. Move removal entirely to finish_encode. |
| In the Linux kernel, the following vulnerability has been resolved:
media: cx231xx: fix devres lifetime
USB drivers bind to USB interfaces and any device managed resources
should have their lifetime tied to the interface rather than parent USB
device. This avoids issues like memory leaks when drivers are unbound
without their devices being physically disconnected (e.g. on probe
deferral or configuration changes).
Fix the driver state lifetime so that it is released on driver unbind. |
| In the Linux kernel, the following vulnerability has been resolved:
media: nxp: imx8-isi: Fix potential out-of-bounds issues
The maximum downscaling factor supported by ISI can be up to 16. Add
minimum value constraint before applying the setting to hardware.
Otherwise, the process will not respond even when Ctrl+C is executed. |
| In the Linux kernel, the following vulnerability has been resolved:
media: stm32: dcmi: unregister notifier on probe failure
dcmi_graph_init() registers the async notifier before dcmi_probe() toggles
the reset line. If reset_control_assert() or reset_control_deassert()
fails afterwards, probe returns through err_cleanup and the driver core
will not call dcmi_remove().
Unregister the notifier before cleaning it up on that error path,
matching the successful remove path and the V4L2 async notifier lifetime
rules.
[hverkuil: added Fixes tag] |
| 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. |
