diff options
author | Sabrina Dubroca <sd@queasysnail.net> | 2020-07-03 17:00:32 +0200 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2020-07-07 15:26:37 -0700 |
commit | 5eff06902394425c722f0a44d9545909a8800f79 (patch) | |
tree | 33395537f8f5fc142824b84893a205bfd378eb0f /net/mptcp | |
parent | 7cdaa4cc4bdfa252d515b307863f5a1972246dd6 (diff) | |
download | linux-5eff06902394425c722f0a44d9545909a8800f79.tar.gz linux-5eff06902394425c722f0a44d9545909a8800f79.tar.bz2 linux-5eff06902394425c722f0a44d9545909a8800f79.zip |
ipv4: fill fl4_icmp_{type,code} in ping_v4_sendmsg
IPv4 ping sockets don't set fl4.fl4_icmp_{type,code}, which leads to
incomplete IPsec ACQUIRE messages being sent to userspace. Currently,
both raw sockets and IPv6 ping sockets set those fields.
Expected output of "ip xfrm monitor":
acquire proto esp
sel src 10.0.2.15/32 dst 8.8.8.8/32 proto icmp type 8 code 0 dev ens4
policy src 10.0.2.15/32 dst 8.8.8.8/32
<snip>
Currently with ping sockets:
acquire proto esp
sel src 10.0.2.15/32 dst 8.8.8.8/32 proto icmp type 0 code 0 dev ens4
policy src 10.0.2.15/32 dst 8.8.8.8/32
<snip>
The Libreswan test suite found this problem after Fedora changed the
value for the sysctl net.ipv4.ping_group_range.
Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
Reported-by: Paul Wouters <pwouters@redhat.com>
Tested-by: Paul Wouters <pwouters@redhat.com>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/mptcp')
0 files changed, 0 insertions, 0 deletions