🚨 CVE-2026-75754
Missing Authentication for Critical Function, Server-Side Request Forgery (SSRF), and Use of Hard-coded Credentials in ASUS Control Center allow an unauthorized user to obtain the encryption key via an HTTP request, causing a local service to enable SSH on port 2222. The attacker can then log in with the hardcode credentials to obtain a root shell, enabling direct reading, writing, and deletion of data on ASUS Control Center, as well as remote control of all servers, PCs, and workstations within the company.
Refer to the 'Security Update for ASUS Control Center' section on the ASUS Security Advisory for more information.

🎖@cveNotify

🚨 CVE-2026-12962
A Permissive Cross-domain Security Policy with Untrusted Domains in Armoury Crate allows a remote user to obtain a local user's NTLM hash by convincing the user to visit a crafted web page that sends a request containing a UNC path to the application's local service endpoint.Refer to the '
Security Update for Armoury Crate App ' section on the ASUS Security Advisory for more information.

🎖@cveNotify

🚨 CVE-2026-16003
Exposed IOCTL with Insufficient Access Control in Armoury Crate driver allows a local user to add an arbitrary process identifier to the driver's whitelist via a crafted IOCTL request by bypassing the driver's verification.Refer to the '
Security Update for Armoury Crate App  ' section on the ASUS Security Advisory for more information.

🎖@cveNotify

🚨 CVE-2026-16004
Exposed IOCTL with Insufficient Access Control in Armoury Crate driver allows a local user to read and write arbitrary PCI/PCIe configuration space via crafted IOCTL requests by bypassing the driver's verification.
Refer to the '
Security Update for Armoury Crate App' section on the ASUS Security Advisory for more information.

🎖@cveNotify

🚨 CVE-2026-16006
Exposure of Sensitive System Information to an Unauthorized Control Sphere in Armoury Crate driver allows a local user to obtain kernel virtual addresses via a crafted IOCTL request by bypassing the driver's verification, potentially providing further insight into the kernel memory layout.Refer to the '
Security Update for Armoury Crate App  ' section on the ASUS Security Advisory for more information.

🎖@cveNotify

🚨 CVE-2026-18023
Sensitive Information in Resource Not Removed Before Reuse in ASUS Armoury Crate driver allows a local user to disclose sensitive information from uninitialized memory via a crafted IOCTL request that bypasses the driver's security verification mechanism.
Refer to the '
Security Update for Armoury Crate App ' section on the ASUS Security Advisory for more information.

🎖@cveNotify

🚨 CVE-2026-19397
Missing authentication for a critical function in ASUS Control Center Express Agent allows an unauthenticated nearby user to control the host via a direct connection to the agent when the host has an active login session.
Refer to the ' 
Security Update for ASUS Control Center Express Agent ' section on the ASUS Security Advisory for more information.

🎖@cveNotify

🚨 CVE-2026-75808
Allocation of Resources Without Limits or Throttling in ASUS Armoury Crate allows a local user to cause a denial-of-service condition through system memory exhaustion by bypassing driver authentication and allocating an unrestricted amount of memory.Refer to the '
Security Update for Armoury Crate App ' section on the ASUS Security Advisory for more information.

🎖@cveNotify

🚨 CVE-2026-75809
Exposed IOCTL with insufficient access control in ASUS Armoury Crate allows a local user to disclosure information and disabling device functionality by bypassing driver authentication and using IOCTLs to read from and write to PCIe configuration space.Refer to the '
Security Update for Armoury Crate App ' section on the ASUS Security Advisory for more information.

🎖@cveNotify

🚨 CVE-2026-75810
Exposed Dangerous Method or Function in ASUS Armoury Crate allow a local user to cause a brief system stall by bypassing driver authentication and sending requests to trigger system management interrupts (SMIs). Repeatedly triggering SMI may lead to a denial-of-service (DoS) condition.Refer to the '
Security Update for Armoury Crate App ' section on the ASUS Security Advisory for more information.

🎖@cveNotify

🚨 CVE-2026-75811
Improper Restriction of Software Interfaces to Hardware Features in ASUS Armoury Crate allows a local user to modify hardware configuration settings and potentially cause hardware damage by bypassing driver authentication and accessing critical model-specific registers.Refer to the '
Security Update for Armoury Crate App' section on the ASUS Security Advisory for more information.

🎖@cveNotify

🚨 CVE-2026-86320
A flaw was found in flatpak-builder where Git hooks are not disabled when applying patch sources with use-git-am: true. An attacker who can provide a malicious source containing a Git post-applypatch hook can cause the hook to execute on the host during the build process, resulting in arbitrary code execution with the privileges of the user running flatpak-builder.

🎖@cveNotify

🚨 CVE-2026-15688
Incorrect Implementation of Authentication Algorithm Vulnerability in Mitsubishi Electric GX Works3 and Motion Control Setting allows a local attacker to successfully authenticate even with an invalid block password by executing the affected product and modifying part of the executable module in memory, and thereby may be able to view, tamper with, destroy, or delete control programs.

🎖@cveNotify

🚨 CVE-2026-50608
A vulnerability has been identified in the Acer System Monitoring component included with NitroSense and PredatorSense. The WebSocket handshake process does not properly require authentication before allowing connections to the service. Under certain circumstances, unauthorized access to service functionality may be possible.

🎖@cveNotify

🚨 CVE-2026-50609
A vulnerability has been identified in the Acer System Monitoring component included with NitroSense and PredatorSense. Insufficient access controls within a privileged Named Pipe service may allow an authenticated local user to perform unauthorized registry operations. In certain situations, this could lead to privilege escalation or compromise of the affected system.

🎖@cveNotify

🚨 CVE-2026-50610
A vulnerability has been identified in the Acer System Monitoring component included with NitroSense and PredatorSense due to insufficient access controls in a privileged service. An authenticated local user may be able to access the service and perform unauthorized registry modifications, potentially resulting in local privilege escalation.

🎖@cveNotify

🚨 CVE-2026-89808
In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram

When migration vm range is hole at cpu side(MIGRATE_PFN_MIGRATE set +
MIGRATE_PFN_VALID unset) driver still allocates device pages. There is no
dma map of src pages and migration. j is 0 and svm_migrate_copy_memory_gart()
will return an uninitialized r. That can trigger out_free_vram_pages to drop
all VRAM just set up.

Initialize r and only call the last svm_migrate_copy_memory_gart if j > 0.

Current code postponed the last page to the final copy. This patch flushes on
the last page when reach to the end of current drm_buddy_block; avoids another
svm_migrate_copy_memory_gart.

🎖@cveNotify

🚨 CVE-2026-89809
In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: fix scope of mqd_mgr dereference in pqm_debugfs_mqds

Reading /sys/kernel/debug/kfd/mqds while a process holds an active KFD
queue triggers a NULL pointer dereference because the for loop that
calls mqd_mgr->debugfs_show_mqd() is incorrectly placed outside the
if (pqn->q) block that initializes mqd_mgr.

The queue list can contain entries where pqn->q is NULL (kernel queues
where only pqn->kq is valid). In the original code:

if (pqn->q) {
...
mqd_mgr = q->device->dqm->mqd_mgrs[mqd_type];
size = mqd_mgr->mqd_stride(...);
}

for (xcc = 0; xcc < num_xccs; xcc++) { // WRONG: outside if block
mqd = q->mqd + size * xcc;
r = mqd_mgr->debugfs_show_mqd(m, mqd);
}

When iterating over a queue node where pqn->q is NULL:
1. The if (pqn->q) block is skipped
2. mqd_mgr remains uninitialized (NULL from declaration)
3. The for loop executes anyway
4. mqd_mgr->debugfs_show_mqd(m, mqd) dereferences NULL

The crash manifests as:

BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor instruction fetch in kernel mode
RIP: 0010:0x0
Call Trace:
pqm_debugfs_mqds+0x10c/0x1d0 [amdgpu]
kfd_debugfs_mqds_by_process+0x9b/0x110 [amdgpu]
seq_read_iter+0x132/0x4b0
...

Fix by moving the for loop inside the if (pqn->q) block, so mqd_mgr
and related variables are only used when properly initialized.

(cherry picked from commit 8bfe29d5c798940f797aa24135d2734c3ffce9de)

🎖@cveNotify

🚨 CVE-2026-89810
In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix error path at svm_migrate_copy_to_ram

If page migration from device to sys ram fails for some reasons driver needs
release and unlock allocated system pages. To do that driver should use page
physical address, or pfn, then get struct page*. Current driver uses dma
address(for adev) that is not correct with IOMMU enabled, or even in general.

The patch releases and unlocks allocated system pages based on where migration
failed by struct page* of sys ram pages. Also dma_unmap correspodent system
ram pages at error path.

🎖@cveNotify

🚨 CVE-2026-89811
In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Add TLB flush after MES queue eviction/suspension

MES (Micro Engine Scheduler) does not perform heavy-weight TLB
invalidation after unmapping queues, unlike HWS which does this
automatically. This causes a race condition where in-flight DMA
descriptors can access memory that has been unmapped, leading to page
faults and GPU queue hangs during SVM page migration.

The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest
failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU
compute queue hangs with packets submitted but never consumed.

Add kfd_flush_tlb() calls after MES queue removal in two locations:
- evict_process_queues_cpsch(): after all queues removed during eviction
- suspend_queues(): after debug/criu queue suspension (with mem_fence barrier)

This ensures all in-flight memory accesses from unmapped queues are
flushed before memory is freed or migrated.

(cherry picked from commit f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77)

🎖@cveNotify

🚨 CVE-2026-89812
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: force complete the MES ring fences on reset

The MES scheduler ring has no drm scheduler (no_scheduler = true), so it is
skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). It uses
a polling fence whose hw value lives in wb (GTT) memory and survives a MODE1
reset, while fence_drv.sync_seq keeps advancing for every packet.

When the reset is triggered because MES itself stopped responding, the
timed-out packets advance sync_seq past the last hw fence value MES wrote.
After resume the first MES submission polls forever on a seq that is never
written back, failing the resume and wedging the box on a second reset:

amdgpu: MES ring buffer is full.
amdgpu: *ERROR* ring gfx_0.0.0 test failed (-110)
amdgpu: resume of IP block <gfx_v11_0> failed -110
amdgpu: GPU reset end with ret = -110

Force complete the MES scheduler ring fences together with the scheduler rings
so their hw fence is realigned to sync_seq.

v2: cover all XCCs (one scheduler ring each), not just mes.ring[0].

🎖@cveNotify