The HTTP client is provided as an EFI driver by the UEFI. AFAICT the UEFI spec doesn't specifically say what the behavior should be if the content-length header doesn't match the response body length, so it might very well be possible that some implementations just make `connection:close` requests and don't check the content length.
The vulnerability was reported by MSRC and none of the text about the CVE mentions an actual exploit. It might be revealed later, or it might just be theoretical.
The HTTP spec does say though: in HTTP/1.1, the HTTP body length is the value of the content-length header. Anything else coming on the wire is part of the next HTTP request/response (which may of course be invalid). Reading everything from the stream until the connection is closed is HTTP/1.0 behavior.
Of course, if the UEFI HTTP client is not correctly implementing the spec, it's up to shim to defend itself, so I'm not saying this change is wrong or unnecessary.
The vulnerability was reported by MSRC and none of the text about the CVE mentions an actual exploit. It might be revealed later, or it might just be theoretical.