@TimonPost reports encountering this consistently on WSL, and observed it at least once in our CI at https://github.com/quinn-rs/quinn/actions/runs/1630318713, manifesting as a cmsg_len of 20 rather than the expected 17. It was observed for the echo_dualstack and echo_v4 tests, but apparently not for echo_v6. Looking around the kernel source, I'm not sure how this is possible; the only origin seems to be https://elixir.bootlin.com/linux/latest/source/net/ipv4/ip_sockglue.c#L73, which has a very clearly hardcoded size of 1.
Our current behavior should be correct in release builds on little-endian systems, and harmlessly broken on big-endian systems. Still, I'd like to be able to account for why this is necessary, if nothing else so we can narrow down and perhaps someday remove the mitigation.
@TimonPost reports encountering this consistently on WSL, and observed it at least once in our CI at https://github.com/quinn-rs/quinn/actions/runs/1630318713, manifesting as a cmsg_len of 20 rather than the expected 17. It was observed for the echo_dualstack and echo_v4 tests, but apparently not for echo_v6. Looking around the kernel source, I'm not sure how this is possible; the only origin seems to be https://elixir.bootlin.com/linux/latest/source/net/ipv4/ip_sockglue.c#L73, which has a very clearly hardcoded size of 1.
Our current behavior should be correct in release builds on little-endian systems, and harmlessly broken on big-endian systems. Still, I'd like to be able to account for why this is necessary, if nothing else so we can narrow down and perhaps someday remove the mitigation.