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.