Tidy up: indentation, ASCII-only comments, dedupe IFSM where, refresh SARIF baselines

Style and consistency cleanups uncovered during the final code review,
plus baseline regeneration so all checked-in SARIF baselines have
consistent (2-space) pretty-printing and reflect the current CodeQL
build's output:

* Irql.qll
  - whenConditionIsFalseAtCallSite: realign the new "!= NULL" and
    "(arg & 0x1) <op> 0" or-branches to match the indentation of the
    pre-existing "Param != 0" / "Param == N" branches (one extra
    leading space each before this change).
  - isInConstantFalseBranch: indent the predicate body to match the
    surrounding 1-space-leading column convention used throughout the
    file.

* Page.qll: replace "MacroInvocation x MacroInvocation" en-quad with
  ASCII "x" so the file is pure ASCII (matching the rest of the
  codebase).

* IrqlSetTooHigh.ql: replace em-dash with "--" in the same-line
  rationale comment for the lower-on-exit exemption.

* IrqlNotSaved.ql:
  - Replace em-dash in the "Only track flow to assignment targets or
    parameters" comment with a comma.
  - Rewrite the "exists(sink.asParameter())" idiom as
    "sink.asParameter() instanceof Parameter" for readability;
    behaviour is unchanged.

* IrqlFloatStateMismatch.ql:
  - Drop the now-redundant getName().matches("KeSave...") /
    getName().matches("KeRestore...") constraints from the where
    clause: the FloatStateFlow source/sink predicates already enforce
    them, so saveCall and restoreCall are uniquely bound by their
    arg(0) equalities. Adds a short explanatory comment.
  - Refresh the comment on the irqlChangesBetween conjunct so it no
    longer says "in the same function": the predicate now also
    handles one-level wrapper / common-caller patterns.

* Adversarial driver_snippet.c comments (IrqlTooHigh, IrqlTooLow,
  IrqlFloatStateMismatch): the original test headers described the
  pre-fix predicate behaviour ("under the current predicate they are
  not [flagged]" / "known false negative of the current
  intraprocedural filter"). Those statements no longer reflect
  reality: each adversarial case is now flagged by the corresponding
  query. Rewrote the headers to describe what the test now exercises
  (regression guards against the former FN classes).

* SARIF baselines: regenerated all six against the current CodeQL
  build using the in-tree test runner, then pretty-printed with
  2-space indent (matching the convention used by the majority of
  checked-in baselines under src/drivers/). MPC's baseline previously
  used a Jackson-style "key" : value formatting from the older
  CodeQL 2.11.5; the regenerated file uses the modern "key": value
  style consistent with the rest of the repo.

Validation: in-tree test runner reports +0/-0 for IrqlTooHigh,
IrqlTooLow, IrqlFloatStateMismatch, MultiplePagedCode, IrqlNotSaved,
and IrqlSetTooHigh. No query semantics changed.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: NateD-MSFT

src/drivers/general/queries/IrqlFloatStateMismatch/IrqlFloatStateMismatch.ql

@@ -142,18 +142,23 @@ from
   FunctionCall saveCall, FunctionCall restoreCall
 where
   FloatStateFlow::flow(source, sink) and
-  saveCall.getTarget().getName().matches("KeSaveFloatingPointState") and
+  // FloatStateFlow's source/sink predicates already restrict the flow's
+  // endpoints to be the first arguments of KeSaveFloatingPointState /
+  // KeRestoreFloatingPointState. The two arg(0) equalities below
+  // uniquely bind `saveCall` and `restoreCall` (each Expr has exactly
+  // one parent FunctionCall), without re-stating the function-name
+  // constraints.
   source.asIndirectExpr() = saveCall.getArgument(0) and
-  restoreCall.getTarget().getName().matches("KeRestoreFloatingPointState") and
   sink.asIndirectExpr() = restoreCall.getArgument(0) and
   irqlSource = getPotentialExitIrqlAtCfn(source.asIndirectExpr()) and
   irqlSink = getPotentialExitIrqlAtCfn(sink.asIndirectExpr()) and
   irqlSink != irqlSource and
-  // Only flag if there is an actual IRQL-changing call in the same function
-  // between save and restore (in source order). If no IRQL-changing call
-  // exists between them, the IRQL is invariant within a single invocation
-  // and the mismatch is a may-analysis artifact from different hypothetical
-  // entry IRQLs.
+  // Only flag if there is an actual IRQL-changing call between the save
+  // and the restore (in source order), in either the directly enclosing
+  // function or a one-level wrapper / common-caller. If no IRQL-changing
+  // call exists between them, the IRQL is invariant within a single
+  // invocation and the mismatch is a may-analysis artifact from
+  // different hypothetical entry IRQLs.
   irqlChangesBetween(saveCall, restoreCall)
 select sink.asIndirectExpr(),
   "The irql level where the floating-point state was saved (" + irqlSource +

src/drivers/general/queries/IrqlFloatStateMismatch/IrqlFloatStateMismatch.sarif

@@ -83,8 +83,8 @@
                 "level": "warning"
               },
               "help": {
-                "text": "# Irql Float State Mismatch\nThe IRQL where the floating-point state was saved does not match the current IRQL (for this restore operation).\n\n\n## Recommendation\nThe IRQL at which the driver is executing when it restores a floating-point state is different than the IRQL at which it was executing when it saved the floating-point state. Because the IRQL at which the driver runs determines how the floating-point state is saved, the driver must be executing at the same IRQL when it calls the functions to save and to restore the floating-point state.\n\n\n## Example\nExample of incorrect code. Floating point state was saved at APC_LEVEL but restored at PASSIVE_LEVEL\n\n```c\n \n\t\t_IRQL_requires_(PASSIVE_LEVEL) \n\t\tvoid driver_utility_bad(void)\n\t\t{\n\t\t\tKIRQL oldIRQL;\n\t\t\tKeRaiseIrql(APC_LEVEL, &oldIRQL);\n\t\t\t// running at APC level\n\t\t\tKFLOATING_SAVE FloatBuf;\n\t\t\tif (KeSaveFloatingPointState(&FloatBuf))\n\t\t\t{\n\t\t\t\tKeLowerIrql(oldIRQL); // lower back to PASSIVE_LEVEL\n\t\t\t\t// ...\n\t\t\t\tKeRestoreFloatingPointState(&FloatBuf);\n\t\t\t}\n\t\t}\n\t\t\n```\nCorrect example\n\n```c\n \n\t\t\t_IRQL_requires_(PASSIVE_LEVEL) \n\t\t\tvoid driver_utility_good(void)\n\t\t\t{\n\t\t\t\t// running at APC level\n\t\t\t\tKFLOATING_SAVE FloatBuf;\n\t\t\t\tKIRQL oldIRQL;\n\t\t\t\tKeRaiseIrql(APC_LEVEL, &oldIRQL);\n\n\t\t\t\tif (KeSaveFloatingPointState(&FloatBuf))\n\t\t\t\t{\n\t\t\t\t\tKeLowerIrql(oldIRQL);\n\t\t\t\t\t// ...\n\t\t\t\t\tKeRaiseIrql(APC_LEVEL, &oldIRQL);\n\t\t\t\t\tKeRestoreFloatingPointState(&FloatBuf);\n\t\t\t\t}\n\t\t\t}\n\t\t\n```\n\n## References\n* [ C28111 ](https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/28111-floating-point-irql-mismatch)\n\n## Semmle-specific notes\n**Known false negatives.** The query suppresses save / restore pairs when no IRQL-changing call sits between the save call and the restore call on a source line that lies textually within the enclosing function. This suppression eliminates a class of may-analysis false positives where the save and the restore are at the same IRQL within a single dynamic invocation but the IRQL inference reports different hypothetical entry IRQLs. The check has the following limitations:\n\n* **Cross-function save / restore.** When the save and the restore are routed through helper functions that wrap `KeSaveFloatingPointState` / `KeRestoreFloatingPointState`, and the IRQL change happens in the caller, no in-function intermediate call is found and the mismatch is silently suppressed.\n* **Indirect calls.** IRQL changes performed by an indirect call (function pointer or dispatch-table call) between save and restore are not detected, because the predicate only inspects the static call target.\n* **Loops where the restore is textually before the save.** The filter compares source line numbers; in a loop body whose first statement is the restore and last statement is the save (with the IRQL change after the save), the line range becomes empty and no intermediate IRQL change is seen.\nIf a real mismatch is being suppressed, eliminate the wrapper or add explicit `_IRQL_raises_` / `_IRQL_saves_global_` annotations to the helper so its IRQL behavior is visible without body inspection.\n\n",
-                "markdown": "# Irql Float State Mismatch\nThe IRQL where the floating-point state was saved does not match the current IRQL (for this restore operation).\n\n\n## Recommendation\nThe IRQL at which the driver is executing when it restores a floating-point state is different than the IRQL at which it was executing when it saved the floating-point state. Because the IRQL at which the driver runs determines how the floating-point state is saved, the driver must be executing at the same IRQL when it calls the functions to save and to restore the floating-point state.\n\n\n## Example\nExample of incorrect code. Floating point state was saved at APC_LEVEL but restored at PASSIVE_LEVEL\n\n```c\n \n\t\t_IRQL_requires_(PASSIVE_LEVEL) \n\t\tvoid driver_utility_bad(void)\n\t\t{\n\t\t\tKIRQL oldIRQL;\n\t\t\tKeRaiseIrql(APC_LEVEL, &oldIRQL);\n\t\t\t// running at APC level\n\t\t\tKFLOATING_SAVE FloatBuf;\n\t\t\tif (KeSaveFloatingPointState(&FloatBuf))\n\t\t\t{\n\t\t\t\tKeLowerIrql(oldIRQL); // lower back to PASSIVE_LEVEL\n\t\t\t\t// ...\n\t\t\t\tKeRestoreFloatingPointState(&FloatBuf);\n\t\t\t}\n\t\t}\n\t\t\n```\nCorrect example\n\n```c\n \n\t\t\t_IRQL_requires_(PASSIVE_LEVEL) \n\t\t\tvoid driver_utility_good(void)\n\t\t\t{\n\t\t\t\t// running at APC level\n\t\t\t\tKFLOATING_SAVE FloatBuf;\n\t\t\t\tKIRQL oldIRQL;\n\t\t\t\tKeRaiseIrql(APC_LEVEL, &oldIRQL);\n\n\t\t\t\tif (KeSaveFloatingPointState(&FloatBuf))\n\t\t\t\t{\n\t\t\t\t\tKeLowerIrql(oldIRQL);\n\t\t\t\t\t// ...\n\t\t\t\t\tKeRaiseIrql(APC_LEVEL, &oldIRQL);\n\t\t\t\t\tKeRestoreFloatingPointState(&FloatBuf);\n\t\t\t\t}\n\t\t\t}\n\t\t\n```\n\n## References\n* [ C28111 ](https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/28111-floating-point-irql-mismatch)\n\n## Semmle-specific notes\n**Known false negatives.** The query suppresses save / restore pairs when no IRQL-changing call sits between the save call and the restore call on a source line that lies textually within the enclosing function. This suppression eliminates a class of may-analysis false positives where the save and the restore are at the same IRQL within a single dynamic invocation but the IRQL inference reports different hypothetical entry IRQLs. The check has the following limitations:\n\n* **Cross-function save / restore.** When the save and the restore are routed through helper functions that wrap `KeSaveFloatingPointState` / `KeRestoreFloatingPointState`, and the IRQL change happens in the caller, no in-function intermediate call is found and the mismatch is silently suppressed.\n* **Indirect calls.** IRQL changes performed by an indirect call (function pointer or dispatch-table call) between save and restore are not detected, because the predicate only inspects the static call target.\n* **Loops where the restore is textually before the save.** The filter compares source line numbers; in a loop body whose first statement is the restore and last statement is the save (with the IRQL change after the save), the line range becomes empty and no intermediate IRQL change is seen.\nIf a real mismatch is being suppressed, eliminate the wrapper or add explicit `_IRQL_raises_` / `_IRQL_saves_global_` annotations to the helper so its IRQL behavior is visible without body inspection.\n\n"
+                "text": "# Irql Float State Mismatch\nThe IRQL where the floating-point state was saved does not match the current IRQL (for this restore operation).\n\n\n## Recommendation\nThe IRQL at which the driver is executing when it restores a floating-point state is different than the IRQL at which it was executing when it saved the floating-point state. Because the IRQL at which the driver runs determines how the floating-point state is saved, the driver must be executing at the same IRQL when it calls the functions to save and to restore the floating-point state.\n\n\n## Example\nExample of incorrect code. Floating point state was saved at APC_LEVEL but restored at PASSIVE_LEVEL\n\n```c\n \n\t\t_IRQL_requires_(PASSIVE_LEVEL) \n\t\tvoid driver_utility_bad(void)\n\t\t{\n\t\t\tKIRQL oldIRQL;\n\t\t\tKeRaiseIrql(APC_LEVEL, &oldIRQL);\n\t\t\t// running at APC level\n\t\t\tKFLOATING_SAVE FloatBuf;\n\t\t\tif (KeSaveFloatingPointState(&FloatBuf))\n\t\t\t{\n\t\t\t\tKeLowerIrql(oldIRQL); // lower back to PASSIVE_LEVEL\n\t\t\t\t// ...\n\t\t\t\tKeRestoreFloatingPointState(&FloatBuf);\n\t\t\t}\n\t\t}\n\t\t\n```\nCorrect example\n\n```c\n \n\t\t\t_IRQL_requires_(PASSIVE_LEVEL) \n\t\t\tvoid driver_utility_good(void)\n\t\t\t{\n\t\t\t\t// running at APC level\n\t\t\t\tKFLOATING_SAVE FloatBuf;\n\t\t\t\tKIRQL oldIRQL;\n\t\t\t\tKeRaiseIrql(APC_LEVEL, &oldIRQL);\n\n\t\t\t\tif (KeSaveFloatingPointState(&FloatBuf))\n\t\t\t\t{\n\t\t\t\t\tKeLowerIrql(oldIRQL);\n\t\t\t\t\t// ...\n\t\t\t\t\tKeRaiseIrql(APC_LEVEL, &oldIRQL);\n\t\t\t\t\tKeRestoreFloatingPointState(&FloatBuf);\n\t\t\t\t}\n\t\t\t}\n\t\t\n```\n\n## References\n* [ C28111 ](https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/28111-floating-point-irql-mismatch)\n\n## Semmle-specific notes\n**Wrapper / common-caller pattern.** The query reasons about IRQL-changing calls between save and restore not only when both calls share an enclosing function, but also when they sit inside one-level helper wrappers that are called from a common caller (for example, thin `save_fp_helper` / `restore_fp_helper` functions that simply forward to `KeSaveFloatingPointState` / `KeRestoreFloatingPointState`). In those cases the intermediate IRQL transition is searched in the common caller (or in either helper's enclosing function for the asymmetric case where one side is a helper and the other is direct).\n\n**Remaining limitations.** The position-based filter still does not detect:\n\n* **IRQL changes performed deep inside helper bodies.** If the helper function itself raises or lowers the IRQL after the save (or before the restore), the change is not visible from the common caller's source-position view, and no intermediate IRQL change is found. Annotating the helper with `_IRQL_raises_` or `_IRQL_saves_global_` makes its IRQL behavior visible without body inspection.\n* **Indirect calls.** IRQL changes performed by an indirect call (function pointer or dispatch-table call) between save and restore are not detected, because the predicate only inspects the static call target.\n* **Loops where the restore is textually before the save.** The filter compares source line numbers; in a loop body whose first statement is the restore and last statement is the save (with the IRQL change after the save), the line range becomes empty and no intermediate IRQL change is seen.\n* **Wrapper chains longer than one level.** Only one level of wrapping is currently modelled (the helper is called directly from the common caller). Multi-level wrappers require the same annotation hint described above, or a direct call site.\n",
+                "markdown": "# Irql Float State Mismatch\nThe IRQL where the floating-point state was saved does not match the current IRQL (for this restore operation).\n\n\n## Recommendation\nThe IRQL at which the driver is executing when it restores a floating-point state is different than the IRQL at which it was executing when it saved the floating-point state. Because the IRQL at which the driver runs determines how the floating-point state is saved, the driver must be executing at the same IRQL when it calls the functions to save and to restore the floating-point state.\n\n\n## Example\nExample of incorrect code. Floating point state was saved at APC_LEVEL but restored at PASSIVE_LEVEL\n\n```c\n \n\t\t_IRQL_requires_(PASSIVE_LEVEL) \n\t\tvoid driver_utility_bad(void)\n\t\t{\n\t\t\tKIRQL oldIRQL;\n\t\t\tKeRaiseIrql(APC_LEVEL, &oldIRQL);\n\t\t\t// running at APC level\n\t\t\tKFLOATING_SAVE FloatBuf;\n\t\t\tif (KeSaveFloatingPointState(&FloatBuf))\n\t\t\t{\n\t\t\t\tKeLowerIrql(oldIRQL); // lower back to PASSIVE_LEVEL\n\t\t\t\t// ...\n\t\t\t\tKeRestoreFloatingPointState(&FloatBuf);\n\t\t\t}\n\t\t}\n\t\t\n```\nCorrect example\n\n```c\n \n\t\t\t_IRQL_requires_(PASSIVE_LEVEL) \n\t\t\tvoid driver_utility_good(void)\n\t\t\t{\n\t\t\t\t// running at APC level\n\t\t\t\tKFLOATING_SAVE FloatBuf;\n\t\t\t\tKIRQL oldIRQL;\n\t\t\t\tKeRaiseIrql(APC_LEVEL, &oldIRQL);\n\n\t\t\t\tif (KeSaveFloatingPointState(&FloatBuf))\n\t\t\t\t{\n\t\t\t\t\tKeLowerIrql(oldIRQL);\n\t\t\t\t\t// ...\n\t\t\t\t\tKeRaiseIrql(APC_LEVEL, &oldIRQL);\n\t\t\t\t\tKeRestoreFloatingPointState(&FloatBuf);\n\t\t\t\t}\n\t\t\t}\n\t\t\n```\n\n## References\n* [ C28111 ](https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/28111-floating-point-irql-mismatch)\n\n## Semmle-specific notes\n**Wrapper / common-caller pattern.** The query reasons about IRQL-changing calls between save and restore not only when both calls share an enclosing function, but also when they sit inside one-level helper wrappers that are called from a common caller (for example, thin `save_fp_helper` / `restore_fp_helper` functions that simply forward to `KeSaveFloatingPointState` / `KeRestoreFloatingPointState`). In those cases the intermediate IRQL transition is searched in the common caller (or in either helper's enclosing function for the asymmetric case where one side is a helper and the other is direct).\n\n**Remaining limitations.** The position-based filter still does not detect:\n\n* **IRQL changes performed deep inside helper bodies.** If the helper function itself raises or lowers the IRQL after the save (or before the restore), the change is not visible from the common caller's source-position view, and no intermediate IRQL change is found. Annotating the helper with `_IRQL_raises_` or `_IRQL_saves_global_` makes its IRQL behavior visible without body inspection.\n* **Indirect calls.** IRQL changes performed by an indirect call (function pointer or dispatch-table call) between save and restore are not detected, because the predicate only inspects the static call target.\n* **Loops where the restore is textually before the save.** The filter compares source line numbers; in a loop body whose first statement is the restore and last statement is the save (with the IRQL change after the save), the line range becomes empty and no intermediate IRQL change is seen.\n* **Wrapper chains longer than one level.** Only one level of wrapping is currently modelled (the helper is called directly from the common caller). Multi-level wrappers require the same annotation hint described above, or a direct call site.\n"
               },
               "properties": {
                 "tags": [
@@ -112,7 +112,7 @@
         "extensions": [
           {
             "name": "microsoft/windows-drivers",
-            "semanticVersion": "1.9.0+2515238ad8912d03a18aab75fcacace2a4f4d307",
+            "semanticVersion": "1.9.0+a76f8551b47f01adada99ddc44a5ea4fa9839fca",
             "locations": [
               {
                 "uri": "file:///F:/source/repos/Windows-Driver-Developer-Supplemental-Tools/src/",
@@ -254,14 +254,14 @@
                 "text": ""
               },
               "level": "none",
-              "timeUtc": "2026-04-28T23:26:00.575823400Z",
+              "timeUtc": "2026-04-29T04:38:29.808991Z",
               "descriptor": {
                 "id": "cli/file-coverage-baseline",
                 "index": 1
               },
               "properties": {
                 "attributes": {
-                  "durationMilliseconds": 288
+                  "durationMilliseconds": 253
                 },
                 "visibility": {
                   "statusPage": false,
@@ -274,7 +274,7 @@
                 "text": ""
               },
               "level": "none",
-              "timeUtc": "2026-04-28T23:26:00.581682100Z",
+              "timeUtc": "2026-04-29T04:38:29.815492900Z",
               "descriptor": {
                 "id": "cli/platform",
                 "index": 2
@@ -297,7 +297,7 @@
                 "markdown": "Internal telemetry for the C++ extractor.\n\nNo action needed."
               },
               "level": "note",
-              "timeUtc": "2026-04-28T23:26:39.590845200Z",
+              "timeUtc": "2026-04-29T04:39:07.709847200Z",
               "descriptor": {
                 "id": "cpp/extractor/summary",
                 "index": 3
@@ -369,7 +369,7 @@
                   "index": 0
                 },
                 "region": {
-                  "startLine": 112,
+                  "startLine": 111,
                   "startColumn": 33,
                   "endColumn": 36
                 }

src/drivers/general/queries/IrqlFloatStateMismatch/driver_snippet.c

@@ -92,14 +92,13 @@ void driver_utility_nested_block_good(void)
 // =====================================================================
 // Adversarial: cross-function save / restore via thin wrappers.
 //
-// `irqlChangesBetween` requires `saveCall` and `restoreCall` to
-// share an enclosing function, so when the save and the restore
-// are routed through helper wrappers and the IRQL change happens
-// in the caller, the source-position filter never finds a `mid`
-// candidate.  No finding is produced even though the IRQL at the
-// save (PASSIVE_LEVEL) differs from the IRQL at the restore
-// (DISPATCH_LEVEL).  This is a known false negative of the
-// current intraprocedural filter.
+// `irqlChangesBetween` projects each call to an anchor line in either
+// the directly enclosing function or a one-level wrapper / common
+// caller, so when the save and the restore are routed through helper
+// wrappers and the IRQL change happens in the caller, the caller's
+// anchor lines bracket the `KeRaiseIrql` call and the mismatch is
+// flagged.  The IRQL at the save (PASSIVE_LEVEL) differs from the IRQL
+// at the restore (DISPATCH_LEVEL) for this case.
 // =====================================================================
 
 static void save_fp_helper(PKFLOATING_SAVE pfs)

src/drivers/general/queries/IrqlNotSaved/IrqlNotSaved.ql

@@ -83,10 +83,10 @@ module IrqlSaveParameterFlowConfigurationConfig implements DataFlow::ConfigSig {
   }
 
   predicate isSink(DataFlow::Node sink) {
-    // Only track flow to assignment targets or parameters — not every node
+    // Only track flow to assignment targets or parameters, not every node.
     exists(Variable v | v.getAnAssignedValue() = sink.asExpr())
     or
-    exists(sink.asParameter())
+    sink.asParameter() instanceof Parameter
   }
 }
 module IrqlSaveParameterFlowConfiguration = DataFlow::Global<IrqlSaveParameterFlowConfigurationConfig>;