[GH-ISSUE #4380] [Bug][TENT] C notification results are unterminated at their field limits #1100

New issue

Closed

opened 2026-10-29 21:22:53 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-29 21:22:53 +00:00

Owner

Originally created by @feichai0017 on GitHub (Sep 29, 2026).
Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/4380

Bug report

On current main (1ad008bc41c6de7c74e02fb1d48713309b880c0d), tent_recv_notifs() can return unterminated C strings when the notification name has at least 255 bytes or the message has at least 4095 bytes.

The result contains name[256] and msg[4096]. The implementation copies at most 255/4095 bytes using strncpy, but does not initialize the final byte. At the exact truncation limit, strncpy does not add a terminator. C callers using strlen, %s, or std::string(record.msg) can therefore read beyond the field (and beyond the allocation for the last message).

Source: C notification receive implementation at the tested commit.

Reproduction and expected behavior

CPU-only Linux x86_64, glibc, Clang 20, USE_TENT=ON, USE_CUDA=OFF. No RDMA NIC is needed: a self-targeted notification reaches the same C receive wrapper.

Create a TENT engine and send a notification to LOCAL_SEGMENT_ID, using std::string(255, 'n') and std::string(4095, 'm') for its name and message.
Receive using tent_recv_notifs().
Check records[0].name[255] and records[0].msg[4095].
Run with MALLOC_PERTURB_=165 so untouched heap bytes are nonzero.

Expected: both bytes are NUL. Actual: both are 0x5a. The same failure occurs for over-limit input lengths 256/4096; empty and shorter fields pass.

A regression added to local_notification_test fails on the unmodified production code and passes after explicitly terminating the two fields. The proposed fix preserves the existing struct layout and truncation limits.

#4253 addresses dangling/reused result ownership after tent_free_notifs, not string termination.
#4252 addresses named-notification segment-handle ownership.
#4061 / #4062 / #4068 address notification transport/lifecycle behavior.

I searched open and closed notification, C API, strncpy, and unterminated-string issues/PRs; I did not find a matching termination fix. A focused fix and regression test follow separately.

Prepared with Codex assistance; reproduction and the complete local notification test suite were executed.

Originally created by @feichai0017 on GitHub (Sep 29, 2026). Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/4380 ## Bug report On current `main` (`1ad008bc41c6de7c74e02fb1d48713309b880c0d`), `tent_recv_notifs()` can return unterminated C strings when the notification name has at least 255 bytes or the message has at least 4095 bytes. The result contains `name[256]` and `msg[4096]`. The implementation copies at most 255/4095 bytes using `strncpy`, but does not initialize the final byte. At the exact truncation limit, `strncpy` does not add a terminator. C callers using `strlen`, `%s`, or `std::string(record.msg)` can therefore read beyond the field (and beyond the allocation for the last message). Source: [C notification receive implementation at the tested commit](https://github.com/kvcache-ai/Mooncake/blob/1ad008bc41c6de7c74e02fb1d48713309b880c0d/mooncake-transfer-engine/tent/src/transfer_engine_c.cpp#L276-L305). ## Reproduction and expected behavior CPU-only Linux x86_64, glibc, Clang 20, `USE_TENT=ON`, `USE_CUDA=OFF`. No RDMA NIC is needed: a self-targeted notification reaches the same C receive wrapper. 1. Create a TENT engine and send a notification to `LOCAL_SEGMENT_ID`, using `std::string(255, 'n')` and `std::string(4095, 'm')` for its name and message. 2. Receive using `tent_recv_notifs()`. 3. Check `records[0].name[255]` and `records[0].msg[4095]`. 4. Run with `MALLOC_PERTURB_=165` so untouched heap bytes are nonzero. Expected: both bytes are `NUL`. Actual: both are `0x5a`. The same failure occurs for over-limit input lengths 256/4096; empty and shorter fields pass. A regression added to `local_notification_test` fails on the unmodified production code and passes after explicitly terminating the two fields. The proposed fix preserves the existing struct layout and truncation limits. ## Related work checked - #4253 addresses dangling/reused result ownership after `tent_free_notifs`, not string termination. - #4252 addresses named-notification segment-handle ownership. - #4061 / #4062 / #4068 address notification transport/lifecycle behavior. I searched open and closed notification, C API, `strncpy`, and unterminated-string issues/PRs; I did not find a matching termination fix. A focused fix and regression test follow separately. Prepared with Codex assistance; reproduction and the complete local notification test suite were executed.

bsakaguchi closed this issue

2026-10-29 21:22:53 +00:00

bsakaguchi commented

2026-10-29 21:22:54 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 29, 2026):

Thanks for opening this issue, @feichai0017!

Field	Value
Issue	#4380
GitHub user ID	`132118805`
Reporter	@feichai0017

A maintainer will triage this when possible. To help us respond faster, please include:

Mooncake version or commit SHA
Environment (OS, CUDA/driver, RDMA stack if relevant)
Steps to reproduce and expected vs. actual behavior

Useful links: Documentation · Contributing guide

This message was posted automatically by the issue bot.

@github-actions[bot] commented on GitHub (Sep 29, 2026): Thanks for opening this issue, @feichai0017! | Field | Value | |-------|-------| | **Issue** | #4380 | | **GitHub user ID** | `132118805` | | **Reporter** | @feichai0017 | A maintainer will triage this when possible. To help us respond faster, please include: - Mooncake version or commit SHA - Environment (OS, CUDA/driver, RDMA stack if relevant) - Steps to reproduce and expected vs. actual behavior Useful links: [Documentation](https://kvcache-ai.github.io/Mooncake/) · [Contributing guide](https://github.com/kvcache-ai/Mooncake/blob/main/CONTRIBUTING.md) > This message was posted automatically by the issue bot.