BSOD with DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

NTDEV
1

Hi all,

I got BSOD with DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1).
The source code is :

pXferParams->BytesTransferred = 0;

It looks like the driver tried to access the memory which has been paged out.

The crash dump is :
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000020, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, value 0 = read operation, 1 = write operation
Arg4: fffff880056e0f7b, address which referenced memory

Since 0x20 is the reference address, can I assume that I have accessed a NULL pointer?

best regards

Xiang Chao

2

Yes, BytesTransferred is at offset 0x20 in your data structure.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Sunday, March 6, 2016 9:59 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] BSOD with DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

Hi all,

I got BSOD with DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1).
The source code is :

pXferParams->BytesTransferred = 0;

It looks like the driver tried to access the memory which has been paged out.

The crash dump is :
An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000020, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, value 0 = read operation, 1 = write operation
Arg4: fffff880056e0f7b, address which referenced memory

Since 0x20 is the reference address, can I assume that I have accessed a NULL pointer?

best regards

Xiang Chao

—
NTDEV is sponsored by OSR

Visit the list online at: https:

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

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

3

This is the code snippet where error happens:

if (pDesc->XFER_PARAMS != NULL)
{
_InterlockedIncrement(&pDMAExt->AvailNumberDescriptors);
// Read the Transaction Pointer.
pXferParams = pDesc->XFER_PARAMS;
// Clear the DMA Trans link.
pDesc->XFER_PARAMS = NULL;

if (CachedStatusCount & DMA_DESC_SOP)
{
// Since this is the first DMA Descriptor, reset the byte count.
-----------------------------------------> pXferParams->BytesTransferred = 0;
// And the status…
pXferParams->Status = 0;
}

I have just checked that pDesc->XFER_PARAMS != NULL, why pXferParams became NULL after just one line of code?

best regards

Xiang Chao

4

> On Mar 7, 2016, at 6:33 PM, xxxxx@gmail.com wrote:

This is the code snippet where error happens:

if (pDesc->XFER_PARAMS != NULL)
{
_InterlockedIncrement(&pDMAExt->AvailNumberDescriptors);
// Read the Transaction Pointer.
pXferParams = pDesc->XFER_PARAMS;
// Clear the DMA Trans link.
pDesc->XFER_PARAMS = NULL;

if (CachedStatusCount & DMA_DESC_SOP)
{
// Since this is the first DMA Descriptor, reset the byte count.
-----------------------------------------> pXferParams->BytesTransferred = 0;
// And the status…
pXferParams->Status = 0;
}

I have just checked that pDesc->XFER_PARAMS != NULL, why pXferParams became NULL after just one line of code?

Well, it depends how often this gets executed. It doesn’t matter how narrow the vulnerability is, as long as there is a hole, sooner or later you’re going to fall into it. If there is a potential for this to be executed in multiple processors at once, then you MUST protect this with a lock.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.