Guard stackwalking in IXClrDataStackWalk codepaths to account for underlying max size of context

[hoyosjs]

IXClrDataStackWalk methods don't take into account that the Windows context size is the one of the Windows SDK CONTEXT on AMD64. It does not include inline XSTATE. If some customer passes in XSTATE, ContextSizeForFlags always returns 0x4D0 regardless of context flag. So CheckContextSizeForBuffer always returns true. Then CopyMemory(&m_context, context, ...) will overrun for any XSTATE input and overwrite other fields.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes a memory-safety issue in CoreCLR DAC stackwalking (IXCLRDataStackWalk / IXCLRDataFrame) when callers provide a CONTEXT buffer larger than the underlying T_CONTEXT (e.g., AMD64 CONTEXT + appended XSTATE), which could previously cause out-of-bounds reads/writes during CopyMemory.

Changes:

• Cap GetContext copies to sizeof(T_CONTEXT) to avoid reading past the local context struct when callers supply oversized output buffers.
• Cap SetContext2 copies to sizeof(m_context) to avoid overwriting adjacent fields when callers supply oversized input buffers (e.g., with XSTATE).

[max-charlamb]

change looks good