remote_port is another case of a BPF context field documented as a 32-bit value in network byte order for which the BPF context access converter generates a load of a zero-padded 16-bit integer in network byte order. First such case was dst_port in bpf_sock which got addressed in commit 4421a582718a ("bpf: Make dst_port field in struct bpf_sock 16-bit wide"). Loading 4-bytes from the remote_port offset and converting the value with bpf_ntohl() leads to surprising results, as the expected value is shifted by 16 bits. Reduce the confusion by splitting the field in two - a 16-bit field holding a big-endian integer, and a 16-bit zero-padding anonymous field that follows it.
Showing the changes to include/uapi (1 of 3 files). Show all
Unified · Split
| @@ -6453,7 +6453,8 @@ struct bpf_sk_lookup { · 6452 unmodified lines | ||
| 6453 | 6453 | __u32 protocol; /* IP protocol (IPPROTO_TCP, IPPROTO_UDP) */ |
| 6454 | 6454 | __u32 remote_ip4; /* Network byte order */ |
| 6455 | 6455 | __u32 remote_ip6[4]; /* Network byte order */ |
| 6456 | − __u32 remote_port; /* Network byte order */ | |
| 6456 | + __be16 remote_port; /* Network byte order */ | |
| 6457 | + __u16 :16; /* Zero padding */ | |
| 6457 | 6458 | __u32 local_ip4; /* Network byte order */ |
| 6458 | 6459 | __u32 local_ip6[4]; /* Network byte order */ |
| 6459 | 6460 | __u32 local_port; /* Host byte order */ |