GHSA-gfw4-49f9-cp25

## Summary

KubeEdge CloudHub uses the viaduct packer to decode messages received from connected peers. The packer reads a 32-bit payload length from the message header and previously allocated a buffer of that size without enforcing an upper bound.

An authenticated peer that can establish a viaduct connection to CloudHub can send a crafted message header containing an excessively large payload length. This may cause CloudHub to allocate a large amount of memory and can result in memory exhaustion, process termination, or denial of service.

## Impact

A successfully authenticated malicious or compromised edge node may repeatedly send crafted viaduct message headers to increase CloudHub memory consumption.

Depending on available memory and deployment limits, exploitation may cause:

* Increased CloudHub memory usage * Out-of-memory termination * CloudHub restart loops * Temporary disruption of cloud-edge communication

Authentication to the viaduct endpoint is required. This issue does not provide unauthenticated access or direct code execution.

## Root cause

The viaduct packer trusted the payload length encoded in the message header and allocated the payload buffer before validating whether the declared length was within an acceptable range.

## Fix

The fix introduces a maximum viaduct payload size of 32 MiB.

The updated implementation:

* Rejects oversized payload lengths in the reader before memory allocation * Enforces the same maximum size in the writer * Adds regression tests covering oversized and valid payloads

Fixes have been prepared for the following patch releases:

* KubeEdge v1.23.1 * KubeEdge v1.22.2 * KubeEdge v1.21.2

These versions should not be listed as released until the coordinated release process is complete.

## Workarounds

Before patched versions are available, operators should:

* Restrict access to the CloudHub endpoint to trusted edge nodes and networks * Protect and rotate edge-node credentials * Revoke credentials belonging to decommissioned or potentially compromised nodes * Apply memory limits and restart policies to the CloudHub workload * Monitor CloudHub memory consumption and unexpected connection activity

## Affected component

* `pkg/viaduct/pkg/packer` * CloudHub viaduct message-processing path

## Credits

KubeEdge thanks Sang-Hoon Choi ([KoreaSecurity](https://github.com/KoreaSecurity), Sejong University) for responsibly reporting this issue and for coordinating with the KubeEdge maintainers through the security disclosure process.