netdev - Re: [PATCH] Fix routing tables with id

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

Message-ID: <48453C70.1040303@trash.net>
Date:	Tue, 03 Jun 2008 14:43:28 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Jarek Poplawski <jarkao2@...il.com>
CC:	Krzysztof Oledzki <olel@....pl>, netdev@...r.kernel.org
Subject: Re: [PATCH]  Fix routing tables with id > 255 for legacy software

Jarek Poplawski wrote:
> On Tue, Jun 03, 2008 at 12:37:35PM +0200, Krzysztof Oledzki wrote:
>>
> If such an old app uses rtm_table, this 253 table could be used for
> something and get additional entries after this patch. Another case
> would be when such an overflow on 0xff is "expected", then old tables
> would loose their entries. I hope I'm wrong with this, but it looks
> like admins can do strange things, and then this would be called a
> regression. So, I think this patch is right if we are sure there are
> no such cases...
> 
>>> BTW, I wonder, how these old appliction would treat RT_TABLE_UNSPEC  
>>> instead.
>> Such old appliction is for example zebra/quagga: it asks for all routes,  
>> does not know about RTA_TABLE so uses rtm_table and selects all entries  
>> with rtm_table == RT_TABLE_MAIN or zebrad.rtm_table_default which is  
>> unfortunately 0 by default. So no, RT_TABLE_UNSPEC (0) does not help, 
>> even makes everythink worse here.
> 
> I see: so we don't care for these RT_TABLE_COMPAT entries, let only
> they don't go to _MAIN or _UNSPEC!

Well, if people already use table 253, I guess they might care.
I'm not convinced this is any better than overflowing.

Quoting the changelog from the patch which introduces this:

     Introduce RTA_TABLE route attribute and FRA_TABLE routing rule 
attribute
     to hold 32 bit routing table IDs. Usespace compatibility is provided by
     continuing to accept and send the rtm_table field, but because of its
     limited size it can only carry the low 8 bits of the table ID. This
     implies that if larger IDs are used, _all_ userspace programs using 
them
     need to use RTA_TABLE.

And I still don't see any other way to handle this properly.
--
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