Skip to content

Epoll: Use correct value to initialize mmsghdr.msg_namelen#16460

Merged
normanmaurer merged 1 commit into
4.2from
recvmmsg_msg_namelen
Mar 14, 2026
Merged

Epoll: Use correct value to initialize mmsghdr.msg_namelen#16460
normanmaurer merged 1 commit into
4.2from
recvmmsg_msg_namelen

Conversation

@normanmaurer
Copy link
Copy Markdown
Member

Motivation:

We did use the incorrect value for the msg_namelen and so could in theory result in an overflow if the kernel really use this value for the last element.

Modifications:

Use correct value

Result:

No risk of overflow during recvmmsg

Motivation:

We did use the incorrect value for the msg_namelen and so could in theory result in an overflow if the kernel really use this value for the last element.

Modifications:

Use correct value

Result:

No risk of overflow during recvmmsg
@normanmaurer normanmaurer added this to the 4.2.11.Final milestone Mar 13, 2026
@normanmaurer normanmaurer added needs-cherry-pick-4.1 This PR should be cherry-picked to 4.1 once merged. needs-cherry-pick-5.0 This PR should be cherry-picked to 5.0 once merged. labels Mar 13, 2026
@@ -628,7 +628,7 @@ static jint netty_epoll_native_recvmmsg0(JNIEnv* env, jclass clazz, jint fd, jbo
msg[i].msg_hdr.msg_iovlen = (*env)->GetIntField(env, packet, packetCountFieldId);

msg[i].msg_hdr.msg_name = addr + i;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
msg[i].msg_hdr.msg_name = addr + i;
msg[i].msg_hdr.msg_name = &addr[i];

Spotted this, where it looks like we're trying to get the pointer to each addr element, but do so incorrectly and instead get a byte-offset from the addr VLA.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Apparently in C, addition is type-specific so add + i will indeed reference the ith element, but I still think we should change it because it's kind of a wild concept and looks weird.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

yeah this just works as expected ... welcome to C :D We can do this as a follow as its not related to this PR.

msg[i].msg_hdr.msg_namelen = (socklen_t) storageSize;

if (cntrlbuf != NULL) {
msg[i].msg_hdr.msg_control = cntrlbuf + i * storageSize;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Could use the more idiomatic pattern here as well, but I think this code is otherwise correct as is.

@normanmaurer normanmaurer merged commit 29a5efc into 4.2 Mar 14, 2026
24 checks passed
@normanmaurer normanmaurer deleted the recvmmsg_msg_namelen branch March 14, 2026 14:10
netty-project-bot pushed a commit that referenced this pull request Mar 14, 2026
Motivation:

We did use the incorrect value for the msg_namelen and so could in
theory result in an overflow if the kernel really use this value for the
last element.

Modifications:

Use correct value

Result:

No risk of overflow during recvmmsg

(cherry picked from commit 29a5efc)
@netty-project-bot
Copy link
Copy Markdown
Contributor

Auto-port PR for 5.0: #16466

@github-actions github-actions Bot removed the needs-cherry-pick-5.0 This PR should be cherry-picked to 5.0 once merged. label Mar 14, 2026
netty-project-bot pushed a commit that referenced this pull request Mar 14, 2026
Motivation:

We did use the incorrect value for the msg_namelen and so could in
theory result in an overflow if the kernel really use this value for the
last element.

Modifications:

Use correct value

Result:

No risk of overflow during recvmmsg

(cherry picked from commit 29a5efc)
@netty-project-bot
Copy link
Copy Markdown
Contributor

Auto-port PR for 4.1: #16467

@github-actions github-actions Bot removed the needs-cherry-pick-4.1 This PR should be cherry-picked to 4.1 once merged. label Mar 14, 2026
normanmaurer added a commit that referenced this pull request Mar 16, 2026
…elen (#16467)

Auto-port of #16460 to 4.1
Cherry-picked commit: 29a5efc

---
Motivation:

We did use the incorrect value for the msg_namelen and so could in
theory result in an overflow if the kernel really use this value for the
last element.

Modifications:

Use correct value

Result:

No risk of overflow during recvmmsg

Co-authored-by: Norman Maurer <[email protected]>
normanmaurer added a commit that referenced this pull request Mar 16, 2026
…elen (#16466)

Auto-port of #16460 to 5.0
Cherry-picked commit: 29a5efc

---
Motivation:

We did use the incorrect value for the msg_namelen and so could in
theory result in an overflow if the kernel really use this value for the
last element.

Modifications:

Use correct value

Result:

No risk of overflow during recvmmsg

Co-authored-by: Norman Maurer <[email protected]>
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.

3 participants