Uploaded image for project: 'Core ReactOS'
  1. Core ReactOS
  2. CORE-10395

CaretInfo use after free when running user32_apitest:AttachThreadInput

    XMLWordPrintable

    Details

      Description

      With special pool enabled for win32k (or USERTAG_Q), this happens when running user32:AttachThreadInfo:

      *** Fatal System Error: 0x000000d5
                             (0xF48F4FE4,0x00000000,0xF261B031,0x00000000)
       
      Driver at fault:
      ***    win32k.sys - Address F261B031 base at F258E000, DateStamp 562b3432
      .
      Break instruction exception - code 80000003 (first chance)
       
      A fatal system error has occurred.
      Debugger entered on first try; Bugcheck callbacks have not been invoked.
       
      A fatal system error has occurred.
       
      Connected to Windows Server 2003 3790 x86 compatible target at (Sat Oct 24 09:37:34.874 2015 (UTC + 2:00)), ptr64 FALSE
      Loading Kernel Symbols
      ....................................................
      Loading User Symbols
      ..............
      *******************************************************************************
      *                                                                             *
      *                        Bugcheck Analysis                                    *
      *                                                                             *
      *******************************************************************************
       
      Use !analyze -v to get detailed debugging information.
       
      BugCheck D5, {f48f4fe4, 0, f261b031, 0}
       
      Probably caused by : win32k.sys ( win32k!IntSendDestroyMsg+91 )
       
      Followup: MachineOwner
      ---------
       
      nt!RtlpBreakWithStatusInstruction:
      805188d8 cc              int     3
      kd> !analyze -v
      *******************************************************************************
      *                                                                             *
      *                        Bugcheck Analysis                                    *
      *                                                                             *
      *******************************************************************************
       
      DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)
      Memory was referenced after it was freed.
      This cannot be protected by try-except.
      When possible, the guilty driver's name (Unicode string) is printed on
      the bugcheck screen and saved in KiBugCheckDriver.
      Arguments:
      Arg1: f48f4fe4, memory referenced
      Arg2: 00000000, value 0 = read operation, 1 = write operation
      Arg3: f261b031, if non-zero, the address which referenced memory.
      Arg4: 00000000, (reserved)
       
      Debugging Details:
      ------------------
       
       
      READ_ADDRESS:  f48f4fe4
       
      FAULTING_IP:
      win32k!IntSendDestroyMsg+91 [c:\ros\reactos-clean\reactos\win32ss\user\ntuser\window.c @ 512]
      f261b031 8b0a            mov     ecx,dword ptr [edx]
       
      MM_INTERNAL_CODE:  0
       
      IMAGE_NAME:  win32k.sys
       
      DEBUG_FLR_IMAGE_TIMESTAMP:  562b3432
       
      MODULE_NAME: win32k
       
      FAULTING_MODULE: f258e000 win32k
       
      DEFAULT_BUCKET_ID:  DRIVER_FAULT
       
      BUGCHECK_STR:  0xD5
       
      PROCESS_NAME:  user32_apitest.
       
      CURRENT_IRQL:  1
       
      TRAP_FRAME:  00000010 -- (.trap 0x10)
      Unable to read trap frame at 00000010
       
      LAST_CONTROL_TRANSFER:  from 8047da96 to 805188d8
       
      STACK_TEXT:
      f20c4530 8047da96 00000003 f20c4850 ffdff408 nt!RtlpBreakWithStatusInstruction
      f20c4560 8047e371 00000003 00000000 00000000 nt!KiBugCheckDebugBreak+0x36 [c:\ros\reactos-clean\reactos\ntoskrnl\ke\bug.c @ 538]
      f20c48fc 8047e9ae 00000050 f48f4fe4 00000000 nt!KeBugCheckWithTf+0x551 [c:\ros\reactos-clean\reactos\ntoskrnl\ke\bug.c @ 1102]
      f20c491c 8049d009 00000050 f48f4fe4 00000000 nt!KeBugCheckEx+0x1e [c:\ros\reactos-clean\reactos\ntoskrnl\ke\bug.c @ 1462]
      f20c49f8 804bd86b 00000000 f48f4fe4 00000000 nt!MmArmAccessFault+0x739 [c:\ros\reactos-clean\reactos\ntoskrnl\mm\arm3\pagfault.c @ 1860]
      f20c4a14 804fd925 00000000 f48f4fe4 00000000 nt!MmAccessFault+0x10b [c:\ros\reactos-clean\reactos\ntoskrnl\mm\mmfault.c @ 251]
      f20c4a48 804036ef f20c4ad4 f261b031 badb0d00 nt!KiTrap0EHandler+0x195 [c:\ros\reactos-clean\reactos\ntoskrnl\ke\i386\traphdlr.c @ 1281]
      f20c4a48 f261b031 f20c4ad4 f261b031 badb0d00 nt!KiTrap0E+0x8f
      f20c4ad4 f261aed7 0003011c 00000001 bc6507d0 win32k!IntSendDestroyMsg+0x91 [c:\ros\reactos-clean\reactos\win32ss\user\ntuser\window.c @ 512]
      f20c4b38 f262835c bc658700 bc401ce8 01838e08 win32k!co_UserDestroyWindow+0x737 [c:\ros\reactos-clean\reactos\win32ss\user\ntuser\window.c @ 2819]
      f20c4b50 f25a7d11 bc40d708 f4838e08 00000001 win32k!UserDestroyObjectsForOwner+0x6c [c:\ros\reactos-clean\reactos\win32ss\user\ntuser\object.c @ 717]
      f20c4b90 f25a8152 b4945db0 00000001 805a8b20 win32k!ExitThreadCallback+0x221 [c:\ros\reactos-clean\reactos\win32ss\user\ntuser\main.c @ 754]
      f20c4bac 804d9dc6 b4945db0 00000001 00000000 win32k!Win32kThreadCallback+0xc2 [c:\ros\reactos-clean\reactos\win32ss\user\ntuser\main.c @ 865]
      f20c4c7c 804da1d5 00000000 00000000 f20c4ce0 nt!PspExitThread+0x6f6 [c:\ros\reactos-clean\reactos\ntoskrnl\ps\kill.c @ 747]
      f20c4c8c 8047c8f9 b4945a98 f20c4cdc f20c4cb8 nt!PsExitSpecialApc+0x45 [c:\ros\reactos-clean\reactos\ntoskrnl\ps\kill.c @ 942]
      f20c4ce0 804feb55 00000001 00000000 f20c4d64 nt!KiDeliverApc+0x339 [c:\ros\reactos-clean\reactos\ntoskrnl\ke\apc.c @ 481]
      f20c4cfc 804fe15d f20c4d64 f20c4d28 804fc545 nt!KiCheckForApcDelivery+0x65 [c:\ros\reactos-clean\reactos\ntoskrnl\include\internal\i386\ke.h @ 779]
      f20c4d08 804fc545 f20c4d64 00000000 00000001 nt!KiCommonExit+0xd [c:\ros\reactos-clean\reactos\ntoskrnl\ke\i386\traphdlr.c @ 100]
      f20c4d28 804fe0e0 ffdff6b8 00c7ff64 f20c4d64 nt!KiServiceExit+0x65 [c:\ros\reactos-clean\reactos\ntoskrnl\ke\i386\traphdlr.c @ 158]
      f20c4d5c 80403e13 00c7ff78 7c9493a4 badb0d00 nt!KiSystemServiceHandler+0x270 [c:\ros\reactos-clean\reactos\ntoskrnl\ke\i386\traphdlr.c @ 1752]
      f20c4d5c 7c9493a4 00c7ff78 7c9493a4 badb0d00 nt!KiFastCallEntry+0x8c
      00c7ff58 7c5d4faa 7c5c5563 00c7ff94 00000000 ntdll!KiFastSystemCallRet
      00c7ff5c 7c5c5563 00c7ff94 00000000 00000000 user32!ZwUserGetMessage+0xc
      00c7ff78 00401290 00c7ff94 00000000 00000000 user32!GetMessageA+0x33 [c:\ros\reactos-clean\reactos\win32ss\user\user32\windows\message.c @ 2054]
      00c7ffb8 7c7da124 0045b544 00000000 00000000 user32_apitest!thread_proc+0xa0 [c:\ros\reactos-clean\reactos\modules\rostests\apitests\user32\attachthreadinput.c @ 111]
      00c7ffec 00000000 004011f0 0045b544 00000000 kernel32!BaseThreadStartup+0x54 [c:\ros\reactos-clean\reactos\dll\win32\kernel32\client\thread.c @ 69]
       
       
      STACK_COMMAND:  kb
       
      FOLLOWUP_IP:
      win32k!IntSendDestroyMsg+91 [c:\ros\reactos-clean\reactos\win32ss\user\ntuser\window.c @ 512]
      f261b031 8b0a            mov     ecx,dword ptr [edx]
       
      FAULTING_SOURCE_CODE:
         508:             co_UserSetFocus(NULL);
         509:          }
         510:       }
         511:
      >  512:       if (ti->MessageQueue->CaretInfo->hWnd == UserHMGetHandle(Window))
         513:       {
         514:          co_IntDestroyCaret(ti);
         515:       }
         516:    }
         517:
       
       
      SYMBOL_STACK_INDEX:  8
       
      SYMBOL_NAME:  win32k!IntSendDestroyMsg+91
       
      FOLLOWUP_NAME:  MachineOwner
       
      FAILURE_BUCKET_ID:  0xD5_win32k!IntSendDestroyMsg+91
       
      BUCKET_ID:  0xD5_win32k!IntSendDestroyMsg+91
       
      Followup: MachineOwner
      ---------
       
      kd> ?? ti->MessageQueue
      struct _USER_MESSAGE_QUEUE * 0xf45b0f10
         +0x000 References       : 1
         +0x004 Desktop          : (null)
         +0x008 ptiSysLock       : (null)
         +0x00c idSysLock        : 0
         +0x010 idSysPeek        : 0
         +0x014 ptiMouse         : 0xf4838e08 _THREADINFO
         +0x018 ptiKeyboard      : 0xf4838e08 _THREADINFO
         +0x01c HardwareMessagesListHead : _LIST_ENTRY [ 0xf45b0f2c - 0xf45b0f2c ]
         +0x024 msgDblClk        : tagMSG
         +0x040 spwndCapture     : (null)
         +0x044 spwndFocus       : (null)
         +0x048 spwndActive      : (null)
         +0x04c spwndActivePrev  : (null)
         +0x050 MoveSize         : (null)
         +0x054 MenuOwner        : (null)
         +0x058 MenuState        : 0 ''
         +0x05c CaretInfo        : 0xf48f4fe4 _THRDCARETINFO
         +0x060 QF_flags         : 0x40
         +0x064 cThreads         : 1
         +0x068 ExtraInfo        : 0
         +0x06c afKeyRecentDown  : [32]  ""
         +0x08c afKeyState       : [64]  ""
         +0x0cc iCursorLevel     : 0
         +0x0d0 CursorObject     : 0xbc40dc58 _CURICON_OBJECT

      Cause:
      UserAttachThreadInput assigns

      ptiTo->MessageQueue->CaretInfo    = ptiFrom->MessageQueue->CaretInfo;

      but then immediately dereferences ptiFrom's MessageQueue, allowing it to be destroyed (which invalidates its CaretInfo pointer). The structure should probably simply be copied instead (which makes CaretInfo being a pointer useless, so the whole structure should likely just become part of the MessageQueue).

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                ThFabba ThFabba
                Reporter:
                ThFabba ThFabba
              • Votes:
                1 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: