Bring several memory and access safety queries in from internal repo. (#208)

* Bring several memory queries+libraries into public repo.

* Add qhelp and md files for the new memory queries.

* Adjust IDs for new memory queries

* Move the MS libraries to a public folder.

* Update QLPack version and changelog.

* Standardize copyright headers and emails.

* Fix filenames for ConditionallyUninitializedVariable

Author: NateD-MSFT

CHANGELOG.md

@@ -2,6 +2,19 @@
 # Change Log
 All notable changes to this project will be documented in this file.
 
+## [1.9.0] - 2026-02-27
+
+### Added
+ - Added five new queries in the Microsoft subfolder.  These queries are now part of our recommended and must-run sets.
+     - ConditionallyUninitializedVariableAutomation.ql: Flags calls to initialization functions whose return status is not checked, potentially leaving a local variable uninitialized.
+     - UnprobedDereference.ql: Detects dereferences of user-provided pointers that haven't been probed first, which could cause access violations.
+     - UserModeMemoryOutsideTry.ql: Finds reads of user-mode memory that occur outside a try/catch block, where unexpected exceptions from changed memory protections could crash the kernel.
+     - UserModeMemoryReadMultipleTimes.ql: identifies double-fetch vulnerabilities where user-mode memory is read more than once without being copied to kernel memory first.
+     - UnguardedNullReturnDereference.ql: Reports dereferences of return values from calls that may return NULL (e.g. heap allocations) without a preceding null check.
+
+### Changed
+ - Standardized the rule ID of UninitializedPtrField.ql to "cpp/microsoft/public/likely-bugs/uninitializedptrfield" and updated accuracy.
+
 ## [1.8.3] - 2026-02-25
 
 ### Changed

src/microsoft/Likely Bugs/Memory Management/ConditionallyUninitializedVariable.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/ConditionallyUninitializedVariable.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/ConditionallyUninitializedVariable.ql

@@ -0,0 +1,30 @@
+// Copyright (c) Microsoft Corporation.
+// Licensed under the MIT license.
+/**
+* @id cpp/microsoft/public/likely-bugs/memory-management/v2/conditionally-uninitialized-variable
+* @name Conditionally uninitialized variable
+* @description When an initialization function is used to initialize a local variable,
+*              but the returned status code is not checked, reading the variable may
+*              result in undefined behaviour.
+* @platform Desktop
+* @security.severity Low
+* @impact Insecure Coding Practice
+* @feature.area Multiple 
+* @repro.text The following code locations potentially contain uninitialized variables
+* @owner.email sdat@microsoft.com
+* @kind problem
+* @problem.severity error
+* @query-version 2.0
+**/
+
+import cpp
+private import UninitializedVariables
+
+from ConditionallyInitializedVariable v, ConditionalInitializationFunction f, ConditionalInitializationCall call, Evidence e
+where exists(v.getARiskyAccess(f, call, e))
+  and e = DefinitionInSnapshot()
+select call, "$@: The status of this call to $@ is not checked, potentially leaving $@ uninitialized.",
+    call.getEnclosingFunction(),
+    call.getEnclosingFunction().toString(),
+	f, f.getName(),
+	v, v.getName()

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);
+    }
+  }
+}