Updates to default verdict for MSAF and LMII

The product shall appropriately mitigate risks due to memory safety errors.

**

#### 5.2.6.2 Default Preparation, Verdict, and Evidence

Most memory safety mitigations have the same Verdict and Evidence:

* Preparation: None

* Verdict: each involved thread fails to read or write the target data and takes a segmentation fault, has error handling code executed, or is terminated in all tests => PASS, otherwise FAIL

* Evidence: error messages, log message, or the product reboots or halts

#### 5.2.5.2 MI-MSAF-1: Stack exhaustion detection

For each mitigation grouped under requirement TR-MSAF, for each field Preparation, Verdict, or Evidence, if it is not specified for that test, then the above Preparation, Verdict, or Evidence field shall apply.

#### 5.2.5.3 MI-MSAF-1: Stack exhaustion detection

Both kernel and userspace threads shall reject writes beyond the end of the stack.

Guidance: Two methods of exhausting stack memory include allocating a very large object on the stack, and performing an unbounded recursive function call.

#### 5.2.5.3 MI-MSAF-2: Stack linear buffer overflow detection

#### 5.2.5.4 MI-MSAF-2: Stack linear buffer overflow detection

Both kernel and userspace threads shall reject stack buffer writes that go beyond the end of the stack frame.

* Objective: Prevent thread from writing beyond end of stack

* Activities: For each of kernel and userspace, write beyond the end of the stack frame

#### 5.2.5.4 MI-MSAF-3: Array bounds checking

#### 5.2.5.5 MI-MSAF-3: Array bounds checking

Both kernel and userspace threads shall reject writes to fixed-size arrays that are beyond the end of the array.

* Objective: Prevent thread from writing beyond the end of a fixed-size array

* Activities: For each of kernel and userspace, write beyond the end of a fixed-size array

#### 5.2.5.5 MI-MSAF-4: Heap linear buffer overflow detection

#### 5.2.5.6 MI-MSAF-4: Heap linear buffer overflow detection

Both kernel and userspace threads shall reject writes beyond the bounds of allocated heap memory.

* Objective: Prevent thread from writing beyond the end of heap memory

* Activities: For each of kernel and userspace, for each type of heap memory, allocate a fixed size from each class of heap memory, write beyond it

#### 5.2.5.6 MI-MSAF-5: Heap use-after-free access prevention

#### 5.2.5.7 MI-MSAF-5: Heap use-after-free access prevention

Both kernel and userspace threads shall reject use of allocated memory that has been freed.

* Objective: Prevent thread from using memory that was allocated then freed

* Activities: For each of kernel and userspace, allocate from heap memory, free it, then try to read it, repeat but with a write

#### 5.2.5.7 MI-MSAF-6: Heap free checking

#### 5.2.5.8 MI-MSAF-6: Heap free checking

Both kernel and userspace threads shall reject freeing of memory that was allocated and previously freed.

* Verdict: each involved thread fails to read or write the target data and takes a segmentation fault, has error handling code executed, or is terminated in all tests => PASS, otherwise FAIL

* Evidence: error messages, log message, or the product reboots or halts

For each mitigation grouped under requirement TR-MSAF, for each field Preparation, Verdict, or Evidence, if it is not specified for that test, then the above Preparation, Verdict, or Evidence field shall apply.

For each mitigation grouped under requirement TR-LMII, for each field Preparation, Verdict, or Evidence, if it is not specified for that test, then the above Preparation, Verdict, or Evidence field shall apply.

#### 5.2.6.3 MI-MZRO-1: Stack memory zeroing