netdev - Re: [RFC V2 PATCH] rtnetlink: Fix problem with buffer allocation

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]

Date:	Tue, 14 Feb 2012 16:31:38 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	gregory.v.rose@...el.com
Cc:	bhutchings@...arflare.com, netdev@...r.kernel.org
Subject: Re: [RFC V2 PATCH] rtnetlink: Fix problem with buffer allocation

From: "Rose, Gregory V" <gregory.v.rose@...el.com>
Date: Tue, 14 Feb 2012 21:27:59 +0000

> That's a real sticky problem.  When the dump request comes in we
> don't know how big the required buffer might actually get.  That's
> why we used to have the min_ifinfo_dump_size.  However there were
> problems with that also so Dave asked me to get rid of it.  The only
> thing I could come up with just allocating a really big buffer.  If
> someone could point out to me how to get a maximum ifinfo dump size
> before rtnl_dump_ifinfo starts filtering through the matching
> interfaces then that would really help.  But at the point the dump
> request comes in we don't know beforehand how to calculate the info
> dump size because if_nlmsg_size() requires a pointer to a netdevice.

Two quick ideas:

1) Have a first pass which iterates over the devices and calculates
   the maximum of all if_nlmsg_size() calculations over those devices
   then uses that for the dump buffer allocation size.

2) Replace min_ifinfo_dump_size() with an array of sizes, one for
   each combination of extended features.  The only concern with this
   one is that whilst it's practical to do this now with only 1 or
   a few feature bits, in the future it may be a lot less practical.
--
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