# GET_CAPABILITIES issue (from mjunior <mjunior@larc.usp.br>)

[jyao1]

From mjunior mjunior@larc.usp.br

Potential OpenSPDM code issues:

• The requester accepts the ErrorCode=ResponseNotReady message as a response for get_capabilities. In fact, one of the unit tests for get_capabilities requester considers this scenario, and the device wrongly answers with a respond_if_ready message. Although the behavior is undefined in the specification, I assumed that the correct message handling should return a device_error in this situation (more on this subject on code fixes).
• All messages exchanged by a device are recorded on the structure SpdmContext->Transcript. These saved messages are later used for other device operations, such as get_measurements. However, in the UnitTest code, multiple get_capabilities messages are sequentially sent and received and the device is never reset. Therefore, after some tests, the Transcript buffer is completely filled and a buffer overflow happens (more on this subject on code fixes)
• On successful get_capabilities message response, the device does not check flag consistency to assure that mutually inclusive or mutually exclusive flags are compatible (more on this subject on code fixes).

  Contribution to OpenSPDM:

• More tests were created on the UnitTest code, including tests for protocol V1.1c, message responses with incompatible sizes, and message responses with incompatible flags.
• SpdmRequesterLibHandleErrorResponse.c was edited (lines 133-138) to return a device error if an ErrorCode=ResponseNotReady is received and the requester message is either a get_version, get_capabilities or negotiate_algorithms.
• To fix the buffer overflow in SpdmContext.Transcript, some test cases in TestSpdmRequesterGetCapability.c have a ResetManagedBuffer(&SpdmContext->Transcript.MessageA); command before the SpdmGetCapabilities call.

[jyao1]

Fixed c730d8f1cd0a3c475392c57c1be858d0cbd0b2e5