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
| ||
|
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
Powered by blists - more mailing lists