linux-hardened/net/xfrm
Tobias Brunner 6916fb3b10 xfrm: Ignore socket policies when rebuilding hash tables
Whenever thresholds are changed the hash tables are rebuilt.  This is
done by enumerating all policies and hashing and inserting them into
the right table according to the thresholds and direction.

Because socket policies are also contained in net->xfrm.policy_all but
no hash tables are defined for their direction (dir + XFRM_POLICY_MAX)
this causes a NULL or invalid pointer dereference after returning from
policy_hash_bysel() if the rebuild is done while any socket policies
are installed.

Since the rebuild after changing thresholds is scheduled this crash
could even occur if the userland sets thresholds seemingly before
installing any socket policies.

Fixes: 53c2e285f9 ("xfrm: Do not hash socket policies")
Signed-off-by: Tobias Brunner <tobias@strongswan.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2016-07-29 10:21:54 +02:00
..
Kconfig net/xfrm: remove depends on CONFIG_EXPERIMENTAL 2013-01-11 11:40:03 -08:00
Makefile
xfrm_algo.c ipsec: Use skcipher and ahash when probing algorithms 2016-01-27 20:36:07 +08:00
xfrm_hash.c
xfrm_hash.h xfrm: hash prefixed policies based on preflen thresholds 2014-09-02 13:29:44 +02:00
xfrm_input.c xfrm: Fix crash observed during device unregistration and decryption 2016-03-24 14:29:36 -04:00
xfrm_ipcomp.c Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 2013-11-04 13:48:30 -05:00
xfrm_output.c xfrm: Reset encapsulation field of the skb before transformation 2016-03-17 10:28:44 +01:00
xfrm_policy.c xfrm: Ignore socket policies when rebuilding hash tables 2016-07-29 10:21:54 +02:00
xfrm_proc.c net: clean up snmp stats code 2014-05-07 16:06:05 -04:00
xfrm_replay.c xfrm: Always zero high-order sequence number bits 2015-05-21 06:56:23 +02:00
xfrm_state.c Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 2015-06-01 22:51:30 -07:00
xfrm_sysctl.c
xfrm_user.c xfrm: get rid of another incorrect WARN 2016-07-27 13:09:00 +02:00