Re: notoskrnl.exe: Fix the stack overflow bugs in raising exceptions(DLL_PROCESS_DETACH processing for DllMain in ntoskrnl.c)

[Dmitry Timoshkov]

"Anton Rudnev" <mibori(a)etersoft.ru> wrote:
> --- a/dlls/ntoskrnl.exe/ntoskrnl.c
> +++ b/dlls/ntoskrnl.exe/ntoskrnl.c
> @@ -886,14 +886,20 @@ NTSTATUS WINAPI PsSetCreateProcessNotifyRoutine( PCREATE_PROCESS_NOTIFY_ROUTINE
>  BOOL WINAPI DllMain( HINSTANCE inst, DWORD reason, LPVOID reserved )
>  {
>      LARGE_INTEGER count;
> +    static vectored_handler_added = NULL;
>
> switch(reason)
>      {
>      case DLL_PROCESS_ATTACH:
>          DisableThreadLibraryCalls( inst );
> -        RtlAddVectoredExceptionHandler( TRUE, vectored_handler );
> +        vectored_handler_added = RtlAddVectoredExceptionHandler( TRUE, vectored_handler );
>          KeQueryTickCount( &count );  /* initialize the global KeTickCount */
>          break;
> +    case DLL_PROCESS_DETACH:
> +        if(vectored_handler_added){
> +            RtlRemoveVectoredExceptionHandler(vectored_handler_added);
> +            vectored_handler_added = NULL;
> +        }
>      }
>      return TRUE;
>  }

What you want is find out why RtlAddVectoredExceptionHandler fails for you,
because it shouldn't fail normally.

-- 
Dmitry.

notoskrnl.exe: Fix the stack overflow bugs in raising exceptions(DLL_PROCESS_DETACH processing for DllMain in ntoskrnl.c)

[Anton Rudnev]

RtlAddVectoredHandler is never fail.
vectored_handler_added store adress of handler for DLL_PROCESS_DETACH-case.
If vectored_handler_added is null then handler is not been added at 
DLL_PROCESS_ATTACH-case.
If handler not has been removed in DLL_PROCESS_DETACH-case, then called it 
after FreeLibrary (at raise exception).
This raise new exception, raise new exception, ... and stack overflow.

Saturday 11 October 2008 16:38:14 Dmitry Timoshkov:
> "Anton Rudnev" <mibori(a)etersoft.ru> wrote:
> > --- a/dlls/ntoskrnl.exe/ntoskrnl.c
> > +++ b/dlls/ntoskrnl.exe/ntoskrnl.c
> > @@ -886,14 +886,20 @@ NTSTATUS WINAPI PsSetCreateProcessNotifyRoutine(
> > PCREATE_PROCESS_NOTIFY_ROUTINE BOOL WINAPI DllMain( HINSTANCE inst, DWORD
> > reason, LPVOID reserved ) {
> >      LARGE_INTEGER count;
> > +    static vectored_handler_added = NULL;
> >
> > switch(reason)
> >      {
> >      case DLL_PROCESS_ATTACH:
> >          DisableThreadLibraryCalls( inst );
> > -        RtlAddVectoredExceptionHandler( TRUE, vectored_handler );
> > +        vectored_handler_added = RtlAddVectoredExceptionHandler( TRUE,
> > vectored_handler ); KeQueryTickCount( &count );  /* initialize the global
> > KeTickCount */ break;
> > +    case DLL_PROCESS_DETACH:
> > +        if(vectored_handler_added){
> > +            RtlRemoveVectoredExceptionHandler(vectored_handler_added);
> > +            vectored_handler_added = NULL;
> > +        }
> >      }
> >      return TRUE;
> >  }
>
> What you want is find out why RtlAddVectoredExceptionHandler fails for you,
> because it shouldn't fail normally.

notoskrnl.exe: Fix the stack overflow bugs in raising exceptions(DLL_PROCESS_DETACH processing for DllMain in ntoskrnl.c)

[Dmitry Timoshkov]

"Anton Rudnev" <mibori(a)etersoft.ru> wrote:
> RtlAddVectoredHandler is never fail.
> vectored_handler_added store adress of handler for DLL_PROCESS_DETACH-case.
> If vectored_handler_added is null then handler is not been added at 
> DLL_PROCESS_ATTACH-case.

This shouldn't happen.
> If handler not has been removed in DLL_PROCESS_DETACH-case, then called it 
> after FreeLibrary (at raise exception).

Then what you need is just add a DLL_PROCESS_DETACH handler. There is no
need to check vectored_handler_added for NULL in this case. Also make
sure to declare vectored_handler_added with a proper type.

-- 
Dmitry.