Bug #14210
closed
reflecting ICMP of IP-in-IP needs to be more robust
100%
Description
Some ASSERTs in DEBUG kernels trigger when well-crafted IP-in-IPv4 (outer-IPv6 doesn't manifest this problem at all) hit the host.
Related issues
Updated by Dan McDonald 7 months ago
A community member reported this because of misbehaving network equipment. A proper test should involve:
- Sending a packet [IPv4 + IPv6(bad-IP-version) + ULP + data] to a target machines (one DEBUG and one non-DEBUG) that have no IPv6-in-IPv4 tunnels configured, which should cause ICMP_PROTOCOL_UNREACHABLE messages to get sent.
- Seeing that the ICMP handling triggers an ASSERT failure pre-this-fix on DEBUG, and something undetermined non-DEBUG.
- Seeing that an ICMP_PROTOCOL_UNREACHABLE post-this-fix gets sent from both non-DEBUG and DEBUG.
Updated by Dan McDonald 7 months ago
I can reproduce a problem packet now easily using a small scapy script, and have demonstrated that:
1.) DEBUG kernels will fail an ASSERT and panic.
2.) non-DEBUG kernels will proceed normally and return a appropriate ICMP error.
Updated by Dan McDonald 7 months ago
- Related to Feature #14211: Re-examine ip_hdr_length_v6 added
Updated by Electric Monk 7 months ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit 9495f63eafceb1605bec42e743f2976df42d683a
commit 9495f63eafceb1605bec42e743f2976df42d683a
Author: Dan McDonald <danmcd@joyent.com>
Date: 2021-11-09T17:42:25.000Z
14210 reflecting ICMP of IP-in-IP needs to be more robust
Reviewed by: Toomas Soome <tsoome@me.com>
Reviewed by: Robert Mustacchi <rm@fingolfin.org>
Approved by: Richard Lowe <richlowe@richlowe.net>