[Bug 33849] Multiple 64-bit kernel drivers crash on access to KI_USER_SHARED_DATA range (0xfffff78000000000) (Tages DRM, Comodo Backup)

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=33849

Sebastian Lackner <sebastian at fds-team.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sebastian at fds-team.de

--- Comment #11 from Sebastian Lackner <sebastian at fds-team.de> ---
Created attachment 49951
  --> https://bugs.winehq.org/attachment.cgi?id=49951
preliminary 64-bit instruction emulator for ntoskrnl

The following quick & dirty patch implements a 64-bit ntoskrnl instruction
emulator for the KI_USER_SHARED_DATA page. I'll clean it up / check for errors
during the next few days and then add it to the staging tree / try to submit
it.

Please note that the data is not filled yet, but even a buffer filled with
zeros seems to be sufficient to get around the first crash. Nevertheless,
shortly afterwards, we get immediately the next crash.

--- snip ---
0044:trace:seh:raise_exception code=c0000005 flags=0 addr=0x447117 ip=447117
tid=0044
0044:trace:seh:raise_exception  rax=5555555555555555 rbx=0000000000000000
rcx=0000000000011ed0 rdx=000000000043dfa0
0044:trace:seh:raise_exception  rsi=00007fd69798fcc1 rdi=00007fd695e24bf1
rbp=000000000043e0a0 rsp=000000000043dd30
0044:trace:seh:raise_exception   r8=00007fd6975f0a75  r9=000000000043e184
r10=000000000022e013 r11=0000000000000293
0044:trace:seh:raise_exception  r12=0000000000012018 r13=000000000043f700
r14=0000000000000000 r15=000000000033df90
--- snip ---

Instruction causing the exception:
--- snip ---
    .data:0x00000000    8b4818    mov    ecx,DWORD PTR [rax+0x18]
--- snip ---

No exception information is available, which means we arrived there using the
following code path in ntdll/signal_x86_64.c (sic!):

--- snip ---
    case TRAP_x86_SEGNPFLT:  /* Segment not present exception */
    case TRAP_x86_PROTFLT:   /* General protection fault */
    case TRAP_x86_UNKNOWN:   /* Unknown fault code */
        rec->ExceptionCode = ERROR_sig(ucontext) ? EXCEPTION_ACCESS_VIOLATION :
EXCEPTION_PRIV_INSTRUCTION;
        rec->ExceptionCode = EXCEPTION_ACCESS_VIOLATION;
        break;
--- snip ---

The number 0x55555... looks like it could come from the following function in
ntoskrnl.c:

--- snip ---
/* process an ioctl request for a given device */
static NTSTATUS process_ioctl( DEVICE_OBJECT *device, ULONG code, void
*in_buff, ULONG in_size,
                               void *out_buff, ULONG *out_size )
{
    IRP irp;
    MDL mdl;
    IO_STACK_LOCATION irpsp;
    PDRIVER_DISPATCH dispatch =
device->DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL];
    NTSTATUS status;
    LARGE_INTEGER count;

    TRACE( "ioctl %x device %p in_size %u out_size %u\n", code, device,
in_size, *out_size );

    /* so we can spot things that we should initialize */
    memset( &irp, 0x55, sizeof(irp) ); <---------------
    memset( &irpsp, 0x66, sizeof(irpsp) );
    memset( &mdl, 0x77, sizeof(mdl) );
--- snip ---

@Anastatius: Could you please confirm that this is a different bug?

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.