* [PATCH net] netfilter: ctnetlink: validate CTA_EXPECT_NAT_DIR to prevent OOB access
@ 2026-03-07 17:22 Hyunwoo Kim
2026-03-07 18:01 ` Florian Westphal
0 siblings, 1 reply; 3+ messages in thread
From: Hyunwoo Kim @ 2026-03-07 17:22 UTC (permalink / raw)
To: pablo, fw, phil, davem, edumazet, kuba, pabeni, horms
Cc: netfilter-devel, coreteam, netdev, imv4bel
ctnetlink_parse_expect_nat() assigns the user-supplied
CTA_EXPECT_NAT_DIR value directly to exp->dir without validating that it
is within the valid range (0 to IP_CT_DIR_MAX-1). When
nf_nat_sip_expected() later uses exp->dir as an index into
ct->master->tuplehash[], an out-of-bounds array access occurs.
For example, with exp->dir = 100, the access at
ct->master->tuplehash[100] reads 5600 bytes past the start of a
320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by
UBSAN.
Validate exp->dir against IP_CT_DIR_MAX before accepting it.
UBSAN report:
[ 1.411419] UBSAN: array-index-out-of-bounds in net/netfilter/nf_nat_sip.c:361:31
[ 1.412133] index 100 is out of range for type 'nf_conntrack_tuple_hash [2]'
[ 1.412365] CPU: 0 UID: 0 PID: 131 Comm: poc_exp_dir Not tainted 7.0.0-rc2+ #8 PREEMPTLAZY
[ 1.412368] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 1.412370] Call Trace:
[ 1.412374] <TASK>
[ 1.412375] dump_stack_lvl+0x64/0x80
[ 1.412388] __ubsan_handle_out_of_bounds+0xc9/0x100
[ 1.412398] nf_nat_sip_expected+0x4b9/0x4d0
[ 1.412405] ? __pfx_nf_nat_sip_expected+0x10/0x10
[ 1.412406] ? __asan_memset+0x23/0x50
[ 1.412413] ? nf_ct_ext_add+0x147/0x200
[ 1.412418] init_conntrack.isra.0+0x6c8/0x770
[ 1.412422] ? __pfx_init_conntrack.isra.0+0x10/0x10
[ 1.412424] ? hash_conntrack_raw+0xd9/0x170
[ 1.412425] ? crng_make_state+0x7b/0x180
[ 1.412431] nf_conntrack_in+0x583/0xac0
[ 1.412433] ? __pfx_nf_conntrack_in+0x10/0x10
[ 1.412435] ? __pfx_get_random_u32+0x10/0x10
[ 1.412437] ? __get_random_u32_below+0x16/0x70
[ 1.412439] ? __pfx_ipv4_conntrack_local+0x10/0x10
[ 1.412441] nf_hook_slow+0x75/0x150
[ 1.412444] __ip_local_out+0x20d/0x2f0
[ 1.412449] ? __pfx___ip_local_out+0x10/0x10
[ 1.412451] ? __pfx_dst_output+0x10/0x10
[ 1.412453] ? __pfx_ip_generic_getfrag+0x10/0x10
[ 1.412454] ? __pfx_ip_make_skb+0x10/0x10
[ 1.412456] ip_send_skb+0x31/0xe0
[ 1.412457] udp_send_skb+0x475/0x680
[ 1.412464] udp_sendmsg+0xbe9/0x1150
[ 1.412467] ? __pfx_ip_generic_getfrag+0x10/0x10
[ 1.412468] ? __pfx_udp_sendmsg+0x10/0x10
[ 1.412470] ? __pfx__raw_spin_lock+0x10/0x10
[ 1.412475] ? udp_lib_get_port+0x35b/0xaf0
[ 1.412477] ? __pfx_ip4_datagram_release_cb+0x10/0x10
[ 1.412479] ? __pfx_udp_lib_get_port+0x10/0x10
[ 1.412481] ? __pfx__raw_spin_lock_bh+0x10/0x10
[ 1.412482] ? aa_sk_perm+0x1a0/0x3f0
[ 1.412489] ? __check_object_size+0x4b/0x450
[ 1.412493] ? inet_send_prepare+0x33/0x140
[ 1.412496] __sys_sendto+0x2be/0x2e0
[ 1.412500] ? __pfx___sys_sendto+0x10/0x10
[ 1.412502] ? __pfx_inet_bind_sk+0x10/0x10
[ 1.412504] ? __sys_bind+0x168/0x1a0
[ 1.412506] ? __pfx_ksys_write+0x10/0x10
[ 1.412509] __x64_sys_sendto+0x76/0x90
[ 1.412511] do_syscall_64+0xc7/0x6c0
[ 1.412514] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 1.412521] RIP: 0033:0x423de7
[ 1.412525] Code: c7 c0 ff ff ff ff eb be 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d 7d 12 09 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 69 c3 55 48 89 e5 53 48 83 ec 38 44 89 4d d0
[ 1.412526] RSP: 002b:00007ffeaf8f5098 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
[ 1.412531] RAX: ffffffffffffffda RBX: 00007ffeaf8f50c0 RCX: 0000000000423de7
[ 1.412533] RDX: 0000000000000007 RSI: 0000000000488257 RDI: 0000000000000004
[ 1.412534] RBP: 00007ffeaf8f50f0 R08: 00007ffeaf8f50c0 R09: 0000000000000010
[ 1.412535] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffeaf8f5228
[ 1.412535] R13: 00007ffeaf8f5238 R14: 00000000004af868 R15: 0000000000000001
[ 1.412537] </TASK>
[ 1.412538] ---[ end trace ]---
Fixes: 076a0ca02644 ("netfilter: ctnetlink: add NAT support for expectations")
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
net/netfilter/nf_conntrack_netlink.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index c9d725fc2d71..fac75128dfb9 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -3497,6 +3497,8 @@ ctnetlink_parse_expect_nat(const struct nlattr *attr,
exp->saved_addr = nat_tuple.src.u3;
exp->saved_proto = nat_tuple.src.u;
exp->dir = ntohl(nla_get_be32(tb[CTA_EXPECT_NAT_DIR]));
+ if (exp->dir >= IP_CT_DIR_MAX)
+ return -EINVAL;
return 0;
#else
--
2.43.0
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH net] netfilter: ctnetlink: validate CTA_EXPECT_NAT_DIR to prevent OOB access
2026-03-07 17:22 [PATCH net] netfilter: ctnetlink: validate CTA_EXPECT_NAT_DIR to prevent OOB access Hyunwoo Kim
@ 2026-03-07 18:01 ` Florian Westphal
2026-03-08 10:42 ` Pablo Neira Ayuso
0 siblings, 1 reply; 3+ messages in thread
From: Florian Westphal @ 2026-03-07 18:01 UTC (permalink / raw)
To: Hyunwoo Kim
Cc: pablo, phil, davem, edumazet, kuba, pabeni, horms,
netfilter-devel, coreteam, netdev
Hyunwoo Kim <imv4bel@gmail.com> wrote:
> ctnetlink_parse_expect_nat() assigns the user-supplied
> CTA_EXPECT_NAT_DIR value directly to exp->dir without validating that it
> is within the valid range (0 to IP_CT_DIR_MAX-1). When
> nf_nat_sip_expected() later uses exp->dir as an index into
> ct->master->tuplehash[], an out-of-bounds array access occurs.
>
> For example, with exp->dir = 100, the access at
> ct->master->tuplehash[100] reads 5600 bytes past the start of a
> 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by
> UBSAN.
>
> Validate exp->dir against IP_CT_DIR_MAX before accepting it.
I would prefer a fix for exp_nat_nla_policy so netlink policy validation
can handle this for us.
[CTA_EXPECT_NAT_DIR] = NLA_POLICY_MAX(NLA_BE32, IPCT_DIR_MAX),
.. should do it. Might make sense to check all other attrs while at it.
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH net] netfilter: ctnetlink: validate CTA_EXPECT_NAT_DIR to prevent OOB access
2026-03-07 18:01 ` Florian Westphal
@ 2026-03-08 10:42 ` Pablo Neira Ayuso
0 siblings, 0 replies; 3+ messages in thread
From: Pablo Neira Ayuso @ 2026-03-08 10:42 UTC (permalink / raw)
To: Florian Westphal
Cc: Hyunwoo Kim, phil, davem, edumazet, kuba, pabeni, horms,
netfilter-devel, coreteam, netdev
On Sat, Mar 07, 2026 at 07:01:07PM +0100, Florian Westphal wrote:
> Hyunwoo Kim <imv4bel@gmail.com> wrote:
> > ctnetlink_parse_expect_nat() assigns the user-supplied
> > CTA_EXPECT_NAT_DIR value directly to exp->dir without validating that it
> > is within the valid range (0 to IP_CT_DIR_MAX-1). When
> > nf_nat_sip_expected() later uses exp->dir as an index into
> > ct->master->tuplehash[], an out-of-bounds array access occurs.
> >
> > For example, with exp->dir = 100, the access at
> > ct->master->tuplehash[100] reads 5600 bytes past the start of a
> > 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by
> > UBSAN.
> >
> > Validate exp->dir against IP_CT_DIR_MAX before accepting it.
>
> I would prefer a fix for exp_nat_nla_policy so netlink policy validation
> can handle this for us.
>
> [CTA_EXPECT_NAT_DIR] = NLA_POLICY_MAX(NLA_BE32, IPCT_DIR_MAX),
>
> .. should do it. Might make sense to check all other attrs while at it.
Agreed.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-03-08 10:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-07 17:22 [PATCH net] netfilter: ctnetlink: validate CTA_EXPECT_NAT_DIR to prevent OOB access Hyunwoo Kim
2026-03-07 18:01 ` Florian Westphal
2026-03-08 10:42 ` Pablo Neira Ayuso
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox