Add qhelp and md files for the new memory queries.

Author: NateD-MSFT

src/microsoft/Likely Bugs/Memory Management/ConditionallyUninitializedVariableAutomation.md

@@ -0,0 +1,80 @@
+# Conditionally uninitialized variable
+A common pattern is to initialize a local variable by calling another function (an "initialization" function) with the address of the local variable as a pointer argument. That function is then responsible for writing to the memory location referenced by the pointer.
+
+In some cases, the called function may not always write to the memory pointed to by the pointer argument. In such cases, the function will typically return a "status" code, informing the caller as to whether the initialization succeeded or not. If the caller does not check the status code before reading the local variable, it may read uninitialized memory, which can result in unexpected behavior.
+
+
+## Recommendation
+When using an initialization function that does not guarantee to initialize the memory pointed to by the passed pointer, and returns a status code to indicate whether such initialization occurred, the status code should be checked before reading from the local variable.
+
+
+## Example
+In this hypothetical example we have code for managing a series of devices. The code includes a `DeviceConfig` struct that can represent properties about each device. The `initDeviceConfig` function can be called to initialize one of these structures, by providing a "device number", which can be used to look up the appropriate properties in some data store. If an invalid device number is provided, the function returns a status code of `-1`, and does not initialize the provided pointer.
+
+In the first code sample below, the `notify` function calls the `initDeviceConfig` function with a pointer to the local variable `config`, which is then subsequently accessed to fetch properties of the device. However, the code does not check the return value from the function call to `initDeviceConfig`. If the device number passed to the `notify` function was invalid, the `initDeviceConfig` function will leave the `config` variable uninitialized, which will result in the `notify` function accessing uninitialized memory.
+
+
+```c
+struct DeviceConfig {
+  bool isEnabled;
+  int channel;
+};
+
+int initDeviceConfig(DeviceConfig *ref, int deviceNumber) {
+  if (deviceNumber >= getMaxDevices()) {
+    // No device with that number, return -1 to indicate failure
+    return -1;
+  }
+  // Device with that number, fetch parameters and initialize struct
+  ref->isEnabled = fetchIsDeviceEnabled(deviceNumber);
+  ref->channel = fetchDeviceChannel(deviceNumber);
+  // Return 0 to indicate success
+  return 0;
+}
+
+int notify(int deviceNumber) {
+  DeviceConfig config;
+  initDeviceConfig(&config, deviceNumber);
+  // BAD: Using config without checking the status code that is returned
+  if (config.isEnabled) {
+    notifyChannel(config.channel);
+  }
+}
+
+```
+To fix this, the code needs to check that the return value of the call to `initDeviceConfig` is zero. If that is true, then the calling code can safely assume that the local variable has been initialized.
+
+
+```c
+struct DeviceConfig {
+  bool isEnabled;
+  int channel;
+};
+
+int initDeviceConfig(DeviceConfig *ref, int deviceNumber) {
+  if (deviceNumber >= getMaxDevices()) {
+    // No device with that number, return -1 to indicate failure
+    return -1;
+  }
+  // Device with that number, fetch parameters and initialize struct
+  ref->isEnabled = fetchIsDeviceEnabled(deviceNumber);
+  ref->channel = fetchDeviceChannel(deviceNumber);
+  // Return 0 to indicate success
+  return 0;
+}
+
+void notify(int deviceNumber) {
+  DeviceConfig config;
+  int statusCode = initDeviceConfig(&config, deviceNumber);
+  if (statusCode == 0) {
+    // GOOD: Status code returned by initialization function is checked, so this is safe
+    if (config.isEnabled) {
+      notifyChannel(config.channel);
+    }
+  }
+}
+
+```
+
+## References
+* Wikipedia: [Uninitialized variable](https://en.wikipedia.org/wiki/Uninitialized_variable).

src/microsoft/Likely Bugs/Memory Management/ConditionallyUninitializedVariableAutomation.qhelp

@@ -0,0 +1,59 @@
+<!DOCTYPE qhelp PUBLIC
+  "-//Semmle//qhelp//EN"
+  "qhelp.dtd">
+<qhelp>
+
+<overview>
+<p>A common pattern is to initialize a local variable by calling another function (an
+"initialization" function) with the address of the local variable as a pointer argument. That
+function is then responsible for writing to the memory location referenced by the pointer.</p>
+
+<p>In some cases, the called function may not always write to the memory pointed to by the
+pointer argument. In such cases, the function will typically return a "status" code, informing the
+caller as to whether the initialization succeeded or not. If the caller does not check the status
+code before reading the local variable, it may read uninitialized memory, which can result in
+unexpected behavior.</p>
+
+</overview>
+<recommendation>
+
+<p>When using an initialization function that does not guarantee to initialize the memory pointed to
+by the passed pointer, and returns a status code to indicate whether such initialization occurred,
+the status code should be checked before reading from the local variable.</p>
+
+</recommendation>
+<example>
+
+<p>In this hypothetical example we have code for managing a series of devices. The code
+includes a <code>DeviceConfig</code> struct that can represent properties about each device.
+The <code>initDeviceConfig</code> function can be called to initialize one of these structures, by
+providing a "device number", which can be used to look up the appropriate properties in some data
+store. If an invalid device number is provided, the function returns a status code of
+<code>-1</code>, and does not initialize the provided pointer.</p>
+
+<p>In the first code sample below, the <code>notify</code> function calls the
+<code>initDeviceConfig</code> function with a pointer to the local variable <code>config</code>,
+which is then subsequently accessed to fetch properties of the device. However, the code does not
+check the return value from the function call to <code>initDeviceConfig</code>. If the
+device number passed to the <code>notify</code> function was invalid, the
+<code>initDeviceConfig</code> function will leave the <code>config</code> variable uninitialized,
+which will result in the <code>notify</code> function accessing uninitialized memory.</p>
+
+<sample src="ConditionallyUninitializedVariableBad.c" />
+
+<p>To fix this, the code needs to check that the return value of the call to
+<code>initDeviceConfig</code> is zero. If that is true, then the calling code can safely assume
+that the local variable has been initialized.</p>
+
+<sample src="ConditionallyUninitializedVariableGood.c" />
+
+</example>
+<references>
+
+<li>
+  Wikipedia:
+  <a href="https://en.wikipedia.org/wiki/Uninitialized_variable">Uninitialized variable</a>.
+</li>
+
+</references>
+</qhelp>

src/microsoft/Likely Bugs/Memory Management/ConditionallyUninitializedVariableBad.c

@@ -0,0 +1,25 @@
+struct DeviceConfig {
+  bool isEnabled;
+  int channel;
+};
+
+int initDeviceConfig(DeviceConfig *ref, int deviceNumber) {
+  if (deviceNumber >= getMaxDevices()) {
+    // No device with that number, return -1 to indicate failure
+    return -1;
+  }
+  // Device with that number, fetch parameters and initialize struct
+  ref->isEnabled = fetchIsDeviceEnabled(deviceNumber);
+  ref->channel = fetchDeviceChannel(deviceNumber);
+  // Return 0 to indicate success
+  return 0;
+}
+
+int notify(int deviceNumber) {
+  DeviceConfig config;
+  initDeviceConfig(&config, deviceNumber);
+  // BAD: Using config without checking the status code that is returned
+  if (config.isEnabled) {
+    notifyChannel(config.channel);
+  }
+}

src/microsoft/Likely Bugs/Memory Management/ConditionallyUninitializedVariableGood.c

@@ -0,0 +1,27 @@
+struct DeviceConfig {
+  bool isEnabled;
+  int channel;
+};
+
+int initDeviceConfig(DeviceConfig *ref, int deviceNumber) {
+  if (deviceNumber >= getMaxDevices()) {
+    // No device with that number, return -1 to indicate failure
+    return -1;
+  }
+  // Device with that number, fetch parameters and initialize struct
+  ref->isEnabled = fetchIsDeviceEnabled(deviceNumber);
+  ref->channel = fetchDeviceChannel(deviceNumber);
+  // Return 0 to indicate success
+  return 0;
+}
+
+void notify(int deviceNumber) {
+  DeviceConfig config;
+  int statusCode = initDeviceConfig(&config, deviceNumber);
+  if (statusCode == 0) {
+    // GOOD: Status code returned by initialization function is checked, so this is safe
+    if (config.isEnabled) {
+      notifyChannel(config.channel);
+    }
+  }
+}

src/microsoft/Likely Bugs/Memory Management/UnprobedDereference.md

@@ -0,0 +1,12 @@
+# User provided pointer dereferenced without a probe.
+In low-level Windows kernel code, dereferencing a pointer originating from user mode is dangerous if the pointer has not been validated (probed). An unvalidated pointer may point to privileged kernel memory or invalid addresses. Using proper user-mode accessors such as `ReadULongFromUser` or probing via APIs such as `ProbeForRead` ensures that invalid or malicious user-supplied addresses do not compromise the kernel.
+
+
+## Recommendation
+Before dereferencing pointers from user memory in kernel-mode code, always validate them.
+
+
+## References
+* Microsoft Learn: [User-mode accessors](https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/user-mode-accessors).
+* Microsoft Learn: [ProbeForRead](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-probeforread).
+* Common Weakness Enumeration: [CWE-668](https://cwe.mitre.org/data/definitions/668.html).

src/microsoft/Likely Bugs/Memory Management/UnprobedDereference.qhelp

@@ -0,0 +1,24 @@
+<!DOCTYPE qhelp PUBLIC
+  "-//Semmle//qhelp//EN"
+  "qhelp.dtd">
+<qhelp>
+  <overview>
+    <p>In low-level Windows kernel code, dereferencing a pointer originating from user mode is dangerous if the pointer has not been validated (probed). 
+    An unvalidated pointer may point to privileged kernel memory or invalid addresses.
+    Using proper user-mode accessors such as <code>ReadULongFromUser</code> or probing via APIs such as <code>ProbeForRead</code> ensures that invalid or malicious user-supplied addresses do not compromise the kernel.</p>
+  </overview>
+
+  <recommendation>
+    <p>Before dereferencing pointers from user memory in kernel-mode code, always validate them.</p>
+  </recommendation>
+    <references>
+    <li>
+    Microsoft Learn:
+    <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/user-mode-accessors">User-mode accessors</a>.
+    </li>
+    <li>
+    Microsoft Learn:
+    <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-probeforread">ProbeForRead</a>.
+    </li>
+    </references>
+</qhelp>