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  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:	Thu, 02 Aug 2007 15:01:14 -0700 (PDT)
From:	David Miller <>
Subject: Re: ipsec not working in 2.6.23-rc1-git10 when using pfkey

From: Joy Latten <>
Date: Thu, 2 Aug 2007 13:58:38 -0500

> Although an ipsec SA was established, kernel couldn't seem to find it.
> I think since we are now using "x->" instead of "family" 
> in the  xfrm_selector_match() called in xfrm_state_find(), af_key 
> needs to set this field too, just as xfrm_user. 
> In af_key.c, x-> only gets set when there's an 
> ext_hdrs[SADB_EXT_ADDRESS_PROXY-1] which I think is for tunnel.
> I think pfkey needs to also set the x-> field when it is 0.

Thanks for finding this bug Joy.

It basically proves that this inner address change was %100 not tested
in any reasonable way by the patch submitter.

Originally Herbert and I thought I only saw problems because XFRM_USER
cases such as openswan did not set the x-> field, but now
that we see that PF_KEY also has the same exact problem and as a
result I am very annoyed.

Joakim, TEST YOUR PATCHES, and not just with your BEET test cases,
before submitting them in the future.  Having normal configurations of
both PF_KEY and XFRM_USER ipsec totally break as a result of your
changes is totally unacceptable and I will doubly scrutinize your
patch submissions in the future because of what has happened here.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists