From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131 Description of problem: Taroon-A4 kernel doesn't fill the following requirements for RFC2461. 8.1. Validation of Redirect Messages A host MUST silently discard any received Redirect message that does not satisfy all of the following validity checks: - The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address. Additional info: This patch from fujitsu. --- net/ipv6/ndisc.c.org 2003-06-18 03:34:00.000000000 +0900 +++ net/ipv6/ndisc.c 2003-06-30 15:51:32.000000000 +0900 @@ -1166,6 +1166,7 @@ struct in6_addr *dest; struct in6_addr *target; /* new first hop to destination */ struct neighbour *neigh; + struct rt6_info *rt6; int on_link = 0; struct ndisc_options ndopts; int optlen; @@ -1205,6 +1206,20 @@ return; } + rt6 = rt6_lookup(dest, NULL, skb->dev->ifindex, 1); + if (!rt6) { + if (net_ratelimit()) + printk(KERN_WARNING "ICMP redirect: " + "no route found for redirect dst\n"); + return; + } else if (ipv6_addr_cmp(&skb->nh.ipv6h->saddr, &rt6->rt6i_gateway) != 0) { + if (net_ratelimit()) + printk(KERN_WARNING "ICMP redirect: " + "not equal to gw-for-src (must be same)\n"); + dst_release(&rt6->u.dst); + return; + } + in6_dev = in6_dev_get(skb->dev); if (!in6_dev) return;
Fuchi, thank you for this ipv6 patch. Dave, could you please check that this patch looks ok ? Jens, could you please test this patch with your TAHI setup ?
I would much prefer that these patches go to the USAGI people and get discussed on the public lists than to rot here in our bugzilla entires. Once USAGI and the lists approve a patch, it goes into our tree automatically, so this is the best course of action for such things.
This patch is buggy, it leaks the 'rt6' on the non-error code path. Once this bug is fixed, please post the final version via the proper channels which is to linux-net.org and CC:'ing Yoshfuji Hideaki of USAGI project (yoshfuji) Thank you.
I'm closing this, the correct tests are made by net/ipv6/route.c:rt6_redirect() already. Whoever is creating these patches is not testing or verifying the things they are finding, they are looking at code and guessing how it works or what it does and making patches based upon those presumptions. I see this happen often when people get into an "RFC mania" mode about fixing bugs.
I think it is not appropriate to merge in a fix for something which is purely a standards compliance issue, so late in the RHEL3 release cycle. If a customer has a real problem they were hitting due to this bug, that would be a different issue. This bug is purely being reported because of a failure during the TAHI ipv6 compliance tests, and I do not consider that a strong enough basis for inclusion this late in the product life cycle. We really need to draw the line somewhere.
Closing as WONTFIX in light of last comment.