Change Details

RFC792 states the conditions for sending a redirect. ip_forward() still sepcifies and does proper checks for these (we do slightly more than suggested as makes sense). The implementation added in 8ad114c082a159c0dde95aa35d2e3e108aa30a75 to ip_tryforward() however is flawed and may send a "multi-hop" redirects (to a host not on the directly connected network) even with a "This host on this network" destination (which makes no sense at all). Do proper checks in ip_tryforward() to stop us from sending redirects in situations we may not. The spreading of logic between ip_tryforward() and ip_redir_alloc() is unfortunate but this is the least intrusive change to fix the bug for now. When rectifying this wwe should probably combine the multiple cases where we decide if to send a redirect into one function. While here enhance and fix comments as to which conditions are handled for sending redirects in various places. Reported by: pi (on net@ 2021-12-04) MFC after: 3 days

RFC792,1009,1122 state the original conditions for sending a redirect. RFC1812 further refine this. ip_forward() still sepcifies the checks originally implemented for these (we do slightly more/different than suggested as makes sense). The implementation added in 8ad114c082a159c0dde95aa35d2e3e108aa30a75 to ip_tryforward() however is flawed and may send a "multi-hop" redirects (to a host not on the directly connected network) even with a "This host on this network" destination (which makes no sense at all). Do proper checks in ip_tryforward() to stop us from sending redirects in situations we may not. Move almost all logic from ip_tryforward() into ip_redir_alloc() apart from the sysctl check to see if redirects are disabled. While here enhance and fix comments as to which conditions are handled for sending redirects in various places. Reported by: pi (on net@ 2021-12-04) MFC after: 3 days

RFC792,1009,1122 states the original conditions for sending a redirect. ip_forward() still sepcifies and does proper checks for these (we doRFC1812 further refine this. slightly more than suggested as makes sense).ip_forward() still sepcifies the checks originally implemented for these (we do slightly more/different than suggested as makes sense). The implementation added in 8ad114c082a159c0dde95aa35d2e3e108aa30a75 to ip_tryforward() however is flawed and may send a "multi-hop" redirects (to a host not on the directly connected network) even with a "This host on this network" destination (which makes no sense at all). Do proper checks in ip_tryforward() to stop us from sending redirects in situations we may not. The spreading ofMove almost all logic betweenfrom ip_tryforward() andinto ip_redir_alloc() is unfortunate but this is the least intrusive changeapart from the sysctl check to see if redirects to fix the bug for now. When rectifying this wwe should probably combine the multiple cases where we decide if to send a redirect into one functionare disabled. While here enhance and fix comments as to which conditions are handled for sending redirects in various places. Reported by: pi (on net@ 2021-12-04) MFC after: 3 days