netdev - Re: [PATCH net-next v2 06/10] tools/net/ynl: Add support for netlink-raw families

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

Date: Mon, 21 Aug 2023 15:00:14 +0100
From: Donald Hunter <donald.hunter@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org,  "David S. Miller" <davem@...emloft.net>,  Eric
 Dumazet <edumazet@...gle.com>,  Paolo Abeni <pabeni@...hat.com>,  Jonathan
 Corbet <corbet@....net>,  linux-doc@...r.kernel.org,  Stanislav Fomichev
 <sdf@...gle.com>,  Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>,
  donald.hunter@...hat.com
Subject: Re: [PATCH net-next v2 06/10] tools/net/ynl: Add support for
 netlink-raw families

Jakub Kicinski <kuba@...nel.org> writes:

> On Thu, 17 Aug 2023 10:10:35 +0100 Donald Hunter wrote:
>> > Looks good, but do we also need some extra plumbing to decode extack
>> > for classic netlink correctly?  Basically shouldn't _decode_extack()
>> > also move to proto? Or we can parameterize it? All we really need there
>> > is to teach it how much of fixed headers parser needs to skip to get to
>> > attributes, really (which, BTW is already kinda buggy for genl families
>> > with fixed headers).  
>> 
>> I have been working on the assumption that extack responses don't
>> include any fixed headers. I have seen extack messages decoded correctly
>> for classic netlink, here with RTM_NEWROUTE:
>> 
>> lib.ynl.NlError: Netlink error: Invalid argument
>> nl_len = 80 (64) nl_flags = 0x300 nl_type = 2
>>   error: -22  extack: {'msg': 'Invalid prefix for given prefix length'}
>> 
>> Is there something I am missing?
>
> I'm thinking of extack messages carrying offsets in addition to the 
> textual error message. NLMSGERR_ATTR_OFFS or NLMSGERR_ATTR_MISS_NEST.
>
> In that case ynl will try to re-parse its own message via
> _decode_extack_path() to resolve from the offset to what attribute
> was there. See the commit message on a552bfa16:
>
>     lib.ynl.NlError: Netlink error: Numerical result out of range
>     nl_len = 108 (92) nl_flags = 0x300 nl_type = 2
>             error: -34      extack: {'msg': 'integer out of range',...
>                                      'bad-attr': '.ifindex'}
>
> I mean the "bad-attr" thing.
>
> I think it works out of sheer luck here, we happen to skip over 
> the fixed header because it looks like a 0-length attribute?

You're right, sheer luck, and maybe only for some values of dp-ifindex.
When I tried to reproduce your test in commit a552bfa16, with a value of
dp-ifindex = 5, then ynl goes into an infinite loop trying to read a
zero length nlattr.

As you say, I'll need to rework the extack handling to account for fixed
headers. At a minimum _decode_extack will need to use nlproto.decode()
and needs to learn to skip the fixed header.

Apologies for being slow to catch up with you on this. Failing to grok
that _decode_extack is decoding the request, not the response.