How can I report WSL Related BSODs?

[bushidocodes]

Dear WSL Team,

I followed the directions in your template regarding BSODs:

**Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues.** Please direct all Windows crashes and security issues to secure@microsoft.com. Ideally, please [configure your machine to capture minidumps](https://support.microsoft.com/en-us/help/315263/how-to-read-the-small-memory-dump-file-that-is-created-by-windows-if-a), repro the issue, and send the minidump from "C:\Windows\minidump\".

However, my case was given a pro-forma response requesting "valid proof of concept (POC) ideally with images or video that prove exploitability." This suggests to me that something is possibly broken with your process.

I repeatedly get hard crashes when solving Rust coding Katas via Exercism. The BSOD is as follows. I have captured minidumps, Please clarify how to report this issue and securely submit the minidumps.

[stephen45ss]

Buffer overflow most likely caused by a call in the lxcore.sys driver. Not sure exactly what you where trying to do before the crash plus if it's your source code that causing it that's basically you PoC or proof of concept. You'd have to examine the exact place in memory the system crashed to figure the exact code that caused the crash. Still I find stuff like this interesting since I like figuring out how things work. Sadly I've had issues with my WSL 2 not working at all after a visual studio install. Not sure if that's the cause or not but oh well. But you should inform them of the issue via email with a snippet of your code or all of with the dumps. Plus I'm assuming you using WSL version 1 so I suggest using version 2 of WSL.

[bushidocodes]

@stephen45ss - Thank you for the suggestions! I was using the Rust compiler, Rust language service, VSCode Remote WSL stuff, and Exercism.io. I actually tried WSL2 and the fast ring a few weeks back, but there were bugs with my preferred distro (Pengwin), so I rolled back. Ideally, I'm hoping to hold out until 20H1 features land on the Slow Ring so I can maintain a bit more stability. Is secure@microsoft.com the correct address to send my minidumps to?

This is the automated response I received, which suggests to me that nobody has reviewed them: """ Hello,

Thank you for contacting the Microsoft Security Response Center (MSRC). In order to investigate your report we need a description of the potential security vulnerability in a Microsoft product along with the details of the environment such as OS Version + Build numbers, along with a valid proof of concept (POC) ideally with images or video that prove exploitability, the detailed steps to reproduce the problem, and how an attacker could use it to exploit another user.

This thread is being closed and no longer monitored. When ready, submit a new email to secure@microsoft.com without a CRM number in the subject line. Please include:

Relevant information previously provided in your initial report Detailed steps required to consistently reproduce the issue Short explanation on how an attacker could use the information to exploit another user remotely Proof-of-concept (POC), such as a video recording, crash reports, screenshots, or relevant code samples The following links should answer most of your questions:

"Report a Computer Security Vulnerability"
<https://technet.microsoft.com/en-us/security/ff852094.aspx>

"Frequently Asked Questions about Microsoft Bug Bounty Programs"
<https://technet.microsoft.com/en-us/library/dn425055.aspx>

"Microsoft Security Response Center PGP Key"
<https://technet.microsoft.com/en-us/security/dn606155.aspx>

"Microsoft Bounty Programs"
<https://technet.microsoft.com/en-us/library/dn425036.aspx>

Regards,

MSRC """

[stephen45ss]

Sadly that is the correct email address. I think the only way they'll fix the issue is if you can prove it's a large security issue by reproducing it then actually finding a way to use the bug to control the system or demonstrate arbitrary code execution is possible. Basically you got prove it's a security risk or they'll ignore it till later

[mickdekkers]

I'm having the same issue with the same setup; I'm also developing Rust in VSCode with the remote WSL extension on WSL1. This looks related to https://github.com/microsoft/WSL/issues/4537#issuecomment-565853216

I opened the BSOD memory dumps in WinDbg Preview. Running !analyze -v there reveals some interesting information:

For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff800`36dc14e0 48894c2408      mov     qword ptr [rsp+8],rcx ss:0018:ffff8207`9b63df00=0000000000000139
4: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure.  The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: ffff82079b63e220, Address of the trap frame for the exception that caused the bugcheck
Arg3: ffff82079b63e178, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved

Debugging Details:
------------------

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.Sec
    Value: 3

    Key  : Analysis.DebugAnalysisProvider.CPP
    Value: Create: 8007007e on DESKTOP-VT84SS7

    Key  : Analysis.DebugData
    Value: CreateObject

    Key  : Analysis.DebugModel
    Value: CreateObject

    Key  : Analysis.Elapsed.Sec
    Value: 10

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 68

    Key  : Analysis.System
    Value: CreateObject

ADDITIONAL_XML: 1

BUGCHECK_CODE:  139

BUGCHECK_P1: 3

BUGCHECK_P2: ffff82079b63e220

BUGCHECK_P3: ffff82079b63e178

BUGCHECK_P4: 0

TRAP_FRAME:  ffff82079b63e220 -- (.trap 0xffff82079b63e220)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffda85f3f8d268 rbx=0000000000000000 rcx=0000000000000003
rdx=ffffda85dd719388 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8003207f86c rsp=ffff82079b63e3b0 rbp=00000000000007c6
 r8=ffff82079b63e2f8  r9=00000000ffffffff r10=fffff80036c38fe0
r11=ffffb37d7d800000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na pe cy
LXCORE!LxpInotifyAddWatch+0x398:
fffff800`3207f86c cd29            int     29h
Resetting default scope

EXCEPTION_RECORD:  ffff82079b63e178 -- (.exr 0xffff82079b63e178)
ExceptionAddress: fffff8003207f86c (LXCORE!LxpInotifyAddWatch+0x0000000000000398)
   ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 0000000000000003
Subcode: 0x3 FAST_FAIL_CORRUPT_LIST_ENTRY 

PROCESS_NAME:  node

ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

EXCEPTION_CODE_STR:  c0000409

EXCEPTION_PARAMETER1:  0000000000000003

EXCEPTION_STR:  0xc0000409

STACK_TEXT:  
ffff8207`9b63def8 fffff800`36dd32e9 : 00000000`00000139 00000000`00000003 ffff8207`9b63e220 ffff8207`9b63e178 : nt!KeBugCheckEx
ffff8207`9b63df00 fffff800`36dd3710 : ffff8207`9b63e2b0 fffff800`320442e0 00000000`00000002 fffff800`36f6f0a9 : nt!KiBugCheckDispatch+0x69
ffff8207`9b63e040 fffff800`36dd1aa5 : ffffda85`f3b4ec78 00000000`00000000 00000000`fffffffe ffffda85`f2e84940 : nt!KiFastFailDispatch+0xd0
ffff8207`9b63e220 fffff800`3207f86c : ffffda85`f3b4eba0 00000000`000007c6 ffffda86`0802b010 ffffda85`e95b5fc0 : nt!KiRaiseSecurityCheckFailure+0x325
ffff8207`9b63e3b0 fffff800`32099dce : ffff8207`9b63e470 00000000`00000000 00007faf`bc00e278 00000000`000007c6 : LXCORE!LxpInotifyAddWatch+0x398
ffff8207`9b63e440 fffff800`32095944 : fffff800`3203b630 ffff8207`9b63e5f0 00007faf`bc00e278 ffffda85`f3f8d250 : LXCORE!LxpSyscall_INOTIFY_ADD_WATCH+0xfe
ffff8207`9b63e4f0 fffff800`320b2df1 : ffffa188`3f8c5500 ffff8207`9b63eb00 00007faf`bc00e278 00000000`00000013 : LXCORE!LxpSysDispatch+0x114
ffff8207`9b63eaa0 fffff800`374cb80f : ffffffff`ffffffd2 fffff800`36dd2af3 00000000`00000050 fffff800`36dc7bc5 : LXCORE!PicoSystemCallDispatch+0x11
ffff8207`9b63ead0 fffff800`36dd2af8 : ffff8207`9b63eb00 ffff8207`9b63eb80 ffffa188`3f8d1b00 00000000`00000000 : nt!PsPicoSystemCallDispatch+0x1f
ffff8207`9b63eb00 00007faf`e51922d7 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceUser+0x76
00007faf`c6fcdae8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007faf`e51922d7

SYMBOL_NAME:  LXCORE!LxpInotifyAddWatch+398

MODULE_NAME: LXCORE

IMAGE_NAME:  LXCORE.SYS

STACK_COMMAND:  .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET:  398

FAILURE_BUCKET_ID:  0x139_3_CORRUPT_LIST_ENTRY_LXCORE!LxpInotifyAddWatch

OS_VERSION:  10.0.18362.1

BUILDLAB_STR:  19h1_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {4c1eca5b-9534-301f-a18f-c55d5a55603f}

Followup:     MachineOwner
---------

I'm not familiar enough with the internals of Windows to make much sense of this, but this part looks especially interesting:

ExceptionAddress: fffff8003207f86c (LXCORE!LxpInotifyAddWatch+0x0000000000000398)
   ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 0000000000000003
Subcode: 0x3 FAST_FAIL_CORRUPT_LIST_ENTRY 

PROCESS_NAME:  node

ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

The process that triggered the BSOD is node, and the issue appears to be related to the file watching mechanism (inotify). Given that VS Code makes use of file watching, it seems likely that the node process that caused the BSOD belongs to VS Code.

I hope posting it here helps someone track down the cause. If not, at least it will allow more people to Google the issue and find this thread.

[stephen45ss]

this is related to https://github.com/microsoft/WSL/issues/4537

[GeorgeFedoseev]

@mickdekkers I am having a similar issue and similar logs. I am running Ubuntu in WSL v1. I am trying to launch expo.io CLI, particularly running command expo start. I can see in task manager node process is taking a lot of CPU and after a minute of running, Windows crashes. Sometimes with VIDEO_MEMORY_MANAGEMENT_INTERNAL BSOD.

Update:
Moving my project from Windows FS to Linux home directory fixed the issue.

[microsoft-github-policy-service[bot]]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!