Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

src/privsep-root.c (1)

129-138:Critical: Fix MSG_WAITALL hang by using incoming message size.

Lines 134 and 137 setiov_len from the context buffer sizes (psr_ctx->psr_mdatalen,psr_ctx->psr_datalen), which can be larger than the actual incoming message sizepsr_error->psr_datalen. WhenMSG_WAITALL is used with aniov_len larger than available data,recvmsg blocks indefinitely waiting for bytes that will never arrive, wedging the privileged proxy and causing cascading failures like "No buffer space available."

This is the same critical issue identified in the past review and must be fixed.

Apply this diff to clampiov_len to the actual incoming message size:

 if (psr_error->psr_datalen != 0) { if (psr_ctx->psr_usemdata) { iov[1].iov_base = psr_ctx->psr_mdata;-/* psr_mdatalen could be smaller then psr_datalen- * if the above malloc failed. */-iov[1].iov_len =-    MIN(psr_ctx->psr_mdatalen, psr_ctx->psr_datalen);+/* Clamp to actual incoming size to avoid MSG_WAITALL hang.+ * If buffer is too small, MSG_TRUNC will catch it. */+iov[1].iov_len = psr_error->psr_datalen;+if (iov[1].iov_len > psr_ctx->psr_mdatalen)+iov[1].iov_len = psr_ctx->psr_mdatalen; } else { iov[1].iov_base = psr_ctx->psr_data;-iov[1].iov_len = psr_ctx->psr_datalen;+iov[1].iov_len = psr_error->psr_datalen;+if (iov[1].iov_len > psr_ctx->psr_datalen)+iov[1].iov_len = psr_ctx->psr_datalen; } }

src/privsep-root.c (1)

102-111:Consider removing MSG_WAITALL from the MSG_PEEK operation.

UsingMSG_WAITALL withMSG_PEEK may cause unnecessary blocking when the message header hasn't fully arrived yet. Since this is just a peek operation to determine buffer size, and you're checking for short reads immediately after (line 110),MSG_PEEK alone should suffice.

Apply this diff:

-len = recvmsg(fd, &msg, MSG_PEEK | MSG_WAITALL);+len = recvmsg(fd, &msg, MSG_PEEK);

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

src/privsep-root.c (2)

118-140:Dynamic buffer growth andiov_len capping avoid hangs and handle ENOBUFS cleanly

Therealloc ofpsr_ctx->psr_mdata and the subsequent setup:

• Preserve the old buffer ifrealloc fails, so the pointer and size remain valid.
• Useiov[1].iov_base from eitherpsr_mdata or the caller’s buffer as before.
• Critically, capiov[1].iov_len topsr_error->psr_datalen, so the total requested length is never larger than the actual message size, eliminating the previous MSG_WAITALL hang scenario when the context buffer was larger than the incoming payload.
• In the “realloc failed” case,psr_mdatalen < psr_error->psr_datalen, which will force a truncated read in the finalrecvmsg, correctly surfacing ENOBUFS while draining the queue.

Only tiny nit: the new comment still says “failed to malloc” even thoughrealloc is used here.

-       /* If we failed to malloc then psr_mdatalen will be smaller+       /* If we failed to realloc then psr_mdatalen will be smaller

---

142-157:Finalrecvmsg validation is robust; comment could be tightened to match new invariants

The finalrecvmsg(fd, &msg, MSG_WAITALL) plus:

• Short‑header check (len < sizeof(*psr_error)),
• Explicit MSG_TRUNC → ENOBUFS mapping,
• Exact size check againstsizeof(*psr_error) + psr_error->psr_datalen with EBADMSG and logging,

gives a solid guard against partial or malformed records and guarantees the caller sees consistent errors while the message is fully consumed from the queue. With the newiov_len capping above, the “receive buffers are bigger than the actual message” case cannot actually occur anymore, so the comment at Line 143 is now slightly misleading; consider updating it to say explicitly that the total requested length is bounded by the announcedpsr_datalen, which is what prevents stalling with MSG_WAITALL.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro