The commit f39925dbde7788cfb96419c0f092b086aa325c0f
(ipv4: Cache learned redirect information in inetpeer.)
removed some ICMP packet validations which are required by
RFC 1122, section 3.2.2.2:
...
A Redirect message SHOULD be silently discarded if the new
gateway address it specifies is not on the same connected
(sub-) net through which the Redirect arrived [INTRO:2,
Appendix A], or if the source of the Redirect is not the
current first-hop gateway for the specified destination (see
Section 3.3.1).
Signed-off-by: Flavio Leitner <redacted>
---
net/ipv4/route.c | 47 ++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 42 insertions(+), 5 deletions(-)
The commit f39925dbde7788cfb96419c0f092b086aa325c0f
(ipv4: Cache learned redirect information in inetpeer.)
removed some ICMP packet validations which are required by
RFC 1122, section 3.2.2.2:
...
A Redirect message SHOULD be silently discarded if the new
gateway address it specifies is not on the same connected
(sub-) net through which the Redirect arrived [INTRO:2,
Appendix A], or if the source of the Redirect is not the
current first-hop gateway for the specified destination (see
Section 3.3.1).
Signed-off-by: Flavio Leitner <redacted>
The reason for putting this into the inetpeer cache was so that we
didn't need to consult the routing cache at all. We're working to
remove it at some point, so every dependency matters.
Can you implement this such that only an inetpeer cache probe is
necessary?
Thanks.
The commit f39925dbde7788cfb96419c0f092b086aa325c0f
(ipv4: Cache learned redirect information in inetpeer.)
removed some ICMP packet validations which are required by
RFC 1122, section 3.2.2.2:
...
A Redirect message SHOULD be silently discarded if the new
gateway address it specifies is not on the same connected
(sub-) net through which the Redirect arrived [INTRO:2,
Appendix A], or if the source of the Redirect is not the
current first-hop gateway for the specified destination (see
Section 3.3.1).
Signed-off-by: Flavio Leitner <redacted>
The reason for putting this into the inetpeer cache was so that we
didn't need to consult the routing cache at all. We're working to
remove it at some point, so every dependency matters.
Can you implement this such that only an inetpeer cache probe is
necessary?
Sure, I have reviewed your patch series to remove the routing
cache and I believe this version works with and without it, though
I have tested only with current net-next code.
Thanks for your time reviewing, I appreciate it.
fbl
Signed-off-by: Flavio Leitner <redacted>
---
net/ipv4/route.c | 43 ++++++++++++++++++++++++++++++++++++++-----
1 files changed, 38 insertions(+), 5 deletions(-)
The commit f39925dbde7788cfb96419c0f092b086aa325c0f
(ipv4: Cache learned redirect information in inetpeer.)
removed some ICMP packet validations which are required by
RFC 1122, section 3.2.2.2:
The reason for putting this into the inetpeer cache was so that we
didn't need to consult the routing cache at all. We're working to
remove it at some point, so every dependency matters.
Can you implement this such that only an inetpeer cache probe is
necessary?
Sure, I have reviewed your patch series to remove the routing
cache and I believe this version works with and without it, though
I have tested only with current net-next code.
Thanks for your time reviewing, I appreciate it.
...
quoted hunk
@@ -1331,13 +1337,40 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 new_gw, goto reject_redirect; }- peer = inet_getpeer_v4(daddr, 1);- if (peer) {- peer->redirect_learned.a4 = new_gw;+ memset(&fl4, 0, sizeof(fl4));+ fl4.daddr = daddr;+ for (s = 0; s < 2; s++) {+ for (i = 0; i < 2; i++) {+ fl4.flowi4_oif = ikeys[i];+ fl4.saddr = skeys[s];+ rt = __ip_route_output_key(net, &fl4);+ if (IS_ERR(rt))+ continue;- inet_putpeer(peer);+ if (rt->dst.error || rt->dst.dev != dev ||+ rt->rt_gateway != old_gw) {+ ip_rt_put(rt);+ continue;+ }- atomic_inc(&__rt_peer_genid);+ peer = rt->peer;+ if (!peer) {+ peer = inet_getpeer_v4(daddr, 1);+ putpeer = true;+ }
I was reviewing this again and instead of doing the above, it would
be better to use rt_bind_peer() to update rt->peer as well.
if (!rt->peer)
rt_bind_peer(rt, rt->rt_dst, 1);
peer = rt->peer;
if (peer) {
peer->redirect_learned.a4 = new_gw;
atomic_inc(&__rt_peer_genid);
}
but I am not sure if I understood you completely when you say
to do such that only an inetpeer cache probe is necessary.
thanks again,
fbl
I was reviewing this again and instead of doing the above, it would
be better to use rt_bind_peer() to update rt->peer as well.
if (!rt->peer)
rt_bind_peer(rt, rt->rt_dst, 1);
peer = rt->peer;
if (peer) {
peer->redirect_learned.a4 = new_gw;
atomic_inc(&__rt_peer_genid);
}
but I am not sure if I understood you completely when you say
to do such that only an inetpeer cache probe is necessary.
If you have the route entry available already and you're doing the
inetpeer lookup anyways, you might as well use rt_bind_peer() since
all of the expensive work has to be done anyways.
So yes, using rt_bind_peer() would be the best thing to do here.
I was reviewing this again and instead of doing the above, it would
be better to use rt_bind_peer() to update rt->peer as well.
if (!rt->peer)
rt_bind_peer(rt, rt->rt_dst, 1);
peer = rt->peer;
if (peer) {
peer->redirect_learned.a4 = new_gw;
atomic_inc(&__rt_peer_genid);
}
but I am not sure if I understood you completely when you say
to do such that only an inetpeer cache probe is necessary.
If you have the route entry available already and you're doing the
inetpeer lookup anyways, you might as well use rt_bind_peer() since
all of the expensive work has to be done anyways.
So yes, using rt_bind_peer() would be the best thing to do here.
just posted patch v3. iirc, you prefer to receive patches as new
posts rather than replies to old threads.
"Subject: [PATCH net-next v3] route: fix ICMP redirect validation"
thanks again,
fbl