From: Steffen Klassert <steffen.klassert@secunet.com>
To: Antony Antony <antony.antony@secunet.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Christian Hopps <chopps@labn.net>,
Tobias Brunner <tobias@strongswan.org>, <netdev@vger.kernel.org>,
<syzbot+0ac4d84afe1066a1f3e9@syzkaller.appspotmail.com>
Subject: Re: [PATCH ipsec v2] xfrm: reject optional IPTFS templates in outbound policies
Date: Mon, 6 Jul 2026 08:19:37 +0200 [thread overview]
Message-ID: <aktI-XbTCnR27Sfe@secunet.com> (raw)
In-Reply-To: <20260627-xfrm-pol-out-tmpl-iptfs-reject-fix-v2-1-45ff81741874@secunet.com>
On Sat, Jun 27, 2026 at 10:23:43AM +0200, Antony Antony wrote:
> syzbot reported a stack-out-of-bounds read in xfrm_state_find()
> which flows from xfrm_tmpl_resolve_one().
>
> Commit 3d776e31c841 ("xfrm: Reject optional tunnel/BEET mode
> templates in outbound policies") disallowed optional tunnel and
> BEET in outbound policies to prevent this. Later when IPTFS
> added, it was not covered by that fix and can still trigger
> the out-of-bounds read;
>
> Extend the check to disallow optional IPTFS in outbound policies
> as well. IPTFS should be identical to tunnel mode.
> IN and FWD policies are not affected: xfrm_tmpl_resolve_one()
> is only reachable via the outbound path.
>
> Reproducer, before:
>
> ip link add dummy0 type dummy
> ip link set dummy0 up
> ip addr add 10.1.1.1/24 dev dummy0
> ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl
> src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs
> level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid
> 2 mode transport
> ping -W 1 -c 1 10.1.1.2
> PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data.
>
> [ 64.168420] ==================================================================
> [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170
> [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844
>
> [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full)
> [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> [ 64.169977] Call Trace:
> [ 64.169977] <TASK>
> [ 64.169977] dump_stack_lvl+0x47/0x70
> [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170
> [ 64.169977] print_report+0x152/0x4b0
> [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0
> [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20
> [ 64.169977] ? __virt_addr_valid+0x21b/0x230
> [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170
> [ 64.169977] kasan_report+0xa8/0xd0
> [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170
> [ 64.169977] __xfrm6_addr_hash+0x11e/0x170
> [ 64.169977] __xfrm_dst_hash+0x24/0xc0
> [ 64.169977] xfrm_state_find+0xa2d/0x2f90
> [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10
> [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10
> [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10
> [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570
> [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10
> [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10
> [ 64.169977] ? kernel_text_address+0x5b/0x80
> [ 64.169977] ? __kernel_text_address+0xe/0x30
> [ 64.169977] ? unwind_get_return_address+0x5e/0x90
> [ 64.169977] ? arch_stack_walk+0x8c/0xe0
> [ 64.169977] xfrm_tmpl_resolve+0x130/0x200
> [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10
> [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10
> [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110
> [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10
> [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310
> [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10
> [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10
> [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10
> [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80
> [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10
> [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110
> [ 64.169977] ? kasan_save_track+0x10/0x30
> [ 64.169977] xfrm_lookup_route+0x18/0xe0
> [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530
> [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10
> [ 64.169977] ? do_raw_spin_lock+0x71/0xc0
> [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10
> [ 64.169977] release_sock+0xb0/0x170
> [ 64.169977] udp_connect+0x43/0x50
> [ 64.169977] __sys_connect+0xa6/0x100
> [ 64.169977] ? alloc_fd+0x2e9/0x300
> [ 64.169977] ? __pfx___sys_connect+0x10/0x10
> [ 64.169977] ? preempt_latency_start+0x1f/0x70
> [ 64.169977] ? fd_install+0x7e/0x150
> [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20
> [ 64.169977] ? __sys_socket+0xdf/0x130
> [ 64.169977] ? __pfx___sys_socket+0x10/0x10
> [ 64.169977] ? vma_refcount_put+0x43/0xa0
> [ 64.169977] __x64_sys_connect+0x7e/0x90
> [ 64.169977] do_syscall_64+0x11b/0x2b0
> [ 64.169977] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 64.169977] RIP: 0033:0x7f4851ecb570
> [ 64.169977] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 80 3d f9 ca 0d 00 00 74 17 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 54
> [ 64.169977] RSP: 002b:00007ffc830e3498 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
> [ 64.169977] RAX: ffffffffffffffda RBX: 00007ffc830e34d0 RCX: 00007f4851ecb570
> [ 64.169977] RDX: 0000000000000010 RSI: 00007ffc830e34d0 RDI: 0000000000000005
> [ 64.169977] RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000
> [ 64.169977] R10: 0000000000000006 R11: 0000000000000202 R12: 0000000000000005
> [ 64.169977] R13: 0000000000000000 R14: 00005619a863f340 R15: 0000000000000000
> [ 64.169977] </TASK>
>
> [ 64.169977] The buggy address belongs to stack of task ping/2844
> [ 64.169977] and is located at offset 88 in frame:
> [ 64.169977] ip4_datagram_release_cb+0x0/0x530
>
> [ 64.169977] This frame has 1 object:
> [ 64.169977] [32, 88) 'fl4'
>
> [ 64.169977] The buggy address belongs to the physical page:
> [ 64.169977] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xe1ff
> [ 64.169977] flags: 0x4000000000000000(zone=1)
> [ 64.169977] raw: 4000000000000000 0000000000000000 ffffea0000387fc8 0000000000000000
> [ 64.169977] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
> [ 64.169977] page dumped because: kasan: bad access detected
>
> [ 64.169977] Memory state around the buggy address:
> [ 64.169977] ffff88800e1ffc00: f2 f2 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00
> [ 64.169977] ffff88800e1ffc80: 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00
> [ 64.169977] >ffff88800e1ffd00: 00 00 00 00 f3 f3 f3 f3 f3 00 00 00 00 00 00 00
> [ 64.169977] ^
> [ 64.169977] ffff88800e1ffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
> [ 64.169977] ffff88800e1ffe00: f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 64.169977] ==================================================================
> [ 64.245153] Disabling lock debugging due to kernel taint
>
> After the fix:
>
> ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl \
> src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs \
> level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 \
> mode transport
>
> Error: Mode in optional template not allowed in outbound policy.
>
> Fixes: d1716d5a44c3 ("xfrm: add generic iptfs defines and functionality")
> Reported-by: syzbot+0ac4d84afe1066a1f3e9@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/6a3ceb94.43b4ff68.30a095.0004.GAE@google.com/T/
> Signed-off-by: Antony Antony <antony.antony@secunet.com>
I decided for Antonys version of the fix.
Patch applied, thanks everyone!
prev parent reply other threads:[~2026-07-06 6:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-27 8:23 [PATCH ipsec v2] xfrm: reject optional IPTFS templates in outbound policies Antony Antony
2026-07-06 6:19 ` Steffen Klassert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aktI-XbTCnR27Sfe@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=antony.antony@secunet.com \
--cc=chopps@labn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=syzbot+0ac4d84afe1066a1f3e9@syzkaller.appspotmail.com \
--cc=tobias@strongswan.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox