| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An authentication bypass vulnerability in Kentico Xperience allows authentication bypass via the Staging Sync Server component password handling for the server defined None type. Authentication bypass allows an attacker to control administrative objects.This issue affects Xperience through 13.0.178. |
| The Kentico Xperience application does not fully validate or filter files uploaded via the multiple-file upload functionality, which allows for stored XSS.This issue affects Kentico Xperience through 13.0.178. |
| An authenticated remote code execution in Kentico Xperience allows authenticated users Staging Sync Server to upload arbitrary data to path relative locations. This results in path traversal and arbitrary file upload, including content that can be executed server side leading to remote code execution.This issue affects Kentico Xperience through 13.0.178. |
| SysAid On-Prem versions <= 23.3.40 are vulnerable to an unauthenticated XML External Entity (XXE) vulnerability in the Checkin processing functionality, allowing for administrator account takeover and file read primitives. |
| SysAid On-Prem versions <= 23.3.40 are vulnerable to an unauthenticated XML External Entity (XXE) vulnerability in the Server URL processing functionality, allowing for administrator account takeover and file read primitives. |
| SysAid On-Prem versions <= 23.3.40 are vulnerable to an unauthenticated XML External Entity (XXE) vulnerability in the lshw processing functionality, allowing for administrator account takeover and file read primitives. |
| In the Linux kernel, the following vulnerability has been resolved:
virtio-net: xsk: rx: fix the frame's length check
When calling buf_to_xdp, the len argument is the frame data's length
without virtio header's length (vi->hdr_len). We check that len with
xsk_pool_get_rx_frame_size() + vi->hdr_len
to ensure the provided len does not larger than the allocated chunk
size. The additional vi->hdr_len is because in virtnet_add_recvbuf_xsk,
we use part of XDP_PACKET_HEADROOM for virtio header and ask the vhost
to start placing data from
hard_start + XDP_PACKET_HEADROOM - vi->hdr_len
not
hard_start + XDP_PACKET_HEADROOM
But the first buffer has virtio_header, so the maximum frame's length in
the first buffer can only be
xsk_pool_get_rx_frame_size()
not
xsk_pool_get_rx_frame_size() + vi->hdr_len
like in the current check.
This commit adds an additional argument to buf_to_xdp differentiate
between the first buffer and other ones to correctly calculate the maximum
frame's length. |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix double put of request
If a netfs request finishes during the pause loop, it will have the ref
that belongs to the IN_PROGRESS flag removed at that point - however, if it
then goes to the final wait loop, that will *also* put the ref because it
sees that the IN_PROGRESS flag is clear and incorrectly assumes that this
happened when it called the collector.
In fact, since IN_PROGRESS is clear, we shouldn't call the collector again
since it's done all the cleanup, such as calling ->ki_complete().
Fix this by making netfs_collect_in_app() just return, indicating that
we're done if IN_PROGRESS is removed. |
| In the Linux kernel, the following vulnerability has been resolved:
genirq/irq_sim: Initialize work context pointers properly
Initialize `ops` member's pointers properly by using kzalloc() instead of
kmalloc() when allocating the simulation work context. Otherwise the
pointers contain random content leading to invalid dereferencing. |
| In the Linux kernel, the following vulnerability has been resolved:
riscv: cpu_ops_sbi: Use static array for boot_data
Since commit 6b9f29b81b15 ("riscv: Enable pcpu page first chunk
allocator"), if NUMA is enabled, the page percpu allocator may be used
on very sparse configurations, or when requested on boot with
percpu_alloc=page.
In that case, percpu data gets put in the vmalloc area. However,
sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data,
and simply assumes that __pa() would work. This causes the just started
hart to immediately access an invalid address and hang.
Fortunately, struct sbi_hart_boot_data is not too large, so we can
simply allocate an array for boot_data statically, putting it in the
kernel image.
This fixes NUMA=y SMP boot on Sophgo SG2042.
To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then
run with:
qemu-system-riscv64 -M virt -smp 2 -nographic \
-kernel arch/riscv/boot/Image \
-append "percpu_alloc=page"
Kernel output:
[ 0.000000] Booting Linux on hartid 0
[ 0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025
...
[ 0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712
...
[ 0.083192] smp: Bringing up secondary CPUs ...
[ 0.086722] ------------[ cut here ]------------
[ 0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080)
[ 0.088001] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/physaddr.c:14 __virt_to_phys+0xae/0xe8
[ 0.088376] Modules linked in:
[ 0.088656] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0-rc1 #11 NONE
[ 0.088833] Hardware name: riscv-virtio,qemu (DT)
[ 0.088948] epc : __virt_to_phys+0xae/0xe8
[ 0.089001] ra : __virt_to_phys+0xae/0xe8
[ 0.089037] epc : ffffffff80021eaa ra : ffffffff80021eaa sp : ff2000000004bbc0
[ 0.089057] gp : ffffffff817f49c0 tp : ff60000001d60000 t0 : 5f6f745f74726976
[ 0.089076] t1 : 0000000000000076 t2 : 705f6f745f747269 s0 : ff2000000004bbe0
[ 0.089095] s1 : ff2000000001d080 a0 : 0000000000000000 a1 : 0000000000000000
[ 0.089113] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
[ 0.089131] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
[ 0.089155] s2 : ffffffff8130dc00 s3 : 0000000000000001 s4 : 0000000000000001
[ 0.089174] s5 : ffffffff8185eff8 s6 : ff2000007f1eb000 s7 : ffffffff8002a2ec
[ 0.089193] s8 : 0000000000000001 s9 : 0000000000000001 s10: 0000000000000000
[ 0.089211] s11: 0000000000000000 t3 : ffffffff8180a9f7 t4 : ffffffff8180a9f7
[ 0.089960] t5 : ffffffff8180a9f8 t6 : ff2000000004b9d8
[ 0.089984] status: 0000000200000120 badaddr: ffffffff80021eaa cause: 0000000000000003
[ 0.090101] [<ffffffff80021eaa>] __virt_to_phys+0xae/0xe8
[ 0.090228] [<ffffffff8001d796>] sbi_cpu_start+0x6e/0xe8
[ 0.090247] [<ffffffff8001a5da>] __cpu_up+0x1e/0x8c
[ 0.090260] [<ffffffff8002a32e>] bringup_cpu+0x42/0x258
[ 0.090277] [<ffffffff8002914c>] cpuhp_invoke_callback+0xe0/0x40c
[ 0.090292] [<ffffffff800294e0>] __cpuhp_invoke_callback_range+0x68/0xfc
[ 0.090320] [<ffffffff8002a96a>] _cpu_up+0x11a/0x244
[ 0.090334] [<ffffffff8002aae6>] cpu_up+0x52/0x90
[ 0.090384] [<ffffffff80c09350>] bringup_nonboot_cpus+0x78/0x118
[ 0.090411] [<ffffffff80c11060>] smp_init+0x34/0xb8
[ 0.090425] [<ffffffff80c01220>] kernel_init_freeable+0x148/0x2e4
[ 0.090442] [<ffffffff80b83802>] kernel_init+0x1e/0x14c
[ 0.090455] [<ffffffff800124ca>] ret_from_fork_kernel+0xe/0xf0
[ 0.090471] [<ffffffff80b8d9c2>] ret_from_fork_kernel_asm+0x16/0x18
[ 0.090560] ---[ end trace 0000000000000000 ]---
[ 1.179875] CPU1: failed to come online
[ 1.190324] smp: Brought up 1 node, 1 CPU |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix memory leak of bio integrity
If nvmet receives commands with metadata there is a continuous memory
leak of kmalloc-128 slab or more precisely bio->bi_integrity.
Since commit bf4c89fc8797 ("block: don't call bio_uninit from bio_endio")
each user of bio_init has to use bio_uninit as well. Otherwise the bio
integrity is not getting free. Nvmet uses bio_init for inline bios.
Uninit the inline bio to complete deallocation of integrity in bio. |
| In the Linux kernel, the following vulnerability has been resolved:
idpf: return 0 size for RSS key if not supported
Returning -EOPNOTSUPP from function returning u32 is leading to
cast and invalid size value as a result.
-EOPNOTSUPP as a size probably will lead to allocation fail.
Command: ethtool -x eth0
It is visible on all devices that don't have RSS caps set.
[ 136.615917] Call Trace:
[ 136.615921] <TASK>
[ 136.615927] ? __warn+0x89/0x130
[ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330
[ 136.615953] ? report_bug+0x164/0x190
[ 136.615968] ? handle_bug+0x58/0x90
[ 136.615979] ? exc_invalid_op+0x17/0x70
[ 136.615987] ? asm_exc_invalid_op+0x1a/0x20
[ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170
[ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330
[ 136.616028] __alloc_pages_noprof+0xe/0x20
[ 136.616038] ___kmalloc_large_node+0x80/0x110
[ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0
[ 136.616081] __kmalloc_noprof+0x32c/0x4c0
[ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170
[ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170
[ 136.616114] ethnl_default_doit+0x107/0x3d0
[ 136.616131] genl_family_rcv_msg_doit+0x100/0x160
[ 136.616147] genl_rcv_msg+0x1b8/0x2c0
[ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10
[ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10
[ 136.616176] netlink_rcv_skb+0x58/0x110
[ 136.616186] genl_rcv+0x28/0x40
[ 136.616195] netlink_unicast+0x19b/0x290
[ 136.616206] netlink_sendmsg+0x222/0x490
[ 136.616215] __sys_sendto+0x1fd/0x210
[ 136.616233] __x64_sys_sendto+0x24/0x30
[ 136.616242] do_syscall_64+0x82/0x160
[ 136.616252] ? __sys_recvmsg+0x83/0xe0
[ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210
[ 136.616275] ? do_syscall_64+0x8e/0x160
[ 136.616282] ? __count_memcg_events+0xa1/0x130
[ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30
[ 136.616306] ? handle_mm_fault+0xae/0x2d0
[ 136.616319] ? do_user_addr_fault+0x379/0x670
[ 136.616328] ? clear_bhb_loop+0x45/0xa0
[ 136.616340] ? clear_bhb_loop+0x45/0xa0
[ 136.616349] ? clear_bhb_loop+0x45/0xa0
[ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 136.616369] RIP: 0033:0x7fd30ba7b047
[ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44
[ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
[ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047
[ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003
[ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c
[ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340
[ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000 |
| In the Linux kernel, the following vulnerability has been resolved:
spi: spi-qpic-snand: reallocate BAM transactions
Using the mtd_nandbiterrs module for testing the driver occasionally
results in weird things like below.
1. swiotlb mapping fails with the following message:
[ 85.926216] qcom_snand 79b0000.spi: swiotlb buffer is full (sz: 4294967294 bytes), total 512 (slots), used 0 (slots)
[ 85.932937] qcom_snand 79b0000.spi: failure in mapping desc
[ 87.999314] qcom_snand 79b0000.spi: failure to write raw page
[ 87.999352] mtd_nandbiterrs: error: write_oob failed (-110)
Rebooting the board after this causes a panic due to a NULL pointer
dereference.
2. If the swiotlb mapping does not fail, rebooting the board may result
in a different panic due to a bad spinlock magic:
[ 256.104459] BUG: spinlock bad magic on CPU#3, procd/2241
[ 256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b
...
Investigating the issue revealed that these symptoms are results of
memory corruption which is caused by out of bounds access within the
driver.
The driver uses a dynamically allocated structure for BAM transactions,
which structure must have enough space for all possible variations of
different flash operations initiated by the driver. The required space
heavily depends on the actual number of 'codewords' which is calculated
from the pagesize of the actual NAND chip.
Although the qcom_nandc_alloc() function allocates memory for the BAM
transactions during probe, but since the actual number of 'codewords'
is not yet know the allocation is done for one 'codeword' only.
Because of this, whenever the driver does a flash operation, and the
number of the required transactions exceeds the size of the allocated
arrays the driver accesses memory out of the allocated range.
To avoid this, change the code to free the initially allocated BAM
transactions memory, and allocate a new one once the actual number of
'codewords' required for a given NAND chip is known. |
| A flaw was found in the cookie parsing logic of the libsoup HTTP library, used in GNOME applications and other software. The vulnerability arises when processing the expiration date of cookies, where a specially crafted value can trigger an integer overflow. This may result in undefined behavior, allowing an attacker to bypass cookie expiration logic, causing persistent or unintended cookie behavior. The issue stems from improper validation of large integer inputs during date arithmetic operations within the cookie parsing routines. |
| When using the Grafana Databricks Datasource Plugin,
if Oauth passthrough is enabled on the datasource, and multiple users are using the same datasource at the same time on a single Grafana instance, it could result in
the wrong user identifier being used, and information for which the viewer is not authorized being returned.
This issue affects Grafana Databricks Datasource Plugin: from 1.6.0 before 1.12.0 |
| A flaw was found in the cookie date handling logic of the libsoup HTTP library, widely used by GNOME and other applications for web communication. When processing cookies with specially crafted expiration dates, the library may perform an out-of-bounds memory read. This flaw could result in unintended disclosure of memory contents, potentially exposing sensitive information from the process using libsoup. |
| In the Linux kernel, the following vulnerability has been resolved:
net: netpoll: Initialize UDP checksum field before checksumming
commit f1fce08e63fe ("netpoll: Eliminate redundant assignment") removed
the initialization of the UDP checksum, which was wrong and broke
netpoll IPv6 transmission due to bad checksumming.
udph->check needs to be set before calling csum_ipv6_magic(). |
| In the Linux kernel, the following vulnerability has been resolved:
block: reject bs > ps block devices when THP is disabled
If THP is disabled and when a block device with logical block size >
page size is present, the following null ptr deref panic happens during
boot:
[ [13.2 mK AOSAN: null-ptr-deref in range [0x0000000000000000-0x0000000000K0 0 0[07]
[ 13.017749] RIP: 0010:create_empty_buffers+0x3b/0x380
<snip>
[ 13.025448] Call Trace:
[ 13.025692] <TASK>
[ 13.025895] block_read_full_folio+0x610/0x780
[ 13.026379] ? __pfx_blkdev_get_block+0x10/0x10
[ 13.027008] ? __folio_batch_add_and_move+0x1fa/0x2b0
[ 13.027548] ? __pfx_blkdev_read_folio+0x10/0x10
[ 13.028080] filemap_read_folio+0x9b/0x200
[ 13.028526] ? __pfx_filemap_read_folio+0x10/0x10
[ 13.029030] ? __filemap_get_folio+0x43/0x620
[ 13.029497] do_read_cache_folio+0x155/0x3b0
[ 13.029962] ? __pfx_blkdev_read_folio+0x10/0x10
[ 13.030381] read_part_sector+0xb7/0x2a0
[ 13.030805] read_lba+0x174/0x2c0
<snip>
[ 13.045348] nvme_scan_ns+0x684/0x850 [nvme_core]
[ 13.045858] ? __pfx_nvme_scan_ns+0x10/0x10 [nvme_core]
[ 13.046414] ? _raw_spin_unlock+0x15/0x40
[ 13.046843] ? __switch_to+0x523/0x10a0
[ 13.047253] ? kvm_clock_get_cycles+0x14/0x30
[ 13.047742] ? __pfx_nvme_scan_ns_async+0x10/0x10 [nvme_core]
[ 13.048353] async_run_entry_fn+0x96/0x4f0
[ 13.048787] process_one_work+0x667/0x10a0
[ 13.049219] worker_thread+0x63c/0xf60
As large folio support depends on THP, only allow bs > ps block devices
if THP is enabled. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix race between DIM disable and net_dim()
There's a race between disabling DIM and NAPI callbacks using the dim
pointer on the RQ or SQ.
If NAPI checks the DIM state bit and sees it still set, it assumes
`rq->dim` or `sq->dim` is valid. But if DIM gets disabled right after
that check, the pointer might already be set to NULL, leading to a NULL
pointer dereference in net_dim().
Fix this by calling `synchronize_net()` before freeing the DIM context.
This ensures all in-progress NAPI callbacks are finished before the
pointer is cleared.
Kernel log:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
RIP: 0010:net_dim+0x23/0x190
...
Call Trace:
<TASK>
? __die+0x20/0x60
? page_fault_oops+0x150/0x3e0
? common_interrupt+0xf/0xa0
? sysvec_call_function_single+0xb/0x90
? exc_page_fault+0x74/0x130
? asm_exc_page_fault+0x22/0x30
? net_dim+0x23/0x190
? mlx5e_poll_ico_cq+0x41/0x6f0 [mlx5_core]
? sysvec_apic_timer_interrupt+0xb/0x90
mlx5e_handle_rx_dim+0x92/0xd0 [mlx5_core]
mlx5e_napi_poll+0x2cd/0xac0 [mlx5_core]
? mlx5e_poll_ico_cq+0xe5/0x6f0 [mlx5_core]
busy_poll_stop+0xa2/0x200
? mlx5e_napi_poll+0x1d9/0xac0 [mlx5_core]
? mlx5e_trigger_irq+0x130/0x130 [mlx5_core]
__napi_busy_loop+0x345/0x3b0
? sysvec_call_function_single+0xb/0x90
? asm_sysvec_call_function_single+0x16/0x20
? sysvec_apic_timer_interrupt+0xb/0x90
? pcpu_free_area+0x1e4/0x2e0
napi_busy_loop+0x11/0x20
xsk_recvmsg+0x10c/0x130
sock_recvmsg+0x44/0x70
__sys_recvfrom+0xbc/0x130
? __schedule+0x398/0x890
__x64_sys_recvfrom+0x20/0x30
do_syscall_64+0x4c/0x100
entry_SYSCALL_64_after_hwframe+0x4b/0x53
...
---[ end trace 0000000000000000 ]---
...
---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.
sof_pdata->tplg_filename can have address allocated by kstrdup()
and can be overwritten. Memory leak was detected with kmemleak:
unreferenced object 0xffff88812391ff60 (size 16):
comm "kworker/4:1", pid 161, jiffies 4294802931
hex dump (first 16 bytes):
73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic.
backtrace (crc 4bf1675c):
__kmalloc_node_track_caller_noprof+0x49c/0x6b0
kstrdup+0x46/0xc0
hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic]
sof_init_environment+0x16f/0xb50 [snd_sof]
sof_probe_continue+0x45/0x7c0 [snd_sof]
sof_probe_work+0x1e/0x40 [snd_sof]
process_one_work+0x894/0x14b0
worker_thread+0x5e5/0xfb0
kthread+0x39d/0x760
ret_from_fork+0x31/0x70
ret_from_fork_asm+0x1a/0x30 |
