public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
* [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