netdev - Re: [PATCH] [IPv4] Reply net unreachable ICMP message

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-prev] [day] [month] [year] [list]

Date:	Fri, 7 Dec 2007 13:23:36 +0900
From:	Mitsuru Chinen <mitch@...ux.vnet.ibm.com>
To:	Jarek Poplawski <jarkao2@...il.com>
Cc:	Jarek Poplawski <jarkao2@...pl>, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>,
	Rami Rosen <roszenrami@...il.com>
Subject: Re: [PATCH] [IPv4] Reply net unreachable ICMP message

On Thu, 6 Dec 2007 09:47:33 +0100
Jarek Poplawski <jarkao2@...pl> wrote:

> On 06-12-2007 09:14, Mitsuru Chinen wrote:
> > On Thu, 6 Dec 2007 08:49:47 +0100
> > Jarek Poplawski <jarkao2@...pl> wrote:
> > 
> >> On 06-12-2007 07:31, Mitsuru Chinen wrote:
> >>> IPv4 stack doesn't reply any ICMP destination unreachable message
> >>> with net unreachable code when IP detagrams are being discarded
> >>> because of no route could be found in the forwarding path.
> >>> Incidentally, IPv6 stack replies such ICMPv6 message in the similar
> >>> situation.
> ...
> >> This patch seems to be wrong. It overrides err codes from
> >> fib_lookup, where such decisions should be made.
> > 
> > fib_lookup() replies -ESRCH in this situation.
> > It is necessary to override the variable by the suitable error
> > number like the code under e_hostunreach label.
> 
> Probably I miss something, but I can't see how can you be sure it's
> only -ESRCH possible here? Isn't opt->action() in fib_rules_lookup()
> supposed to return this -ENETUNREACH when needed?

Oh, excuse me. I did mistake.
fib_rules_lookup() replies -ESRCH when no route is found. The case
it replies -ENETUNREACH is that user adds unreachable route.
However, if the err value is override with no check, a blackhole
or prohibit route is treated as a unreachable route.

As the patch is already applied, I will send another patch to add
a check for it.
Thank you very much for pointing out the issue!

Best Regards,
----
Mitsuru Chinen <mitch@...ux.vnet.ibm.com>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html