Skip to content

gcs-sidecar/bridge: Do not enforce MaxMsgSize on incoming messages#2786

Open
micromaomao wants to merge 1 commit into
microsoft:mainfrom
micromaomao:wcow-gcs-msglen
Open

gcs-sidecar/bridge: Do not enforce MaxMsgSize on incoming messages#2786
micromaomao wants to merge 1 commit into
microsoft:mainfrom
micromaomao:wcow-gcs-msglen

Conversation

@micromaomao

Copy link
Copy Markdown
Member

This was discovered as causing the UVM to crash when we try to load a long fragment. Currently, the LCOW gcs does not enforce this limit, and so we never hit this in LCOW. I think it should be fine to also not enforce it for WCOW, since DoS attack from the host is outside the scope of the confidential threat model, and this avoid arbitrary length limits on policy and fragments.

This was discovered as causing the UVM to crash when we try to load a long
fragment.  Currently, the LCOW gcs does not enforce this limit, and so we never
hit this in LCOW.  I think it should be fine to also not enforce it for WCOW,
since DoS attack from the host is outside the scope of the confidential threat
model, and this avoid arbitrary length limits on policy and fragments.

Signed-off-by: Tingmao Wang <tingmaowang@microsoft.com>
@micromaomao micromaomao requested a review from a team as a code owner June 22, 2026 16:13
}

n := header.Size
if n < prot.HdrSize || n > prot.MaxMsgSize {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

inbox GCS transport has a buffer limit of 64kb, so maybe we can drop this check for messages handled strictly by gcs-sidecar (policy/fragments etc) and we can ensure the size on the rest of the messages?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants