netdev - Re: [PATCH] af_key: parse and send SADB_X_EXT_NAT_T

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: <49796139.3090605@iki.fi>
Date:	Fri, 23 Jan 2009 08:18:33 +0200
From:	Timo Teräs <timo.teras@....fi>
To:	David Miller <davem@...emloft.net>
CC:	herbert@...dor.apana.org.au, netdev@...r.kernel.org
Subject: Re: [PATCH] af_key: parse and send SADB_X_EXT_NAT_T_OA extension

David Miller wrote:
> From: Timo Teräs <timo.teras@....fi>
>> David Miller wrote:
>>> From: Timo Teräs <timo.teras@....fi>
>>>> Is there any particular reason why setting NAT-OA info should/
>>>> must be done using netlink? Or is this just a way to try to
>>>> put more pressure for the change to happen?
>>> Because it isn't deprecated if we keep adding features to it.
>> I would not consider this a new feature. It just makes pfkey
>> act consistently. If you don't want it supported, it'd make
>> more sense to not #define SADB_X_EXT_NAT_T_OA and drop all of
>> the verification code already present than to silently
>> ignore it. Make kernel return an error if some tried using it.
> 
> Fair enough, sounds like a reasonable argument.
> 
> Herbert what do you think?  The proposal is that we just reflect the
> value we get, rather than acting upon it.

Going back to the original patch. Knowing that it's bad idea to
use it for my other purposes, I have no strong feelings to push
for this.

Then again, since as discussed earlier, encap_oa is not used for
anything (and never will be). It's just stored and given back if
requested, so this patch adds nothing new; it just stores and
gives the attribute back if the SA is dumped.

Do note that currently pfkey_msg2xfrm_state() currently allocates
xfrm_encap_tmpl with kmalloc() and leaves encap_oa uninitialized,
thus all SAs with NAT-T created via pfkey currently show random
crap in encap_oa when dumped via "ip xfrm state".

Also the patch I sent first should memset() the encap_oa if
SADB_X_EXT_NAT_T_OA is not present.

If you still consider that the copying of that extension is
inappropriate then maybe memset():ing the encap_oa to zero
would be acceptable?

Cheers,
  Timo

--
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