CVE-2024-21338
Microsoft Windows Kernel Exposed IOCTL with Insufficient Access Control Vulnerability
CVSS
7.8
High
EPSS
59.8%
p99
KEV
YES
Mar 4, 2024
Exploit Today
80
0-100
Published: Feb 13, 2024 · Last modified: Aug 10, 2026 · CWE-822
59.8%EPSS · 30 days59.8%
2026-08-022026-08-31
Product
Microsoft / Windows
Vulnerability
Microsoft Windows Kernel Exposed IOCTL with Insufficient Access Control Vulnerability
Added to KEV
Mar 4, 2024
Remediate by
Mar 25, 2024
Known ransomware use
Yes
Summary description
Microsoft Windows Kernel contains an exposed IOCTL with insufficient access control vulnerability within the IOCTL (input and output control) dispatcher in appid.sys that allows a local attacker to achieve privilege escalation.
Required action
Apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable.
Notes
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21338; https://nvd.nist.gov/vuln/detail/CVE-2024-21338
Windows Kernel Elevation of Privilege Vulnerability
- msrc.microsoft.comhttps://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21338
- decoded.avast.iohttps://decoded.avast.io/janvojtesek/lazarus-and-the-fudmodule-rootkit-beyond-byovd-with-an-admin-to-kernel-zero-day/
- msrc.microsoft.comhttps://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21338
- packetstorm.newshttps://packetstorm.news/files/id/190586/
- www.exploit-db.comhttps://www.exploit-db.com/exploits/52275
- www.cisa.govhttps://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-21338
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-194428.2 HIG2.0%
——1IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 has a pointer validation flaw exists in the AIX Virtual SCSI (vSCSI) initiator driver. Successful exploitation may result in denial of service, privilege escalation, or full compromise of the client LPAR kernel.6dCVE-2026-188408.2 HIG2.4%
——1IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to execute arbitrary code due to improper validation of an attacker-controlled pointer.6dCVE-2026-97718.8 HIG1.2%
——0The flash_copy() system call is verified by z_vrfy_flash_copy() in drivers/flash/flash_util.c. On builds with CONFIG_USERSPACE enabled, this handler is the kernel-side trust boundary for a user-mode caller. Prior to the fix it validated only the output buffer (K_SYSCALL_MEMORY_WRITE) and passed the two struct device * arguments, src_dev and dst_dev, directly into the implementation without any object validation — unlike every sibling flash syscall, which guards its device pointer with K_SYSCALL_DRIVER_FLASH.
A user-mode thread fully controls the values of src_dev/dst_dev and the contents of its own address space. The implementation z_impl_flash_copy() dereferences these pointers and calls through their driver-API function tables (e.g. api->get_parameters(dst_dev), flash_read(src_dev, ...), flash_write(dst_dev, ...)). By supplying a pointer to a forged struct device whose api table contains attacker-chosen function pointers, an unprivileged thread can cause the kernel to call arbitrary code in supervisor mode; passing any arbitrary or invalid address otherwise yields a kernel crash or out-of-bounds read.
The result is a local privilege escalation out of the userspace sandbox (with kernel denial-of-service and information disclosure as lesser outcomes). The fix adds K_SYSCALL_DRIVER_FLASH(src_dev, read) and K_SYSCALL_DRIVER_FLASH(dst_dev, write) to z_vrfy_flash_copy(), which verify each device is a registered flash-driver kernel object the calling thread is permitted to use before any dereference, closing the path completely.14dCVE-2026-123648.4 HIG2.0%
——1The user-space system-call verifier z_vrfy_z_log_msg_static_create() in subsys/logging/log_msg.c was a pure pass-through: it forwarded the caller-supplied source, desc, package, and data arguments directly to the kernel-mode implementation z_impl_z_log_msg_static_create() without performing any of the mandatory K_SYSCALL_* checks. Because z_log_msg_static_create() is declared __syscall, under CONFIG_USERSPACE any unprivileged user-mode thread can invoke it directly with fully attacker-controlled arguments.
The kernel-mode handler dereferences each of these untrusted values: frontend_runtime_filtering() reads through the source pointer as a struct log_source_dynamic_data, cbprintf_package_copy() reads desc.package_len bytes from the package pointer, and z_log_msg_finalize() performs a memcpy() of desc.data_len bytes from the data pointer. With no verification, a user thread can supply arbitrary kernel addresses and arbitrary lengths, and the kernel will read from them.
The impact is a kernel-mode denial of service (the kernel faults dereferencing an attacker-chosen pointer) and, where a log backend output is observable to the attacker, disclosure of arbitrary kernel memory copied into the emitted log message — a confidentiality breach across the user/kernel boundary that the userspace sandbox is meant to enforce. The reads do not corrupt kernel memory, so there is no out-of-bounds write primitive.
The fix adds the required validation to the verifier: it bounds desc.package_len against Z_LOG_MSG_MAX_PACKAGE, rejects non-NULL/length mismatches, and applies K_SYSCALL_MEMORY_READ() to package, data, and (when runtime filtering with a frontend is enabled) source, so any out-of-bounds or kernel pointer now raises K_OOPS instead of being honored.5dCVE-2026-688107.8 HIG22.5%
——7Untrusted pointer dereference in Microsoft Office Excel allows an unauthorized attacker to execute code locally.18dCVE-2026-649107.8 HIG26.8%
——8Untrusted pointer dereference in Microsoft Office allows an unauthorized attacker to execute code locally.17d