<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/net/xfrm, branch linux-5.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2019-07-26T07:12:39Z</updated>
<entry>
<title>ipsec: select crypto ciphers for xfrm_algo</title>
<updated>2019-07-26T07:12:39Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2019-06-18T11:22:13Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a275d049f958b18840375309fcda8fe084b8e6b8'/>
<id>urn:sha1:a275d049f958b18840375309fcda8fe084b8e6b8</id>
<content type='text'>
[ Upstream commit 597179b0ba550bd83fab1a9d57c42a9343c58514 ]

kernelci.org reports failed builds on arc because of what looks
like an old missed 'select' statement:

net/xfrm/xfrm_algo.o: In function `xfrm_probe_algs':
xfrm_algo.c:(.text+0x1e8): undefined reference to `crypto_has_ahash'

I don't see this in randconfig builds on other architectures, but
it's fairly clear we want to select the hash code for it, like we
do for all its other users. As Herbert points out, CRYPTO_BLKCIPHER
is also required even though it has not popped up in build tests.

Fixes: 17bc19702221 ("ipsec: Use skcipher and ahash when probing algorithms")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfrm: fix sa selector validation</title>
<updated>2019-07-26T07:12:36Z</updated>
<author>
<name>Nicolas Dichtel</name>
<email>nicolas.dichtel@6wind.com</email>
</author>
<published>2019-06-14T09:13:55Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=db1af6e8030327ed1d5aeec248299558d8adcc62'/>
<id>urn:sha1:db1af6e8030327ed1d5aeec248299558d8adcc62</id>
<content type='text'>
[ Upstream commit b8d6d0079757cbd1b69724cfd1c08e2171c68cee ]

After commit b38ff4075a80, the following command does not work anymore:
$ ip xfrm state add src 10.125.0.2 dst 10.125.0.1 proto esp spi 34 reqid 1 \
  mode tunnel enc 'cbc(aes)' 0xb0abdba8b782ad9d364ec81e3a7d82a1 auth-trunc \
  'hmac(sha1)' 0xe26609ebd00acb6a4d51fca13e49ea78a72c73e6 96 flag align4

In fact, the selector is not mandatory, allow the user to provide an empty
selector.

Fixes: b38ff4075a80 ("xfrm: Fix xfrm sel prefix length validation")
CC: Anirudh Gupta &lt;anirudh.gupta@sophos.com&gt;
Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfrm: Fix xfrm sel prefix length validation</title>
<updated>2019-07-26T07:12:26Z</updated>
<author>
<name>Anirudh Gupta</name>
<email>anirudhrudr@gmail.com</email>
</author>
<published>2019-05-21T15:29:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=191e0df41416442b5d33f95f79c4455d2a0f5485'/>
<id>urn:sha1:191e0df41416442b5d33f95f79c4455d2a0f5485</id>
<content type='text'>
[ Upstream commit b38ff4075a80b4da5cb2202d7965332ca0efb213 ]

Family of src/dst can be different from family of selector src/dst.
Use xfrm selector family to validate address prefix length,
while verifying new sa from userspace.

Validated patch with this command:
ip xfrm state add src 1.1.6.1 dst 1.1.6.2 proto esp spi 4260196 \
reqid 20004 mode tunnel aead "rfc4106(gcm(aes))" \
0x1111016400000000000000000000000044440001 128 \
sel src 1011:1:4::2/128 sel dst 1021:1:4::2/128 dev Port5

Fixes: 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.")
Signed-off-by: Anirudh Gupta &lt;anirudh.gupta@sophos.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfrm: Honor original L3 slave device in xfrmi policy lookup</title>
<updated>2019-03-27T15:14:05Z</updated>
<author>
<name>Martin Willi</name>
<email>martin@strongswan.org</email>
</author>
<published>2019-03-26T12:20:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=025c65e119bf58b610549ca359c9ecc5dee6a8d2'/>
<id>urn:sha1:025c65e119bf58b610549ca359c9ecc5dee6a8d2</id>
<content type='text'>
If an xfrmi is associated to a vrf layer 3 master device,
xfrm_policy_check() fails after traffic decapsulation. The input
interface is replaced by the layer 3 master device, and hence
xfrmi_decode_session() can't match the xfrmi anymore to satisfy
policy checking.

Extend ingress xfrmi lookup to honor the original layer 3 slave
device, allowing xfrm interfaces to operate within a vrf domain.

Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces")
Signed-off-by: Martin Willi &lt;martin@strongswan.org&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>xfrm: clean up xfrm protocol checks</title>
<updated>2019-03-26T07:35:36Z</updated>
<author>
<name>Cong Wang</name>
<email>xiyou.wangcong@gmail.com</email>
</author>
<published>2019-03-22T23:26:19Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=dbb2483b2a46fbaf833cfb5deb5ed9cace9c7399'/>
<id>urn:sha1:dbb2483b2a46fbaf833cfb5deb5ed9cace9c7399</id>
<content type='text'>
In commit 6a53b7593233 ("xfrm: check id proto in validate_tmpl()")
I introduced a check for xfrm protocol, but according to Herbert
IPSEC_PROTO_ANY should only be used as a wildcard for lookup, so
it should be removed from validate_tmpl().

And, IPSEC_PROTO_ANY is expected to only match 3 IPSec-specific
protocols, this is why xfrm_state_flush() could still miss
IPPROTO_ROUTING, which leads that those entries are left in
net-&gt;xfrm.state_all before exit net. Fix this by replacing
IPSEC_PROTO_ANY with zero.

This patch also extracts the check from validate_tmpl() to
xfrm_id_proto_valid() and uses it in parse_ipsecrequest().
With this, no other protocols should be added into xfrm.

Fixes: 6a53b7593233 ("xfrm: check id proto in validate_tmpl()")
Reported-by: syzbot+0bf0519d6e0de15914fe@syzkaller.appspotmail.com
Cc: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
Cc: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>Revert "net: xfrm: Add '_rcu' tag for rcu protected pointer in netns_xfrm"</title>
<updated>2019-03-20T16:56:13Z</updated>
<author>
<name>Steffen Klassert</name>
<email>steffen.klassert@secunet.com</email>
</author>
<published>2019-03-20T16:54:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bfc01ddff2b0c33de21af436324a669e95ac7e78'/>
<id>urn:sha1:bfc01ddff2b0c33de21af436324a669e95ac7e78</id>
<content type='text'>
This reverts commit f10e0010fae8174dc20bdc872bcaa85baa925cb7.

This commit was just wrong. It caused a lot of
syzbot warnings, so just revert it.

Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>net: xfrm: Add '_rcu' tag for rcu protected pointer in netns_xfrm</title>
<updated>2019-03-08T12:17:31Z</updated>
<author>
<name>Su Yanjun</name>
<email>suyj.fnst@cn.fujitsu.com</email>
</author>
<published>2019-03-07T01:54:08Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f10e0010fae8174dc20bdc872bcaa85baa925cb7'/>
<id>urn:sha1:f10e0010fae8174dc20bdc872bcaa85baa925cb7</id>
<content type='text'>
For rcu protected pointers, we'd better add '__rcu' for them.

Once added '__rcu' tag for rcu protected pointer, the sparse tool reports
warnings.

net/xfrm/xfrm_user.c:1198:39: sparse:    expected struct sock *sk
net/xfrm/xfrm_user.c:1198:39: sparse:    got struct sock [noderef] &lt;asn:4&gt; *nlsk
[...]

So introduce a new wrapper function of nlmsg_unicast  to handle type
conversions.

This patch also fixes a direct access of a rcu protected socket.

Fixes: be33690d8fcf("[XFRM]: Fix aevent related crash")
Signed-off-by: Su Yanjun &lt;suyj.fnst@cn.fujitsu.com&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>xfrm: policy: Fix out-of-bound array accesses in __xfrm_policy_unlink</title>
<updated>2019-03-01T11:17:41Z</updated>
<author>
<name>YueHaibing</name>
<email>yuehaibing@huawei.com</email>
</author>
<published>2019-02-28T07:18:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b805d78d300bcf2c83d6df7da0c818b0fee41427'/>
<id>urn:sha1:b805d78d300bcf2c83d6df7da0c818b0fee41427</id>
<content type='text'>
UBSAN report this:

UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24
index 6 is out of range for type 'unsigned int [6]'
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
 0000000000000000 1466cf39b41b23c9 ffff8801f6b07a58 ffffffff81cb35f4
 0000000041b58ab3 ffffffff83230f9c ffffffff81cb34e0 ffff8801f6b07a80
 ffff8801f6b07a20 1466cf39b41b23c9 ffffffff851706e0 ffff8801f6b07ae8
Call Trace:
 &lt;IRQ&gt;  [&lt;ffffffff81cb35f4&gt;] __dump_stack lib/dump_stack.c:15 [inline]
 &lt;IRQ&gt;  [&lt;ffffffff81cb35f4&gt;] dump_stack+0x114/0x1a0 lib/dump_stack.c:51
 [&lt;ffffffff81d94225&gt;] ubsan_epilogue+0x12/0x8f lib/ubsan.c:164
 [&lt;ffffffff81d954db&gt;] __ubsan_handle_out_of_bounds+0x16e/0x1b2 lib/ubsan.c:382
 [&lt;ffffffff82a25acd&gt;] __xfrm_policy_unlink+0x3dd/0x5b0 net/xfrm/xfrm_policy.c:1289
 [&lt;ffffffff82a2e572&gt;] xfrm_policy_delete+0x52/0xb0 net/xfrm/xfrm_policy.c:1309
 [&lt;ffffffff82a3319b&gt;] xfrm_policy_timer+0x30b/0x590 net/xfrm/xfrm_policy.c:243
 [&lt;ffffffff813d3927&gt;] call_timer_fn+0x237/0x990 kernel/time/timer.c:1144
 [&lt;ffffffff813d8e7e&gt;] __run_timers kernel/time/timer.c:1218 [inline]
 [&lt;ffffffff813d8e7e&gt;] run_timer_softirq+0x6ce/0xb80 kernel/time/timer.c:1401
 [&lt;ffffffff8120d6f9&gt;] __do_softirq+0x299/0xe10 kernel/softirq.c:273
 [&lt;ffffffff8120e676&gt;] invoke_softirq kernel/softirq.c:350 [inline]
 [&lt;ffffffff8120e676&gt;] irq_exit+0x216/0x2c0 kernel/softirq.c:391
 [&lt;ffffffff82c5edab&gt;] exiting_irq arch/x86/include/asm/apic.h:652 [inline]
 [&lt;ffffffff82c5edab&gt;] smp_apic_timer_interrupt+0x8b/0xc0 arch/x86/kernel/apic/apic.c:926
 [&lt;ffffffff82c5c985&gt;] apic_timer_interrupt+0xa5/0xb0 arch/x86/entry/entry_64.S:735
 &lt;EOI&gt;  [&lt;ffffffff81188096&gt;] ? native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:52
 [&lt;ffffffff810834d7&gt;] arch_safe_halt arch/x86/include/asm/paravirt.h:111 [inline]
 [&lt;ffffffff810834d7&gt;] default_idle+0x27/0x430 arch/x86/kernel/process.c:446
 [&lt;ffffffff81085f05&gt;] arch_cpu_idle+0x15/0x20 arch/x86/kernel/process.c:437
 [&lt;ffffffff8132abc3&gt;] default_idle_call+0x53/0x90 kernel/sched/idle.c:92
 [&lt;ffffffff8132b32d&gt;] cpuidle_idle_call kernel/sched/idle.c:156 [inline]
 [&lt;ffffffff8132b32d&gt;] cpu_idle_loop kernel/sched/idle.c:251 [inline]
 [&lt;ffffffff8132b32d&gt;] cpu_startup_entry+0x60d/0x9a0 kernel/sched/idle.c:299
 [&lt;ffffffff8113e119&gt;] start_secondary+0x3c9/0x560 arch/x86/kernel/smpboot.c:245

The issue is triggered as this:

xfrm_add_policy
    --&gt;verify_newpolicy_info  //check the index provided by user with XFRM_POLICY_MAX
			      //In my case, the index is 0x6E6BB6, so it pass the check.
    --&gt;xfrm_policy_construct  //copy the user's policy and set xfrm_policy_timer
    --&gt;xfrm_policy_insert
	--&gt; __xfrm_policy_link //use the orgin dir, in my case is 2
	--&gt; xfrm_gen_index   //generate policy index, there is 0x6E6BB6

then xfrm_policy_timer be fired

xfrm_policy_timer
   --&gt; xfrm_policy_id2dir  //get dir from (policy index &amp; 7), in my case is 6
   --&gt; xfrm_policy_delete
      --&gt; __xfrm_policy_unlink //access policy_count[dir], trigger out of range access

Add xfrm_policy_id2dir check in verify_newpolicy_info, make sure the computed dir is
valid, to fix the issue.

Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Fixes: e682adf021be ("xfrm: Try to honor policy index if it's supplied by user")
Signed-off-by: YueHaibing &lt;yuehaibing@huawei.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>xfrm: Fix inbound traffic via XFRM interfaces across network namespaces</title>
<updated>2019-02-18T09:58:54Z</updated>
<author>
<name>Tobias Brunner</name>
<email>tobias@strongswan.org</email>
</author>
<published>2019-02-18T09:49:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=660899ddf06ae8bb5bbbd0a19418b739375430c5'/>
<id>urn:sha1:660899ddf06ae8bb5bbbd0a19418b739375430c5</id>
<content type='text'>
After moving an XFRM interface to another namespace it stays associated
with the original namespace (net in `struct xfrm_if` and the list keyed
with `xfrmi_net_id`), allowing processes in the new namespace to use
SAs/policies that were created in the original namespace.  For instance,
this allows a keying daemon in one namespace to establish IPsec SAs for
other namespaces without processes there having access to the keys or IKE
credentials.

This worked fine for outbound traffic, however, for inbound traffic the
lookup for the interfaces and the policies used the incorrect namespace
(the one the XFRM interface was moved to).

Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces")
Signed-off-by: Tobias Brunner &lt;tobias@strongswan.org&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>xfrm: destroy xfrm_state synchronously on net exit path</title>
<updated>2019-02-05T05:29:20Z</updated>
<author>
<name>Cong Wang</name>
<email>xiyou.wangcong@gmail.com</email>
</author>
<published>2019-01-31T21:05:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f75a2804da391571563c4b6b29e7797787332673'/>
<id>urn:sha1:f75a2804da391571563c4b6b29e7797787332673</id>
<content type='text'>
xfrm_state_put() moves struct xfrm_state to the GC list
and schedules the GC work to clean it up. On net exit call
path, xfrm_state_flush() is called to clean up and
xfrm_flush_gc() is called to wait for the GC work to complete
before exit.

However, this doesn't work because one of the -&gt;destructor(),
ipcomp_destroy(), schedules the same GC work again inside
the GC work. It is hard to wait for such a nested async
callback. This is also why syzbot still reports the following
warning:

 WARNING: CPU: 1 PID: 33 at net/ipv6/xfrm6_tunnel.c:351 xfrm6_tunnel_net_exit+0x2cb/0x500 net/ipv6/xfrm6_tunnel.c:351
 ...
  ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153
  cleanup_net+0x51d/0xb10 net/core/net_namespace.c:551
  process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153
  worker_thread+0x143/0x14a0 kernel/workqueue.c:2296
  kthread+0x357/0x430 kernel/kthread.c:246
  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352

In fact, it is perfectly fine to bypass GC and destroy xfrm_state
synchronously on net exit call path, because it is in process context
and doesn't need a work struct to do any blocking work.

This patch introduces xfrm_state_put_sync() which simply bypasses
GC, and lets its callers to decide whether to use this synchronous
version. On net exit path, xfrm_state_fini() and
xfrm6_tunnel_net_exit() use it. And, as ipcomp_destroy() itself is
blocking, it can use xfrm_state_put_sync() directly too.

Also rename xfrm_state_gc_destroy() to ___xfrm_state_destroy() to
reflect this change.

Fixes: b48c05ab5d32 ("xfrm: Fix warning in xfrm6_tunnel_net_exit.")
Reported-and-tested-by: syzbot+e9aebef558e3ed673934@syzkaller.appspotmail.com
Cc: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
</feed>
