| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| SuiteCRM is an open-source, enterprise-ready Customer Relationship Management (CRM) software application. Prior to 7.15.2 and 8.10.2, the V8 JSON:API update path fails to remove the id attribute before assigning user-supplied attributes to a SugarBean. The affected flow begins at updateRecord() and uses processAttributes(), id, and ACL_ALLOW_OWNER to carry attacker-controlled data or authorization state into the security-sensitive operation. An authenticated user can substitute a victim record identifier, bypass owner-only authorization, overwrite another record, and hijack record ownership. This issue is fixed in versions 7.15.2 and 8.10.2. |
| Stack-based buffer overflow in Microsoft Office Outlook allows an unauthorized attacker to execute code over a network. |
| Authorization bypass through user-controlled key in Microsoft Exchange Server allows an authorized attacker to elevate privileges over a network. |
| Authorization bypass through user-controlled key in Microsoft Office SharePoint allows an authorized attacker to disclose information over a network. |
| Incorrect conversion between numeric types in Microsoft Office Word allows an unauthorized attacker to disclose information over a network. |
| Improper restriction of xml external entity reference in Microsoft PowerShell allows an unauthorized attacker to disclose information over a network. |
| Improper restriction of xml external entity reference in Microsoft Dynamics 365 (on-premises) allows an authorized attacker to disclose information over a network. |
| Incorrect resource transfer between spheres in Windows Error Reporting allows an authorized attacker to elevate privileges locally. |
| Improper access control in Windows NTFS allows an authorized attacker to perform tampering locally. |
| Authorization bypass through user-controlled key in Azure DevOps Server allows an authorized attacker to elevate privileges over a network. |
| Stack-based buffer overflow in Windows Installer allows an authorized attacker to elevate privileges locally. |
| Authorization bypass through user-controlled key in Microsoft MCP Gateway allows an authorized attacker to elevate privileges over a network. |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix missing alloc tagging of direct mempool allocations
Commit 1d78d56c43ef ("netfs: Fix folio_queue ENOMEM in writeback by
adding a mempool") added a mempool for the folio_queues and made the
request, subrequest and folio_queue allocations distinguish between
writeback and everything else. Writeback is part of memory reclaim
and must not fail due to ENOMEM, so it allocates under GFP_NOFS
through mempool_alloc(), which may dip into the pool's reserve and,
if that runs empty, wait for elements to be returned. The
GFP_KERNEL paths, which can return -ENOMEM to their callers, invoke
the pool's ->alloc() callback directly instead.
The direct call, however, skips the alloc_hooks() wrapper that the
mempool_alloc() macro provides. The pool callbacks, mempool_alloc_slab()
and mempool_kmalloc(), call kmem_cache_alloc_noprof() and kmalloc_noprof()
and rely on current->alloc_tag having been set by the caller. With
CONFIG_MEM_ALLOC_PROFILING_DEBUG=y this leads to
current->alloc_tag not set
WARNING: ./include/linux/alloc_tag.h:161 at __alloc_tagging_slab_alloc_hook
alloc_tag was not set
WARNING: ./include/linux/alloc_tag.h:166 at __alloc_tagging_slab_free_hook
at allocation and free time respectively, as reported when reading
files on a CIFS mount. The allocations are also missing from
/proc/allocinfo.
Wrap the direct ->alloc() invocations in alloc_hooks() with a new
mempool_alloc_noreserve() helper in include/linux/mempool.h, next to
the other alloc_hooks()-wrapped macros such as mempool_alloc(). The
GFP_KERNEL paths keep their failable allocation semantics, they just
get tagged now. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: drain and invalidate before server-side copy/clone
cifs_file_copychunk_range() and the clone (FICLONE) path of
cifs_remap_file_range() do not serialise the destination page cache
against the server-side copy the way the other server-side range
operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range()
and smb3_insert_range()) do.
cifs_file_copychunk_range() invalidates the destination range with
filemap_invalidate_inode(), which takes and drops the mapping's
invalidate_lock internally, so the lock is no longer held when the
copychunk ioctl is issued. It also never drains in-flight netfs I/O on
the target. The clone path never takes the invalidate_lock at all (only
i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not
drain outstanding I/O.
As a result an asynchronous destination writeback can complete after the
server-side copy/clone has run and reinstate stale data over the region
just written by the server, corrupting the file. This is the same class
of corruption as commit d7d2adcd022b ("smb/client: flush dirty data
before punching a hole") and has been seen randomly in generic/363
against Windows Server.
Fix both paths to follow the established ordering: hold the target
mapping's invalidate_lock across the flush and invalidation of the
destination and the server ioctl, and call netfs_wait_for_outstanding_io()
on the target to drain in-flight writes before the ioctl is issued. Only
the target inode's invalidate_lock is required, as the source is merely
flushed and not invalidated; i_rwsem (already held via
lock_two_nondirectories()) is acquired before the invalidate_lock,
matching the VFS lock ordering. Since filemap_invalidate_inode() takes
that same lock internally, replace it with its own unmap/flush/invalidate
steps instead of calling it, and return early on a zero-length copy to
avoid a range underflow. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Transfer the hyp stack pages out of the host stage-2
fix_host_ownership() walks only the linear-map alias of each memblock
region, and the per-CPU hyp stack, mapped in the private VA range for
its guard page, has none.
Walk each stack's VA range with the same walker. |
| In the Linux kernel, the following vulnerability has been resolved:
media: chips-media: wave5: Resume device before setting EOS flag
Setting the EOS flag talks to the firmware via send_firmware_command(),
which accesses VPU registers. Both the STREAMOFF path
(wave5_vpu_dec_job_abort()) and the V4L2_DEC_CMD_STOP path
(wave5_vpu_dec_stop()) can run while the device is runtime suspended, so
those register accesses hit powered-down hardware and the SoC raises an
asynchronous SError, panicking the kernel:
SError Interrupt on CPU3, code 0x00000000bf000000 -- SError
send_firmware_command+0x2c/0x160 [wave5]
wave5_vpu_dec_set_bitstream_flag+0x6c/0x80 [wave5]
wave5_vpu_dec_update_bitstream_buffer+0x80/0xec [wave5]
wave5_vpu_dec_job_abort+0x44/0xa0 [wave5]
v4l2_m2m_cancel_job+0x110/0x19c [v4l2_mem2mem]
v4l2_m2m_streamoff+0x24/0x140 [v4l2_mem2mem]
Resume the device with pm_runtime_resume_and_get() around the EOS
firmware command and release it with pm_runtime_put_autosuspend(),
matching the runtime PM handling already done in
wave5_vpu_dec_device_run(). |
| Improper initialization in the MigTD virtio-vsock stream handling for the Intel(R) TDX Migration Trust Domain (MigTD) within Ring 0: Hypervisor may allow a denial of service. System software adversary with an unauthenticated user combined with a low complexity attack may enable data corruption. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (low) and availability (low) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Incorrect behavior order in the get_tcb_level_by_svn for the Intel(R) TDX Migration Trust Domain (MigTD) within Ring 0: Hypervisor may allow a denial of service. Network adversary with an unauthenticated user combined with a low complexity attack may enable denial of service. This result may potentially occur via adjacent access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (low) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Improper control of a resource through its lifetime in the MigTD's TLS client for the Intel(R) TDX Migration Trust Domain (MigTD) within Ring 0: Hypervisor may allow a denial of service. Network adversary with an unauthenticated user combined with a low complexity attack may enable data corruption. This result may potentially occur via adjacent access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (low) and availability (low) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Incorrect comparison in the Ext2 parser for the Intel(R) Slim Bootloader within Ring 0: Bare Metal OS may allow a denial of service. System software adversary with a privileged user combined with a low complexity attack may enable data corruption. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
