Skip to content

Fix receive buffer overflow - #207

Merged
cboulay merged 4 commits into
masterfrom
fix/receive-buffer-overflow
Sep 28, 2026
Merged

cboulay merged 4 commits into
masterfrom
fix/receive-buffer-overflow

Conversation

@cshmookler

Copy link
Copy Markdown
Contributor

Add more padding to the receive buffer to prevent consumers of the receive buffer from reading past the end of the allocated space.

See comments in code and commits for details.

cbPKT_MAX_SIZE < sizeof(cbPKT_FS_BASIS), so it's possible for a cbPKT_FS_BASIS
packet near the end of the receive buffer to result in a read access violation
even with padding of sizeof(cbPKT_GENERIC) == cbPKT_MAX_SIZE.

The receive buffer must have padding equal to the largest packet on the wire,
but whichever packet is the largest changes between protocol versions and
cbPKT_MAX_SIZE cannot be the pad length because it is exceeded by
cbPKG_FS_BASIS.

This fix sets the pad length equal to the buffer length because all packets
in future protocol versions are guaranteed to fit within cbCER_UDP_SIZE_MAX.
@cshmookler cshmookler changed the title Fix: receive buffer overflow Fix receive buffer overflow Sep 21, 2026
@cshmookler
cshmookler marked this pull request as ready for review September 23, 2026 14:48
@cshmookler
cshmookler requested a review from cboulay September 23, 2026 14:48

@cboulay cboulay left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Thanks. The DeviceSessionWrapper half is the important fix here: that receive thread (used for 3.11/4.0/4.1 devices) had no padding at all and filled the whole buffer, so any full-struct copy from a packet near the end of a large datagram ran off the stack buffer.

Padding by a full datagram is fine with me. It covers readers and writers (e.g. in-place translation, or any code that writes a full struct at a packet offset), and it doesn't need revisiting each time cbproto adds a bigger packet type.

A few cleanups before merging:

  1. Trim the comment in startReceiveThread(). It currently reads like a design discussion ("The previous fix…", "A potential fix is…", the cbPKT_FS_BASIS / cbPKT_UNIT_SELECTION sizing). The code comment should say what the padding is for; the history and alternatives belong in the commit message, where you already have them. Suggested wording is inline.
  2. Typo ("the en") and a line with trailing whitespace, both inline.
  3. Stale comment in device_session_wrapper.h:127. The scratch buffer in receivePackets() is described as "mirroring the receive thread's own stack buffer of the same size", which is no longer true. Since the out-of-place translators (3.11, 4.0) read src through struct casts too, consider giving scratch the same cbCER_UDP_SIZE_MAX * 2 padding (still passing cbCER_UDP_SIZE_MAX as recv_cap); otherwise please at least update that comment.

Comment thread src/cbdev/src/device_session.cpp Outdated
Comment thread src/cbdev/src/device_session.cpp Outdated
Comment thread src/cbdev/src/device_session.cpp Outdated
…ession.cpp

Co-authored-by: Chadwick Boulay <chadwick.boulay@gmail.com>
@cshmookler
cshmookler force-pushed the fix/receive-buffer-overflow branch from fa3e36d to 8a664e6 Compare September 28, 2026 14:59
The out-of-place translators (3.11, 4.0) read source packets through
struct casts, so the scratch buffer in receivePackets() needs the same
full-datagram padding as the receive thread's buffer. It is still
filled only to cbCER_UDP_SIZE_MAX.
@cboulay
cboulay merged commit d37728b into master Sep 28, 2026
20 of 21 checks passed
@cboulay
cboulay deleted the fix/receive-buffer-overflow branch September 28, 2026 19:45
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