| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability in Grafana Tempo exposes the S3 SSE-C encryption key in plaintext through the /status/config endpoint, potentially allowing unauthorized users to obtain the key used to encrypt trace data stored in S3.
Thanks to william_goodfellow for reporting this vulnerability. |
| The dashboard permissions API does not verify the target dashboard scope and only checks the dashboards.permissions:* action. As a result, a user who has permission management rights on one dashboard can read and modify permissions on other dashboards. This is an organization‑internal privilege escalation. |
| When using public dashboards and direct data-sources, all direct data-sources' passwords are exposed despite not being used in dashboards.
No passwords of proxied data-sources are exposed. We encourage all direct data-sources to be converted to proxied data-sources as far as possible to improve your deployments' security. |
| The OpenFeature feature toggle evaluation endpoint reads unbounded values into memory, which can cause out-of-memory crashes. |
| The Grafana MSSQL data source plugin contains a logic flaw that allows a low-privileged user (Viewer) to bypass API restrictions and trigger a catastrophic Out-Of-Memory (OOM) memory exhaustion, crashing the host container. |
| A chained attack via SQL Expressions and a Grafana Enterprise plugin can lead to a remote arbitrary code execution impact (RCE). This is enabled by a feature in Grafana (OSS), so all users are always recommended to update to avoid future attack vectors going this path.
Only instances with the sqlExpressions feature toggle enabled are vulnerable.
Only instances in the following version ranges are affected:
- 11.6.0 (inclusive) to 11.6.14 (exclusive): 11.6.14 has the fix. 11.5 and below are not affected.
- 12.0.0 (inclusive) to 12.1.10 (exclusive): 12.1.10 has the fix. 12.0 did not receive an update, as it is end-of-life.
- 12.2.0 (inclusive) to 12.2.8 (exclusive): 12.2.8 has the fix.
- 12.3.0 (inclusive) to 12.3.6 (exclusive): 12.3.6 has the fix.
- 12.4.0 (inclusive) to 12.4.2 (exclusive): 12.4.2 has the fix. 13.0.0 and above also have the fix: no v13 release is affected. |
| Every uncached /avatar/:hash request spawns a goroutine that refreshes the Gravatar image. If the refresh sits in the 10-slot worker queue longer than three seconds, the handler times out and stops listening for the result, so that goroutine blocks forever trying to send on an unbuffered channel. Sustained traffic with random hashes keeps tripping this timeout, so goroutine count grows linearly, eventually exhausting memory and causing Grafana to crash on some systems. |
| Public dashboards with annotations enabled did not limit their annotation timerange to the locked timerange of the public dashboard. This means one could read the entire history of annotations visible on the specific dashboard, even those outside the locked timerange.
This did not leak any annotations that would not otherwise be visible on the public dashboard. |
| A testdata data-source can be used to trigger out-of-memory crashes in Grafana. |
| Stack traces in Grafana's Explore Traces view can be rendered as raw HTML, and thus inject malicious JavaScript in the browser. This would require malicious JavaScript to be entered into the stack trace field.
Only datasources with the Jaeger HTTP API appear to be affected; Jaeger gRPC and Tempo do not appear affected whatsoever. |
| SCIM provisioning was introduced in Grafana Enterprise and Grafana Cloud in April to improve how organizations manage users and teams in Grafana by introducing automated user lifecycle management.
In Grafana versions 12.x where SCIM provisioning is enabled and configured, a vulnerability in user identity handling allows a malicious or compromised SCIM client to provision a user with a numeric externalId, which in turn could allow to override internal user IDs and lead to impersonation or privilege escalation.
This vulnerability applies only if all of the following conditions are met:
- `enableSCIM` feature flag set to true
- `user_sync_enabled` config option in the `[auth.scim]` block set to true |
| In the Linux kernel, the following vulnerability has been resolved:
PM: runtime: Fix a race condition related to device removal
The following code in pm_runtime_work() may dereference the dev->parent
pointer after the parent device has been freed:
/* Maybe the parent is now able to suspend. */
if (parent && !parent->power.ignore_children) {
spin_unlock(&dev->power.lock);
spin_lock(&parent->power.lock);
rpm_idle(parent, RPM_ASYNC);
spin_unlock(&parent->power.lock);
spin_lock(&dev->power.lock);
}
Fix this by inserting a flush_work() call in pm_runtime_remove().
Without this patch blktest block/001 triggers the following complaint
sporadically:
BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160
Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081
Workqueue: pm pm_runtime_work
Call Trace:
<TASK>
dump_stack_lvl+0x61/0x80
print_address_description.constprop.0+0x8b/0x310
print_report+0xfd/0x1d7
kasan_report+0xd8/0x1d0
__kasan_check_byte+0x42/0x60
lock_acquire.part.0+0x38/0x230
lock_acquire+0x70/0x160
_raw_spin_lock+0x36/0x50
rpm_suspend+0xc6a/0xfe0
rpm_idle+0x578/0x770
pm_runtime_work+0xee/0x120
process_one_work+0xde3/0x1410
worker_thread+0x5eb/0xfe0
kthread+0x37b/0x480
ret_from_fork+0x6cb/0x920
ret_from_fork_asm+0x11/0x20
</TASK>
Allocated by task 4314:
kasan_save_stack+0x2a/0x50
kasan_save_track+0x18/0x40
kasan_save_alloc_info+0x3d/0x50
__kasan_kmalloc+0xa0/0xb0
__kmalloc_noprof+0x311/0x990
scsi_alloc_target+0x122/0xb60 [scsi_mod]
__scsi_scan_target+0x101/0x460 [scsi_mod]
scsi_scan_channel+0x179/0x1c0 [scsi_mod]
scsi_scan_host_selected+0x259/0x2d0 [scsi_mod]
store_scan+0x2d2/0x390 [scsi_mod]
dev_attr_store+0x43/0x80
sysfs_kf_write+0xde/0x140
kernfs_fop_write_iter+0x3ef/0x670
vfs_write+0x506/0x1470
ksys_write+0xfd/0x230
__x64_sys_write+0x76/0xc0
x64_sys_call+0x213/0x1810
do_syscall_64+0xee/0xfc0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
Freed by task 4314:
kasan_save_stack+0x2a/0x50
kasan_save_track+0x18/0x40
kasan_save_free_info+0x3f/0x50
__kasan_slab_free+0x67/0x80
kfree+0x225/0x6c0
scsi_target_dev_release+0x3d/0x60 [scsi_mod]
device_release+0xa3/0x220
kobject_cleanup+0x105/0x3a0
kobject_put+0x72/0xd0
put_device+0x17/0x20
scsi_device_dev_release+0xacf/0x12c0 [scsi_mod]
device_release+0xa3/0x220
kobject_cleanup+0x105/0x3a0
kobject_put+0x72/0xd0
put_device+0x17/0x20
scsi_device_put+0x7f/0xc0 [scsi_mod]
sdev_store_delete+0xa5/0x120 [scsi_mod]
dev_attr_store+0x43/0x80
sysfs_kf_write+0xde/0x140
kernfs_fop_write_iter+0x3ef/0x670
vfs_write+0x506/0x1470
ksys_write+0xfd/0x230
__x64_sys_write+0x76/0xc0
x64_sys_call+0x213/0x1810 |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()
In DecodeQ931(), the UserUserIE code path reads a 16-bit length from
the packet, then decrements it by 1 to skip the protocol discriminator
byte before passing it to DecodeH323_UserInformation(). If the encoded
length is 0, the decrement wraps to -1, which is then passed as a
large value to the decoder, leading to an out-of-bounds read.
Add a check to ensure len is positive after the decrement. |
| Juju is an open source application orchestration engine that enables any application operation on any infrastructure at any scale through special operators called ‘charms’. From versions 2.9 to before 2.9.56 and 3.6 to before 3.6.19, it is possible that a compromised workload machine under a Juju controller can read any log file for any entity in any model at any level. This issue has been patched in versions 2.9.56 and 3.6.19. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/sva: Fix crash in iommu_sva_unbind_device()
domain->mm->iommu_mm can be freed by iommu_domain_free():
iommu_domain_free()
mmdrop()
__mmdrop()
mm_pasid_drop()
After iommu_domain_free() returns, accessing domain->mm->iommu_mm may
dereference a freed mm structure, leading to a crash.
Fix this by moving the code that accesses domain->mm->iommu_mm to before
the call to iommu_domain_free(). |
| FastMCP is the standard framework for building MCP applications. Prior to version 3.2.0, server names containing shell metacharacters (e.g., &) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string. This issue has been patched in version 3.2.0. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in durable v2 replay of active file handles
parse_durable_handle_context() unconditionally assigns dh_info->fp->conn
to the current connection when handling a DURABLE_REQ_V2 context with
SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by
fp->conn, so it returns file handles that are already actively connected.
The unconditional overwrite replaces fp->conn, and when the overwriting
connection is subsequently freed, __ksmbd_close_fd() dereferences the
stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a
use-after-free.
KASAN report:
[ 7.349357] ==================================================================
[ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0
[ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108
[ 7.350010]
[ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY
[ 7.350068] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work
[ 7.350083] Call Trace:
[ 7.350087] <TASK>
[ 7.350087] dump_stack_lvl+0x64/0x80
[ 7.350094] print_report+0xce/0x660
[ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 7.350101] ? __pfx___mod_timer+0x10/0x10
[ 7.350106] ? _raw_spin_lock+0x75/0xe0
[ 7.350108] kasan_report+0xce/0x100
[ 7.350109] ? _raw_spin_lock+0x75/0xe0
[ 7.350114] kasan_check_range+0x105/0x1b0
[ 7.350116] _raw_spin_lock+0x75/0xe0
[ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10
[ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780
[ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0
[ 7.350128] __ksmbd_close_fd+0x27f/0xaf0
[ 7.350131] ksmbd_close_fd+0x135/0x1b0
[ 7.350133] smb2_close+0xb19/0x15b0
[ 7.350142] ? __pfx_smb2_close+0x10/0x10
[ 7.350143] ? xas_load+0x18/0x270
[ 7.350146] ? _raw_spin_lock+0x84/0xe0
[ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10
[ 7.350150] ? _raw_spin_unlock+0xe/0x30
[ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0
[ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0
[ 7.350154] handle_ksmbd_work+0x40f/0x1080
[ 7.350156] process_one_work+0x5fa/0xef0
[ 7.350162] ? assign_work+0x122/0x3e0
[ 7.350163] worker_thread+0x54b/0xf70
[ 7.350165] ? __pfx_worker_thread+0x10/0x10
[ 7.350166] kthread+0x346/0x470
[ 7.350170] ? recalc_sigpending+0x19b/0x230
[ 7.350176] ? __pfx_kthread+0x10/0x10
[ 7.350178] ret_from_fork+0x4fb/0x6c0
[ 7.350183] ? __pfx_ret_from_fork+0x10/0x10
[ 7.350185] ? __switch_to+0x36c/0xbe0
[ 7.350188] ? __pfx_kthread+0x10/0x10
[ 7.350190] ret_from_fork_asm+0x1a/0x30
[ 7.350197] </TASK>
[ 7.350197]
[ 7.355160] Allocated by task 123:
[ 7.355261] kasan_save_stack+0x33/0x60
[ 7.355373] kasan_save_track+0x14/0x30
[ 7.355484] __kasan_kmalloc+0x8f/0xa0
[ 7.355593] ksmbd_conn_alloc+0x44/0x6d0
[ 7.355711] ksmbd_kthread_fn+0x243/0xd70
[ 7.355839] kthread+0x346/0x470
[ 7.355942] ret_from_fork+0x4fb/0x6c0
[ 7.356051] ret_from_fork_asm+0x1a/0x30
[ 7.356164]
[ 7.356214] Freed by task 134:
[ 7.356305] kasan_save_stack+0x33/0x60
[ 7.356416] kasan_save_track+0x14/0x30
[ 7.356527] kasan_save_free_info+0x3b/0x60
[ 7.356646] __kasan_slab_free+0x43/0x70
[ 7.356761] kfree+0x1ca/0x430
[ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0
[ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40
[ 7.357138] kthread+0x346/0x470
[ 7.357240] ret_from_fork+0x4fb/0x6c0
[ 7.357350] ret_from_fork_asm+0x1a/0x30
[ 7.357463]
[ 7.357513] The buggy address belongs to the object at ffff8881056ac000
[ 7.357513] which belongs to the cache kmalloc-1k of size 1024
[ 7.357857] The buggy address is located 396 bytes inside of
[ 7.357857] freed 1024-byte region
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
perf/x86: Move event pointer setup earlier in x86_pmu_enable()
A production AMD EPYC system crashed with a NULL pointer dereference
in the PMU NMI handler:
BUG: kernel NULL pointer dereference, address: 0000000000000198
RIP: x86_perf_event_update+0xc/0xa0
Call Trace:
<NMI>
amd_pmu_v2_handle_irq+0x1a6/0x390
perf_event_nmi_handler+0x24/0x40
The faulting instruction is `cmpq $0x0, 0x198(%rdi)` with RDI=0,
corresponding to the `if (unlikely(!hwc->event_base))` check in
x86_perf_event_update() where hwc = &event->hw and event is NULL.
drgn inspection of the vmcore on CPU 106 showed a mismatch between
cpuc->active_mask and cpuc->events[]:
active_mask: 0x1e (bits 1, 2, 3, 4)
events[1]: 0xff1100136cbd4f38 (valid)
events[2]: 0x0 (NULL, but active_mask bit 2 set)
events[3]: 0xff1100076fd2cf38 (valid)
events[4]: 0xff1100079e990a90 (valid)
The event that should occupy events[2] was found in event_list[2]
with hw.idx=2 and hw.state=0x0, confirming x86_pmu_start() had run
(which clears hw.state and sets active_mask) but events[2] was
never populated.
Another event (event_list[0]) had hw.state=0x7 (STOPPED|UPTODATE|ARCH),
showing it was stopped when the PMU rescheduled events, confirming the
throttle-then-reschedule sequence occurred.
The root cause is commit 7e772a93eb61 ("perf/x86: Fix NULL event access
and potential PEBS record loss") which moved the cpuc->events[idx]
assignment out of x86_pmu_start() and into step 2 of x86_pmu_enable(),
after the PERF_HES_ARCH check. This broke any path that calls
pmu->start() without going through x86_pmu_enable() -- specifically
the unthrottle path:
perf_adjust_freq_unthr_events()
-> perf_event_unthrottle_group()
-> perf_event_unthrottle()
-> event->pmu->start(event, 0)
-> x86_pmu_start() // sets active_mask but not events[]
The race sequence is:
1. A group of perf events overflows, triggering group throttle via
perf_event_throttle_group(). All events are stopped: active_mask
bits cleared, events[] preserved (x86_pmu_stop no longer clears
events[] after commit 7e772a93eb61).
2. While still throttled (PERF_HES_STOPPED), x86_pmu_enable() runs
due to other scheduling activity. Stopped events that need to
move counters get PERF_HES_ARCH set and events[old_idx] cleared.
In step 2 of x86_pmu_enable(), PERF_HES_ARCH causes these events
to be skipped -- events[new_idx] is never set.
3. The timer tick unthrottles the group via pmu->start(). Since
commit 7e772a93eb61 removed the events[] assignment from
x86_pmu_start(), active_mask[new_idx] is set but events[new_idx]
remains NULL.
4. A PMC overflow NMI fires. The handler iterates active counters,
finds active_mask[2] set, reads events[2] which is NULL, and
crashes dereferencing it.
Move the cpuc->events[hwc->idx] assignment in x86_pmu_enable() to
before the PERF_HES_ARCH check, so that events[] is populated even
for events that are not immediately started. This ensures the
unthrottle path via pmu->start() always finds a valid event pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free of share_conf in compound request
smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without
validating tcon->t_state. ksmbd_tree_conn_lookup() checks t_state ==
TREE_CONNECTED on the initial lookup path, but the compound reuse path
bypasses this check entirely.
If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state
to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(),
subsequent commands dereference the freed share_conf through
work->tcon->share_conf.
KASAN report:
[ 4.144653] ==================================================================
[ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70
[ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44
[ 4.145772]
[ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY
[ 4.145871] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work
[ 4.145888] Call Trace:
[ 4.145892] <TASK>
[ 4.145894] dump_stack_lvl+0x64/0x80
[ 4.145910] print_report+0xce/0x660
[ 4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 4.145928] ? smb2_write+0xc74/0xe70
[ 4.145931] kasan_report+0xce/0x100
[ 4.145934] ? smb2_write+0xc74/0xe70
[ 4.145937] smb2_write+0xc74/0xe70
[ 4.145939] ? __pfx_smb2_write+0x10/0x10
[ 4.145942] ? _raw_spin_unlock+0xe/0x30
[ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0
[ 4.145948] ? smb2_tree_disconnect+0x31c/0x480
[ 4.145951] handle_ksmbd_work+0x40f/0x1080
[ 4.145953] process_one_work+0x5fa/0xef0
[ 4.145962] ? assign_work+0x122/0x3e0
[ 4.145964] worker_thread+0x54b/0xf70
[ 4.145967] ? __pfx_worker_thread+0x10/0x10
[ 4.145970] kthread+0x346/0x470
[ 4.145976] ? recalc_sigpending+0x19b/0x230
[ 4.145980] ? __pfx_kthread+0x10/0x10
[ 4.145984] ret_from_fork+0x4fb/0x6c0
[ 4.145992] ? __pfx_ret_from_fork+0x10/0x10
[ 4.145995] ? __switch_to+0x36c/0xbe0
[ 4.145999] ? __pfx_kthread+0x10/0x10
[ 4.146003] ret_from_fork_asm+0x1a/0x30
[ 4.146013] </TASK>
[ 4.146014]
[ 4.149858] Allocated by task 44:
[ 4.149953] kasan_save_stack+0x33/0x60
[ 4.150061] kasan_save_track+0x14/0x30
[ 4.150169] __kasan_kmalloc+0x8f/0xa0
[ 4.150274] ksmbd_share_config_get+0x1dd/0xdd0
[ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600
[ 4.150529] smb2_tree_connect+0x2e6/0x1000
[ 4.150645] handle_ksmbd_work+0x40f/0x1080
[ 4.150761] process_one_work+0x5fa/0xef0
[ 4.150873] worker_thread+0x54b/0xf70
[ 4.150978] kthread+0x346/0x470
[ 4.151071] ret_from_fork+0x4fb/0x6c0
[ 4.151176] ret_from_fork_asm+0x1a/0x30
[ 4.151286]
[ 4.151332] Freed by task 44:
[ 4.151418] kasan_save_stack+0x33/0x60
[ 4.151526] kasan_save_track+0x14/0x30
[ 4.151634] kasan_save_free_info+0x3b/0x60
[ 4.151751] __kasan_slab_free+0x43/0x70
[ 4.151861] kfree+0x1ca/0x430
[ 4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190
[ 4.152088] smb2_tree_disconnect+0x1cd/0x480
[ 4.152211] handle_ksmbd_work+0x40f/0x1080
[ 4.152326] process_one_work+0x5fa/0xef0
[ 4.152438] worker_thread+0x54b/0xf70
[ 4.152545] kthread+0x346/0x470
[ 4.152638] ret_from_fork+0x4fb/0x6c0
[ 4.152743] ret_from_fork_asm+0x1a/0x30
[ 4.152853]
[ 4.152900] The buggy address belongs to the object at ffff88810430c180
[ 4.152900] which belongs to the cache kmalloc-96 of size 96
[ 4.153226] The buggy address is located 20 bytes inside of
[ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0)
[ 4.153549]
[ 4.153596] The buggy address belongs to the physical page:
[ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c
[ 4.154000] flags: 0x
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
arm_mpam: Fix null pointer dereference when restoring bandwidth counters
When an MSC supporting memory bandwidth monitoring is brought offline and
then online, mpam_restore_mbwu_state() calls __ris_msmon_read() via ipi to
restore the configuration of the bandwidth counters. It doesn't care about
the value read, mbwu_arg.val, and doesn't set it leading to a null pointer
dereference when __ris_msmon_read() adds to it. This results in a kernel
oops with a call trace such as:
Call trace:
__ris_msmon_read+0x19c/0x64c (P)
mpam_restore_mbwu_state+0xa0/0xe8
smp_call_on_cpu_callback+0x1c/0x38
process_one_work+0x154/0x4b4
worker_thread+0x188/0x310
kthread+0x11c/0x130
ret_from_fork+0x10/0x20
Provide a local variable for val to avoid __ris_msmon_read() dereferencing
a null pointer when adding to val. |
