netdev - Re: commit : ppp: add rtnetlink device creation support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 8 Dec 2016 10:54:16 +0100
From:   Guillaume Nault <g.nault@...halink.fr>
To:     Brad Campbell <lists2009@...rfbargle.com>
Cc:     Thomas Haller <thaller@...hat.com>, Dan Williams <dcbw@...hat.com>,
        netdev <netdev@...r.kernel.org>, Thomas Graf <tgraf@...g.ch>,
        David Miller <davem@...emloft.net>
Subject: Re: commit : ppp: add rtnetlink device creation support - breaks
 netcf on my machine.

On Thu, Dec 08, 2016 at 10:29:44AM +0800, Brad Campbell wrote:
> On 08/12/16 01:43, Thomas Haller wrote:
> > On Tue, 2016-12-06 at 17:12 -0600, Dan Williams wrote:
> > > 
> > > > libnl1 rejects the IFLA_INFO_DATA attribute because it expects it
> > > > to
> > > > contain a sub-attribute. Since the payload size is zero it doesn't
> > > > match the policy and parsing fails.
> > > > 
> > > > There's no problem with libnl3 because its policy accepts empty
> > > > payloads for NLA_NESTED attributes (see libnl3 commit 4be02ace4826
> > 
> > Hi,
> > 
> > libnl1 is unmaintained these days. I don't think it makes sense to
> > backport that patch. The last upstream release was 3+ years ago, with
> > no upstream development since then.
> > 
> > IMHO netcf should drop libnl-1 support.
> > 
> 
> G'day Thomas,
> 
> I'm not sure anyone was suggesting fixing libnl1, it was more around a
> discussion with regard to a change in the kernel breaking old userspace and
> whether it needs to be fixed in the kernel.
> 
Yes, I could add a sub-attribute in IFLA_INFO_DATA (e.g. the PPP unit).
That'd be enough to make libnl1 happy. But that wouldn't make much
sense if not backported to stable kernel versions. Given that the
netlink message is already properly formatted and that the problem only
appears with an obsolete library, I'm not sure that's worth it.

Proper message parsing is a must, or we'd loose the extensibility
proprety of netlink (which was the fundamental reason for creating it
in the first place). So for now, I prefer to leave the code as is,
unless someone asks me otherwise.

> Personally, now I have a solution to *my* immediate problem (that being any
> kernel 4.7 or later prevented libvirtd starting on my servers because my
> netcf was compiled against libnl1) I can upgrade the relevant userspace
> components to work around the issue.
> 
> Also, now this issue is a number of months old and I appear to be the only
> person reporting it, maybe it's not worth tackling. I would absolutely say
> that netcf needs to drop libnl1 now though as it *is* broken on newer
> kernels under the right circumstances.
> 
> I appreciate the assistance in tracking it down anyway. Thanks guys.
> 
You're welcome. Thanks for your clear and detailed report.

Regards,

Guillaume