From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.216.245.30 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793950365; b=uo1H1uDYe6QXaKEmzHSCQ0Z4Aertb7YQ84dlHTZktjWCCxZKYwz+fri1FuKDf/TYPl2d Nn6lMvvBIwxbK7jGB8Q7sWrDikK2iIv5rT3XOLkom6hjzAvaFcv+LsIBjpUrHUTlJrMVM 5l5qn0OyMcwMjU99mmOZLqfTiEZJvxYztz6BRkgBGWk/ZYpEWtSsyPw7Vk7RgNm8Kp8II yFfbri43zTkLDsNN+NRjRwfmtqsoEcEA8I8zIdQhmxK3nziIzpt+aWao2mL6MqPOrB235 J6+Igjq23vQ6bliMAMV88R8FhuNMWg0VfeCs8ZJXXbwXHcMrN3aObG+huxRwgDF63Mg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793950365; h=DMARC-Filter:Received:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=BtAtw95vGaQmnVCMH7jtztM6j7fvRibjA0hUTnxbCX8=; b=GzmwzbOLagTLzRkihKkNgipmLtm/9IBWcYYmam1oIrAQ1R9rgLpSFDAN+zdyycQ6JQIm bVjtighei+RwNRGfSLcS84w+a6A6+VOvYI3sypb7iKMymN0TGwYA0JaOZl2S4hVbJi9D6 THjgAzkgR7u9vXl0+hZeSxwsUwUkoWLuquqBaCvZyJTvI2xxvq4s5P5cwTqZOLVzzRowE qfQyq6oxiTCTkcMaj2zkxnm5ww4XeIgajenGrZ4nXpUjUBZanaEbejyJcQsaTXdgmZet8 R+AKbi1AfWVvaaQfP1g4fM7Wy+rh7zjmfFVb0FA0P96Tw5M/yFOEOaW1kahyo5u0cbQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none header.from=strlen.de; spf=pass smtp.mailfrom=strlen.de; arc=none smtp.remote-ip=91.216.245.30 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [91.216.245.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 759C7606A32C; Fri, 6 Nov 2026 07:32:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 759C7606A32C Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=strlen.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=strlen.de Received: by Chamillionaire.breakpoint.cc (Postfix, from userid 1003) id CDAB46060B; Fri, 06 Nov 2026 08:32:41 +0100 (CET) Date: Fri, 6 Nov 2026 08:32:36 +0100 From: Florian Westphal To: xujiahao Cc: Pablo Neira Ayuso , Phil Sutter , netfilter-devel@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+2e819f6641708bb6ab9d@syzkaller.appspotmail.com Subject: Re: [PATCH nf] netfilter: xt_nat: allow IP_CT_RELATED_REPLY in DNAT targets Message-ID: References: <20261106065651.3504452-1-xujiahao@cmss.chinamobile.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261106065651.3504452-1-xujiahao@cmss.chinamobile.com> xujiahao wrote: > The DNAT targets warn when the conntrack info is neither IP_CT_NEW nor > IP_CT_RELATED, while the corresponding SNAT targets additionally accept > IP_CT_RELATED_REPLY: > > WARN_ON(!(ct != NULL && > (ctinfo == IP_CT_NEW || ctinfo == IP_CT_RELATED))); > > A TCP reset generated by nf_send_reset() on the reject path is attached > to the conntrack entry of the rejected packet and marked > IP_CT_RELATED_REPLY. I don't think thats correct. nf_conntrack_attach() assumes ICMP. TCP should just set IP_CT_ESTABLISHED, we're 'emulating' a reset packet coming from peer, so we should not create a fresh/new nat rewrite. I think this should be fixed in nf_conntrack_attach() to check for TCP and then set IP_CT_ESTABLISHED state for nskb. > It traverses the LOCAL_OUT NAT hook, where > nf_nat_inet_fn() lets IP_CT_RELATED_REPLY packets whose destination NAT > mapping is not initialized yet run the OUTPUT NAT chain. When that > chain holds an xtables DNAT target, the target is reached with > IP_CT_RELATED_REPLY and warns: > > WARNING: net/netfilter/xt_nat.c:154 at xt_dnat_target_v2+0x97/0xc0 This warning is correct. We should not do a DNAT mapping for IP_CT_RELATED_REPLY on TCP, it would cause packet rewrite. The IP_CT_RELATED_REPLY warning is old, from a time when DNAT was restricted to PRE_ROUTING hooks, which is likely why its only in the SNAT handler (which was restricted to POST_ROUTING only).