[PATCH] netfilter: xt_dccp: handle reserved options as single-byte

[PATCH] netfilter: xt_dccp: handle reserved options as single-byte

[tjdqudcks0424]

From: Sung Byeongchan <tjdqudcks0424@naver.com>

The DCCP UAPI defines option numbers 3 through 31 as reserved.  Like
Padding and Mandatory, these options occupy one byte.  dccp_find_option()
only treats values below 2 as single-byte and interprets the byte after a
reserved option as a TLV length.

This can skip a later option and invert an XT_DCCP_OPTION rule result.  A
local production-hook fixture installed the same DROP rule for IPv4 and
IPv6.  In three fresh boots per kernel, a target-only packet was dropped
20/20 times, while adding reserved option 3 before the same target let
20/20 packets reach the protected receiver.  The fixed kernel dropped all
trigger packets in three fresh boots and preserved the normal controls.

Treat every option up to DCCPO_MAX_RESERVED as single-byte, matching the
protocol definition.  Triggering requires
CONFIG_NETFILTER_XTABLES_LEGACY, CONFIG_NETFILTER_XT_MATCH_DCCP, an
option-based rule, and remote protocol-33 reachability.  The touched source
is unchanged at 0c2669a9f4a1d607e7591ae50ccf3c432a0aff08, where the patch
applies and builds cleanly.

The demonstrated impact is a conditional remote filter-verdict bypass.
No memory-safety violation, information disclosure, RCE, or LPE was
demonstrated.  The source reproducer and complete logs are available on
request and are not included in this public report.

OpenAI Codex assisted source inspection, test design, patch drafting, and
evidence organization.

Fixes: 1d3de414eb20 ("[NETFILTER]: New iptables DCCP protocol header match")
Assisted-by: LLM
Signed-off-by: Sung Byeongchan <tjdqudcks0424@naver.com>
---
 net/netfilter/xt_dccp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/xt_dccp.c b/net/netfilter/xt_dccp.c
index 3db81e041af9b..23a4e3e8df7de 100644
--- a/net/netfilter/xt_dccp.c
+++ b/net/netfilter/xt_dccp.c
@@ -62,7 +62,7 @@ dccp_find_option(u_int8_t option,
 			return true;
 		}
 
-		if (op[i] < 2 || i == optlen - 1)
+		if (op[i] <= DCCPO_MAX_RESERVED || i == optlen - 1)
 			i++;
 		else
 			i += op[i + 1] ? : 1;
-- 
2.43.0

Re: [PATCH] netfilter: xt_dccp: handle reserved options as single-byte

[Fernando Fernandez Mancera]

On 10/8/26 8:38 PM, tjdqudcks0424@naver.com wrote:
> From: Sung Byeongchan <tjdqudcks0424@naver.com>
> 
> The DCCP UAPI defines option numbers 3 through 31 as reserved.  Like
> Padding and Mandatory, these options occupy one byte.  dccp_find_option()
> only treats values below 2 as single-byte and interprets the byte after a
> reserved option as a TLV length.
> 
> This can skip a later option and invert an XT_DCCP_OPTION rule result.  A
> local production-hook fixture installed the same DROP rule for IPv4 and
> IPv6.  In three fresh boots per kernel, a target-only packet was dropped
> 20/20 times, while adding reserved option 3 before the same target let
> 20/20 packets reach the protected receiver.  The fixed kernel dropped all
> trigger packets in three fresh boots and preserved the normal controls.
> 
> Treat every option up to DCCPO_MAX_RESERVED as single-byte, matching the
> protocol definition.  Triggering requires
> CONFIG_NETFILTER_XTABLES_LEGACY, CONFIG_NETFILTER_XT_MATCH_DCCP, an
> option-based rule, and remote protocol-33 reachability.  The touched source
> is unchanged at 0c2669a9f4a1d607e7591ae50ccf3c432a0aff08, where the patch
> applies and builds cleanly.
> 
> The demonstrated impact is a conditional remote filter-verdict bypass.
> No memory-safety violation, information disclosure, RCE, or LPE was
> demonstrated.  The source reproducer and complete logs are available on
> request and are not included in this public report.
> 
> OpenAI Codex assisted source inspection, test design, patch drafting, and
> evidence organization.
> 
> Fixes: 1d3de414eb20 ("[NETFILTER]: New iptables DCCP protocol header match")
> Assisted-by: LLM
> Signed-off-by: Sung Byeongchan <tjdqudcks0424@naver.com>

The commit message is a bit too verbose and I doubt this has been found 
in a real environment. This might be a bit too extreme from my side but 
can we ditch DCCP support?

DCCP socket infrastructure was deprecated in 2023 at commit b144fcaf46d4 
("dccp: Print deprecation notice.") and removed more than a year ago in 
2025 at commit 2a63dd0edf38 ("net: Retire DCCP socket.").

I don't think someone is actively matching DCCP traffic as a middlebox.. 
what do you think?

Re: [PATCH] netfilter: xt_dccp: handle reserved options as single-byte

[성병찬]

-----Original Message-----
From: "Fernando Fernandez Mancera"<fmancera@suse.de> 
To: <tjdqudcks0424@naver.com>; "Pablo Neira Ayuso"<pablo@netfilter.org>; "Florian Westphal"<fw@strlen.de>; 
Cc: <netfilter-devel@vger.kernel.org>; 
Sent: 2026-10-09 (금) 17:34:55 (GMT+09:00)
Subject: Re: [PATCH] netfilter: xt_dccp: handle reserved options as single-byte

On 10/8/26 8:38 PM, tjdqudcks0424@naver.com wrote:
> From: Sung Byeongchan <tjdqudcks0424@naver.com>
> 
> The DCCP UAPI defines option numbers 3 through 31 as reserved.  Like
> Padding and Mandatory, these options occupy one byte.  dccp_find_option()
> only treats values below 2 as single-byte and interprets the byte after a
> reserved option as a TLV length.
> 
> This can skip a later option and invert an XT_DCCP_OPTION rule result.  A
> local production-hook fixture installed the same DROP rule for IPv4 and
> IPv6.  In three fresh boots per kernel, a target-only packet was dropped
> 20/20 times, while adding reserved option 3 before the same target let
> 20/20 packets reach the protected receiver.  The fixed kernel dropped all
> trigger packets in three fresh boots and preserved the normal controls.
> 
> Treat every option up to DCCPO_MAX_RESERVED as single-byte, matching the
> protocol definition.  Triggering requires
> CONFIG_NETFILTER_XTABLES_LEGACY, CONFIG_NETFILTER_XT_MATCH_DCCP, an
> option-based rule, and remote protocol-33 reachability.  The touched source
> is unchanged at 0c2669a9f4a1d607e7591ae50ccf3c432a0aff08, where the patch
> applies and builds cleanly.
> 
> The demonstrated impact is a conditional remote filter-verdict bypass.
> No memory-safety violation, information disclosure, RCE, or LPE was
> demonstrated.  The source reproducer and complete logs are available on
> request and are not included in this public report.
> 
> OpenAI Codex assisted source inspection, test design, patch drafting, and
> evidence organization.
> 
> Fixes: 1d3de414eb20 ("[NETFILTER]: New iptables DCCP protocol header match")
> Assisted-by: LLM
> Signed-off-by: Sung Byeongchan <tjdqudcks0424@naver.com>

The commit message is a bit too verbose and I doubt this has been found 
in a real environment. This might be a bit too extreme from my side but 
can we ditch DCCP support?

DCCP socket infrastructure was deprecated in 2023 at commit b144fcaf46d4 
("dccp: Print deprecation notice.") and removed more than a year ago in 
2025 at commit 2a63dd0edf38 ("net: Retire DCCP socket.").

I don't think someone is actively matching DCCP traffic as a middlebox.. 
what do you think?





Thanks for the review.

This was found through source review and reproduced with a controlled
local fixture, not from a real-world deployment. I agree that the commit
message can be shortened.

Removing xt_dccp seems broader than this fix because it may affect
existing rules that match forwarded protocol-33 traffic. However, I do
not have evidence of active users.

If removal is preferred, I can prepare a separate RFC patch. Otherwise,
I can send a v2 with the same fix and a shorter commit message.

Pablo, Florian, what direction would you prefer?

Re: [PATCH] netfilter: xt_dccp: handle reserved options as single-byte

[Florian Westphal]

성병찬 <tjdqudcks0424@naver.com> wrote:
> 
> -----Original Message-----
> From: "Fernando Fernandez Mancera"<fmancera@suse.de>
> To: <tjdqudcks0424@naver.com>; "Pablo Neira Ayuso"<pablo@netfilter.org>; "Florian Westphal"<fw@strlen.de>;
> Cc: <netfilter-devel@vger.kernel.org>;
> Sent: 2026-10-09 (금) 17:34:55 (GMT+09:00)
> Subject: Re: [PATCH] netfilter: xt_dccp: handle reserved options as single-byte
> 
> On 10/8/26 8:38 PM, tjdqudcks0424@naver.com wrote:
> > From: Sung Byeongchan <tjdqudcks0424@naver.com>
> >
> > The DCCP UAPI defines option numbers 3 through 31 as reserved.  Like
> > Padding and Mandatory, these options occupy one byte.  dccp_find_option()
> > only treats values below 2 as single-byte and interprets the byte after a
> > reserved option as a TLV length.
> >
> > This can skip a later option and invert an XT_DCCP_OPTION rule result.  A
> > local production-hook fixture installed the same DROP rule for IPv4 and
> > IPv6.  In three fresh boots per kernel, a target-only packet was dropped
> > 20/20 times, while adding reserved option 3 before the same target let
> > 20/20 packets reach the protected receiver.  The fixed kernel dropped all
> > trigger packets in three fresh boots and preserved the normal controls.
> >
> > Treat every option up to DCCPO_MAX_RESERVED as single-byte, matching the
> > protocol definition.  Triggering requires
> > CONFIG_NETFILTER_XTABLES_LEGACY, CONFIG_NETFILTER_XT_MATCH_DCCP, an
> > option-based rule, and remote protocol-33 reachability.  The touched source
> > is unchanged at 0c2669a9f4a1d607e7591ae50ccf3c432a0aff08, where the patch
> > applies and builds cleanly.
> >
> > The demonstrated impact is a conditional remote filter-verdict bypass.
> > No memory-safety violation, information disclosure, RCE, or LPE was
> > demonstrated.  The source reproducer and complete logs are available on
> > request and are not included in this public report.
> >
> > OpenAI Codex assisted source inspection, test design, patch drafting, and
> > evidence organization.
> >
> > Fixes: 1d3de414eb20 ("[NETFILTER]: New iptables DCCP protocol header match")
> > Assisted-by: LLM
> > Signed-off-by: Sung Byeongchan <tjdqudcks0424@naver.com>
> 
> The commit message is a bit too verbose and I doubt this has been found
> in a real environment. This might be a bit too extreme from my side but
> can we ditch DCCP support?

See: 606bd17ef0de ("netfilter: add deprecation warning for dccp support")

> Pablo, Florian, what direction would you prefer?

Well, you already made a fix and it makes more sense from -stable PoV.
So I'd say: Fix and then zap this thing early in 2027.

Re: [PATCH] netfilter: xt_dccp: handle reserved options as single-byte

[Fernando Fernandez Mancera]

On 10/9/26 1:58 PM, Florian Westphal wrote:
> 성병찬 <tjdqudcks0424@naver.com> wrote:
>>
>> -----Original Message-----
>> From: "Fernando Fernandez Mancera"<fmancera@suse.de>
>> To: <tjdqudcks0424@naver.com>; "Pablo Neira Ayuso"<pablo@netfilter.org>; "Florian Westphal"<fw@strlen.de>;
>> Cc: <netfilter-devel@vger.kernel.org>;
>> Sent: 2026-10-09 (금) 17:34:55 (GMT+09:00)
>> Subject: Re: [PATCH] netfilter: xt_dccp: handle reserved options as single-byte
>>
>> On 10/8/26 8:38 PM, tjdqudcks0424@naver.com wrote:
>>> From: Sung Byeongchan <tjdqudcks0424@naver.com>
>>>
>>> The DCCP UAPI defines option numbers 3 through 31 as reserved.  Like
>>> Padding and Mandatory, these options occupy one byte.  dccp_find_option()
>>> only treats values below 2 as single-byte and interprets the byte after a
>>> reserved option as a TLV length.
>>>
>>> This can skip a later option and invert an XT_DCCP_OPTION rule result.  A
>>> local production-hook fixture installed the same DROP rule for IPv4 and
>>> IPv6.  In three fresh boots per kernel, a target-only packet was dropped
>>> 20/20 times, while adding reserved option 3 before the same target let
>>> 20/20 packets reach the protected receiver.  The fixed kernel dropped all
>>> trigger packets in three fresh boots and preserved the normal controls.
>>>
>>> Treat every option up to DCCPO_MAX_RESERVED as single-byte, matching the
>>> protocol definition.  Triggering requires
>>> CONFIG_NETFILTER_XTABLES_LEGACY, CONFIG_NETFILTER_XT_MATCH_DCCP, an
>>> option-based rule, and remote protocol-33 reachability.  The touched source
>>> is unchanged at 0c2669a9f4a1d607e7591ae50ccf3c432a0aff08, where the patch
>>> applies and builds cleanly.
>>>
>>> The demonstrated impact is a conditional remote filter-verdict bypass.
>>> No memory-safety violation, information disclosure, RCE, or LPE was
>>> demonstrated.  The source reproducer and complete logs are available on
>>> request and are not included in this public report.
>>>
>>> OpenAI Codex assisted source inspection, test design, patch drafting, and
>>> evidence organization.
>>>
>>> Fixes: 1d3de414eb20 ("[NETFILTER]: New iptables DCCP protocol header match")
>>> Assisted-by: LLM
>>> Signed-off-by: Sung Byeongchan <tjdqudcks0424@naver.com>
>>
>> The commit message is a bit too verbose and I doubt this has been found
>> in a real environment. This might be a bit too extreme from my side but
>> can we ditch DCCP support?
> 
> See: 606bd17ef0de ("netfilter: add deprecation warning for dccp support")
> 

Ah right. Thanks Florian, then I will patiently wait until 2027.

>> Pablo, Florian, what direction would you prefer?
> 
> Well, you already made a fix and it makes more sense from -stable PoV.
> So I'd say: Fix and then zap this thing early in 2027.

Let's go with the fix then.

Thanks,
Fernando.

Re: [PATCH] netfilter: xt_dccp: handle reserved options as single-byte

[Fernando Fernandez Mancera]

On 10/8/26 8:38 PM, tjdqudcks0424@naver.com wrote:
> From: Sung Byeongchan <tjdqudcks0424@naver.com>
> 
> The DCCP UAPI defines option numbers 3 through 31 as reserved.  Like
> Padding and Mandatory, these options occupy one byte.  dccp_find_option()
> only treats values below 2 as single-byte and interprets the byte after a
> reserved option as a TLV length.
> 
> This can skip a later option and invert an XT_DCCP_OPTION rule result.  A
> local production-hook fixture installed the same DROP rule for IPv4 and
> IPv6.  In three fresh boots per kernel, a target-only packet was dropped
> 20/20 times, while adding reserved option 3 before the same target let
> 20/20 packets reach the protected receiver.  The fixed kernel dropped all
> trigger packets in three fresh boots and preserved the normal controls.
> 
> Treat every option up to DCCPO_MAX_RESERVED as single-byte, matching the
> protocol definition.  Triggering requires
> CONFIG_NETFILTER_XTABLES_LEGACY, CONFIG_NETFILTER_XT_MATCH_DCCP, an
> option-based rule, and remote protocol-33 reachability.  The touched source
> is unchanged at 0c2669a9f4a1d607e7591ae50ccf3c432a0aff08, where the patch
> applies and builds cleanly.
> 
> The demonstrated impact is a conditional remote filter-verdict bypass.
> No memory-safety violation, information disclosure, RCE, or LPE was
> demonstrated.  The source reproducer and complete logs are available on
> request and are not included in this public report.
> 
> OpenAI Codex assisted source inspection, test design, patch drafting, and
> evidence organization.
> 

I think these two paragraphs do not belong to the commit message. Could 
you drop them?

I think this should go through nf-next tree instead. Could you please 
add nf-next prefix in your v2?

Other than that, the patch looks good to me.

Thanks,
Fernando.

> Fixes: 1d3de414eb20 ("[NETFILTER]: New iptables DCCP protocol header match")
> Assisted-by: LLM
> Signed-off-by: Sung Byeongchan <tjdqudcks0424@naver.com>
> ---
>   net/netfilter/xt_dccp.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/netfilter/xt_dccp.c b/net/netfilter/xt_dccp.c
> index 3db81e041af9b..23a4e3e8df7de 100644
> --- a/net/netfilter/xt_dccp.c
> +++ b/net/netfilter/xt_dccp.c
> @@ -62,7 +62,7 @@ dccp_find_option(u_int8_t option,
>   			return true;
>   		}
>   
> -		if (op[i] < 2 || i == optlen - 1)
> +		if (op[i] <= DCCPO_MAX_RESERVED || i == optlen - 1)
>   			i++;
>   		else
>   			i += op[i + 1] ? : 1;