lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240912141440.314005-1-guyavrah1986@gmail.com>
Date: Thu, 12 Sep 2024 17:14:40 +0300
From: Guy Avraham <guyavrah1986@...il.com>
To: guyavrah1986@...il.com,
	davem@...emloft.net,
	dsahern@...nel.org,
	edumazet@...gle.com,
	kuba@...nel.org,
	pabeni@...hat.com,
	netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH net] net:ipv4:ip_route_input_slow: Change behaviour of routing decision when IP router alert option is present

When an IP packet with the IP router alert (RFC 2113) field arrives
to some host who is not the destination of that packet (i.e - non of
its interfaces is the address in the destination IP address field of that
packet) and, for whatever reason, it does not have a route to this
destination address, it drops this packet during the "routing decision"
flow even though it should potentially pass it to the relevant
application(s) that are interested in this packet's content - which happens
in the "forwarding decision" flow. The suggested fix changes this behaviour
by setting the ip_forward as the next "step" in the flow of the packet,
just before it (previously was) is dropped, so that later the ip_forward,
as usual, will pass it on to its relevant recipient (socket), by
invoking the ip_call_ra_chain.

Signed-off-by: Guy Avraham <guyavrah1986@...il.com>
---
The fix was tested and verified on Linux hosts that act as routers in which
there are kerenls 3.10 and 5.2. The verification was done by simulating
a scenario in which an RSVP (RFC 2205) Path message (that has the IP
router alert option set) arrives to a transit RSVP node, and this host
passes on the RSVP Path message to the relevant socket (of the RSVP
deamon) even though upon arrival of this packet it does NOT have route
to the destination IP address of the IP packet (that encapsulates the
RSVP Path message).

 net/ipv4/route.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 13c0f1d455f3..7c416eca84f8 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2360,8 +2360,12 @@ out:	return err;
 
 	RT_CACHE_STAT_INC(in_slow_tot);
 	if (res->type == RTN_UNREACHABLE) {
-		rth->dst.input= ip_error;
-		rth->dst.error= -err;
+		if (IPCB(skb)->opt.router_alert)
+			rth->dst.input = ip_forward;
+		else
+			rth->dst.input = ip_error;
+
+		rth->dst.error = -err;
 		rth->rt_flags	&= ~RTCF_LOCAL;
 	}
 
-- 
2.25.1


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ