Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
CVE-2021-27965 — stack based buffer overflow in MsIo64.sys, Proof of Concept Local Privilege Escalation to nt authority/system | Kitploit
Tools/GitHubGitHub/mathisvickie/cve-2021-27965
Privilege EscalationVulnerability AnalysisExploitationBinary Exploitation
GitHubmathisvickie/cve-2021-27965

CVE-2021-27965

stack based buffer overflow in MsIo64.sys, Proof of Concept Local Privilege Escalation to nt authority/system

View Repository
1355 years agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

CVE-2021-27965

Simple PoC for exploiting CVE-2021-27965 for LPE by spawning system cmd.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27965

An issue was discovered in signed MICSYS windows driver (MsIo64.sys) which may lead to compromisation of whole local system. Driver's ioctl dispatch routine suffers from stack based buffer overflow in all IOCTL codes and also lacks of validation of user supplied buffer.

IOCTL

Anyone can create handle and issue ioctl requests to these ioctl codes which break windows security model:

  • 0x80102040 - arbitrary physical memory mapping into calling process and unchecked pointer access (possible system crash/DoS)
  • 0x80102044 - unmapping physical memory and unchecked pointer access (possible system crash/DoS)
  • 0x80102050 - arbitrary port read (byte, word, dword)
  • 0x80102054 - arbitrary port write (byte, word, dword)

Stack Buffer Overflow

On each IOCTL code, driver is not accessing Irp->SystemBuffer directly but rather using memcpy like function to copy Irp->SystemBuffer into current function's stack frame buffer which has always fixed size (and then using this buffer). Since both Irp->SystemBuffer and Irp->CurrentStackLocation->InputBufferLength are controlled by calling process, a malicious actor could send large enough buffer to overflow the one inside function stack frame. To note: Even if in DriverEntry is __security_init_cookie(), in ioctl dispatch is __security_check_cookie() missing for some reason.

Compiling PoC

TODO

Tested on

TODO

Download Tool