Epoll: Use correct value to initialize mmsghdr.msg_namelen#16460
Conversation
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
| @@ -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; | |||
There was a problem hiding this comment.
| 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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
Could use the more idiomatic pattern here as well, but I think this code is otherwise correct as is.
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)
|
Auto-port PR for 5.0: #16466 |
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)
|
Auto-port PR for 4.1: #16467 |
…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]>
…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]>
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