netdev - Re: 2.6.25-rc8 regression with openswan

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: <47F4EB73.1040705@trash.net>
Date:	Thu, 03 Apr 2008 16:36:35 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Marco Berizzi <pupilla@...mail.com>
CC:	netdev@...r.kernel.org, Kazunori MIYAZAWA <kazunori@...azawa.org>
Subject: Re: 2.6.25-rc8 regression with openswan

Marco Berizzi wrote:
> Patrick McHardy wrote:
> 
>> Manually adding SAs works fine for me, can you figure out what
>> kind of SA openswan was trying to add?
> 
> I have sent you the output of ip -s x s
> and ip -s x p when openswan is working with
> 2.6.25-rc8 with the commit df9dcb458 reverted.
> Let me know you need ssh access to my 2.6.25
> box.

The problem appears to be that openswan doesn't initialize the
selectors family when adding new SAs. xfrm_init_state() uses
the family to decide whether to set up inter family SAs or
regular SAs. We used to fix up the family in xfrm_user, but
this is now only done for transport mode SAs.

-       /*
-        * Set inner address family if the KM left it as zero.
-        * See comment in validate_tmpl.
-        */
-       if (!x->sel.family)
+       if (x->props.mode == XFRM_MODE_TRANSPORT)
                 x->sel.family = p->family;
+

Reverting this part should fix it, but would break inter family
tunnels again. It seems we need a different indication for
xfrm_init_state() for inter family SAs.

Kazunori, any ideas?

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