netdev - Re: [LARTC] [BUG?] ip ru flush && RTNETLINK answers: Numerical result out of range

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 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]

Date:	Mon, 19 Mar 2007 06:54:15 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Luciano Ruete <luciano@...men.org.ar>
CC:	lartc@...lman.ds9a.nl, Linux Netdev List <netdev@...r.kernel.org>,
	Thomas Graf <tgraf@...g.ch>
Subject: Re: [LARTC] [BUG?] ip ru flush && RTNETLINK answers: Numerical result
 out of range

Luciano Ruete wrote:
> After an: 
> # ip ru flush
> I loose all my ip rules but the priority 0 one. 
> root@...asvati:~# ip ru
> 0:      from all lookup 255
> root@...asvati:~#  
> 
> Ok with that, but now i'm not able to insert any new rule.
> This leads to a total loose of conectivity.
> 
> root@...asvati:~# ip ru add from all table default
> RTNETLINK answers: Numerical result out of range
> root@...asvati:~# ip ru add from all lookup main
> RTNETLINK answers: Numerical result out of range
> 
> Even seting the priority value by hand, i got the same error:
> 
> root@...asvati:~# ip ru add from all lookup main priority 32766
> RTNETLINK answers: Numerical result out of range
> 
> To be able to send this e-mail without rebooting i had to insert my gw ip 
> routes in table 255.
> 
> Is this a bug in iproute?
> 
> Some adiotional data:
> ip utility, iproute2-ss060323
> Linux sarasvati 2.6.20-5-386 #2 Sat Jan 6 14:44:57 UTC 2007 i686 GNU/Linux

The problem seems to be the nla policy added in 2.6.19 or 2.6.20.
When specifying a prefix as "all", iproute adds a zero byte long
attribute (FRA_SRC in this case). The IPv4 fib_rules policy states
that it has to be exactly 4 bytes long, which makes validation fail.
This also affects IPv6 and DECnet.

I would argue that iproute is broken and shouldn't add a zero
byte long attribute, but we still need to make sure the kernel
accepts these attributes as valid.

Thomas, I can't see a clean way to fix this right now that
doesn't either bloat struct nla_policy or removes FRA_SRC/FRA_DST
from the policy, could you please look into this? Thanks.

-
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