Is this a bug ?

NTDEV
1

It looks like MiObtainSectionForDriver could return
without releasing the system loader lock.

nt!MiObtainSectionForDriver+0x7f:
fffff8009175c67f 498bcf mov rcx,r15 fffff8009175c682 e8a576f9ff call nt!MmReleaseLoadLock (fffff800916f3d2c) fffff8009175c687 4c8d442468 lea r8,[rsp+68h]
fffff8009175c68c 8bd5 mov edx,ebp fffff8009175c68e 498bce mov rcx,r14
fffff8009175c691 e846120000 call nt!MiCreateSectionForDriver (fffff8009175d8dc)
fffff8009175c696 8bd8 mov ebx,eax // return status saved in EBX fffff8009175c698 e8eb76f9ff call nt!MmAcquireLoadLock (fffff800916f3d88) // Loader Lock Acquired fffff8009175c69d 85db test ebx,ebx // Test for FAILED status
fffff8009175c69f 784d js nt!MiObtainSectionForDriver+0xee (fffff8009175c6ee)

if (nt!MiCreateSectionForDriver) failed, jump here

nt!MiObtainSectionForDriver+0xee:
fffff8009175c6ee 8bc3 mov eax,ebx // status to be returned fffff8009175c6f0 eb50 jmp nt!MiObtainSectionForDriver+0x142 (fffff800`9175c742)

Function prolog:

The function returns the (nt!MiCreateSectionForDriver) failure
status but the loader lock was not released.

nt!MiObtainSectionForDriver+0x142:
fffff8009175c742 488b5c2450 mov rbx,qword ptr [rsp+50h] fffff8009175c747 488b6c2458 mov rbp,qword ptr [rsp+58h]
fffff8009175c74c 488b742460 mov rsi,qword ptr [rsp+60h] fffff8009175c751 4883c420 add rsp,20h
fffff8009175c755 415f pop r15 fffff8009175c757 415e pop r14
fffff8009175c759 415d pop r13 fffff8009175c75b 415c pop r12
fffff8009175c75d 5f pop rdi fffff8009175c75e c3 ret

Is this correct ?

Here is the kernel version as displayed by the debugger:

kd> vertarget
Windows 10 Kernel Version 10240 MP (1 procs) Free x64
Built by: 10240.17071.amd64fre.th1.160802-1852
Machine Name:
Kernel base = 0xfffff8009120b000 PsLoadedModuleList = 0xfffff80091530070
Debug session time: Tue Aug 23 16:55:46.143 2016 (UTC - 4:00)
System Uptime: 0 days 0:00:05.249

2

no, this is not bug.
MiObtainSectionForDriver called from MmLoadSystemImage with already lock held (MmSystemLoadLock) and MmLoadSystemImage release this lock. also if you look more to MiObtainSectionForDriver we can view next code:

MmReleaseLoadLock()
MiCreateSectionForDriver(*)
MmAcquireLoadLock()

first Release (so lock must be already held) and then restore to initial state. this function and must return with lock held

3

Ok, thank you.

4

This is correct. This function is called with the loader lock held. It can release and re-acquire the lock, but in all cases it returns with the lock held.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, August 23, 2016 2:02 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Is this a bug ?

It looks like MiObtainSectionForDriver could return without releasing the system loader lock.

nt!MiObtainSectionForDriver+0x7f:
fffff8009175c67f 498bcf mov rcx,r15<br>fffff8009175c682 e8a576f9ff call nt!MmReleaseLoadLock (fffff800916f3d2c)<br>fffff8009175c687 4c8d442468 lea r8,[rsp+68h]
fffff8009175c68c 8bd5 mov edx,ebp<br>fffff8009175c68e 498bce mov rcx,r14
fffff8009175c691 e846120000 call nt!MiCreateSectionForDriver (fffff8009175d8dc)
fffff8009175c696 8bd8 mov ebx,eax // return status saved in EBX<br>fffff8009175c698 e8eb76f9ff call nt!MmAcquireLoadLock (fffff800916f3d88) // Loader Lock Acquired<br>fffff8009175c69d 85db test ebx,ebx // Test for FAILED status
fffff8009175c69f 784d js nt!MiObtainSectionForDriver+0xee (fffff8009175c6ee)

if (nt!MiCreateSectionForDriver) failed, jump here

nt!MiObtainSectionForDriver+0xee:
fffff8009175c6ee 8bc3 mov eax,ebx // status to be returned<br>fffff8009175c6f0 eb50 jmp nt!MiObtainSectionForDriver+0x142 (fffff8009175c742)<br><br>Function prolog: <br><br>The function returns the (nt!MiCreateSectionForDriver) failure status but the loader lock was not released.<br><br>nt!MiObtainSectionForDriver+0x142:<br>fffff8009175c742 488b5c2450 mov rbx,qword ptr [rsp+50h]
fffff8009175c747 488b6c2458 mov rbp,qword ptr [rsp+58h]<br>fffff8009175c74c 488b742460 mov rsi,qword ptr [rsp+60h]
fffff8009175c751 4883c420 add rsp,20h<br>fffff8009175c755 415f pop r15
fffff8009175c757 415e pop r14<br>fffff8009175c759 415d pop r13
fffff8009175c75b 415c pop r12<br>fffff8009175c75d 5f pop rdi
fffff8009175c75e c3 ret<br><br>Is this correct ?<br><br>Here is the kernel version as displayed by the debugger:<br><br>kd&gt; vertarget<br>Windows 10 Kernel Version 10240 MP (1 procs) Free x64 Built by: 10240.17071.amd64fre.th1.160802-1852<br>Machine Name:<br>Kernel base = 0xfffff8009120b000 PsLoadedModuleList = 0xfffff800`91530070 Debug session time: Tue Aug 23 16:55:46.143 2016 (UTC - 4:00) System Uptime: 0 days 0:00:05.249

—
NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>