Re: [PATCH v3] netfilter: conntrack: fix integer overflow in expectation timeout

Re: [PATCH v3] netfilter: conntrack: fix integer overflow in expectation timeout

[tomaquet18]

Hi Pablo, Florian, and Greg,

Here is the v3 resubmission of the fix, with the changelog text properly wrapped at 72 columns as requested.

Regarding the security implications: while this function requires CAP_NET_ADMIN, I have verified that an unprivileged local user can trigger the overflow by setting up a user and network namespace (unshare -Ur -n).

Although this does not escape the sandbox, the 32-bit wrap-around forces the garbage collector to immediately destroy valid expectations. This breaks the integrity of the conntrack state machine and causes a selective local DoS against protocols relying on expectations within that environment.

Thanks for your time and review.

---
From b7a8f10666325ca70020769dc20d47776ccae440 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C3=80lex=20Fern=C3=A1ndez?= <tomaquet18@protonmail.com>
Date: Mon, 4 May 2026 09:51:40 +0200
Subject: [PATCH v3] netfilter: conntrack: fix integer overflow in expectation
 timeout
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In ctnetlink_change_expect(), the expectation timeout is calculated by
multiplying the user-provided timeout value by HZ. Because ntohl()
returns a 32-bit unsigned integer, this multiplication is performed in
32-bit arithmetic before being promoted to the 64-bit jiffies format.

If a user provides a large enough timeout (e.g., 42949673 on a system
with HZ=100), the multiplication wraps around the 32-bit limit,
resulting in a near-zero jiffies value. This causes the expectation
to be immediately collected by the garbage collector instead of staying
open for the requested duration.

This patch casts the result of ntohl() to u64 prior to multiplication,
matching the safe pattern already used for standard conntrack timeouts.

Signed-off-by: Àlex Fernández <tomaquet18@protonmail.com>
---
 net/netfilter/nf_conntrack_netlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index eda5fe4a7..be89bf1ba 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -3466,7 +3466,7 @@ ctnetlink_change_expect(struct nf_conntrack_expect *x,
                        return -ETIME;

                x->timeout.expires = jiffies +
-                       ntohl(nla_get_be32(cda[CTA_EXPECT_TIMEOUT])) * HZ;
+                       (u64)ntohl(nla_get_be32(cda[CTA_EXPECT_TIMEOUT])) * HZ;
                add_timer(&x->timeout);
        }
        return 0;
--
2.43.0

On Monday, May 4th, 2026 at 10:10, Greg KH <gregkh@linuxfoundation.org> wrote:

> On Mon, May 04, 2026 at 08:05:45AM +0000, tomaquet18 wrote:
> > Hi Willy,
> >
> > Thank you for the feedback and the guidance regarding the requirements. I completely understand.
> >
> > I have updated my identity to my real name. I am resending the fix as a v2 patch and including the Netfilter maintainers in CC as requested.
> 
> As this isn't a security issue, shouldn't this just be sent to the
> normal mailing list and maintainers that way?  Again, no need to cc:
> security@kernel.org anymore, right?
> 
> Also, you should wrap your changelog text at 72 columns.
> 
> thanks,
> 
> greg k-h
>

Re: [PATCH v3] netfilter: conntrack: fix integer overflow in expectation timeout

[Pablo Neira Ayuso]

Hi,

This is not security stuff, submitting this via
netfilter-devel@vger.kernel is sufficient.

Patchwork does not show your patch.

https://patchwork.ozlabs.org/project/netfilter-devel/list/

On Mon, May 04, 2026 at 10:14:25AM +0000, tomaquet18 wrote:
> Hi Pablo, Florian, and Greg,
> 
> Here is the v3 resubmission of the fix, with the changelog text properly wrapped at 72 columns as requested.
> 
> Regarding the security implications: while this function requires CAP_NET_ADMIN, I have verified that an unprivileged local user can trigger the overflow by setting up a user and network namespace (unshare -Ur -n).

What security implication? This is just the entry being removed
inmediately.

> Although this does not escape the sandbox, the 32-bit wrap-around forces the garbage collector to immediately destroy valid expectations. This breaks the integrity of the conntrack state machine and causes a selective local DoS against protocols relying on expectations within that environment.

What? "Selective local DoS against protocol relying on expectation"?

No, sorry. This is not security material, maybe nf-next stuff at best.

> Thanks for your time and review.
> 
> ---
> From b7a8f10666325ca70020769dc20d47776ccae440 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=C3=80lex=20Fern=C3=A1ndez?= <tomaquet18@protonmail.com>
> Date: Mon, 4 May 2026 09:51:40 +0200
> Subject: [PATCH v3] netfilter: conntrack: fix integer overflow in expectation
>  timeout
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> In ctnetlink_change_expect(), the expectation timeout is calculated by
> multiplying the user-provided timeout value by HZ. Because ntohl()
> returns a 32-bit unsigned integer, this multiplication is performed in
> 32-bit arithmetic before being promoted to the 64-bit jiffies format.
> 
> If a user provides a large enough timeout (e.g., 42949673 on a system
> with HZ=100), the multiplication wraps around the 32-bit limit,
> resulting in a near-zero jiffies value. This causes the expectation
> to be immediately collected by the garbage collector instead of staying
> open for the requested duration.
> 
> This patch casts the result of ntohl() to u64 prior to multiplication,
> matching the safe pattern already used for standard conntrack timeouts.
> 
> Signed-off-by: Àlex Fernández <tomaquet18@protonmail.com>
> ---
>  net/netfilter/nf_conntrack_netlink.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
> index eda5fe4a7..be89bf1ba 100644
> --- a/net/netfilter/nf_conntrack_netlink.c
> +++ b/net/netfilter/nf_conntrack_netlink.c
> @@ -3466,7 +3466,7 @@ ctnetlink_change_expect(struct nf_conntrack_expect *x,
>                         return -ETIME;
> 
>                 x->timeout.expires = jiffies +
> -                       ntohl(nla_get_be32(cda[CTA_EXPECT_TIMEOUT])) * HZ;
> +                       (u64)ntohl(nla_get_be32(cda[CTA_EXPECT_TIMEOUT])) * HZ;
>                 add_timer(&x->timeout);
>         }
>         return 0;
> --
> 2.43.0
> 
> On Monday, May 4th, 2026 at 10:10, Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> > On Mon, May 04, 2026 at 08:05:45AM +0000, tomaquet18 wrote:
> > > Hi Willy,
> > >
> > > Thank you for the feedback and the guidance regarding the requirements. I completely understand.
> > >
> > > I have updated my identity to my real name. I am resending the fix as a v2 patch and including the Netfilter maintainers in CC as requested.
> > 
> > As this isn't a security issue, shouldn't this just be sent to the
> > normal mailing list and maintainers that way?  Again, no need to cc:
> > security@kernel.org anymore, right?
> > 
> > Also, you should wrap your changelog text at 72 columns.
> > 
> > thanks,
> > 
> > greg k-h
> >

Re: [PATCH v3] netfilter: conntrack: fix integer overflow in expectation timeout

[tomaquet18]

Hi Pablo,

Understood completely. I have dropped the security framing and will treat this strictly as a functional bug fix for nf-next.

I realize my previous email format broke Patchwork. I have just sent a clean v4 patch in a new thread addressing all your feedback.

Thanks for the guidance and your time.

On Monday, May 4th, 2026 at 12:36, Pablo Neira Ayuso <pablo@netfilter.org> wrote:

> Hi,
>
> This is not security stuff, submitting this via
> netfilter-devel@vger.kernel is sufficient.
>
> Patchwork does not show your patch.
>
> https://patchwork.ozlabs.org/project/netfilter-devel/list/
>
> On Mon, May 04, 2026 at 10:14:25AM +0000, tomaquet18 wrote:
> > Hi Pablo, Florian, and Greg,
> >
> > Here is the v3 resubmission of the fix, with the changelog text properly wrapped at 72 columns as requested.
> >
> > Regarding the security implications: while this function requires CAP_NET_ADMIN, I have verified that an unprivileged local user can trigger the overflow by setting up a user and network namespace (unshare -Ur -n).
>
> What security implication? This is just the entry being removed
> inmediately.
>
> > Although this does not escape the sandbox, the 32-bit wrap-around forces the garbage collector to immediately destroy valid expectations. This breaks the integrity of the conntrack state machine and causes a selective local DoS against protocols relying on expectations within that environment.
>
> What? "Selective local DoS against protocol relying on expectation"?
>
> No, sorry. This is not security material, maybe nf-next stuff at best.
>
> > Thanks for your time and review.
> >
> > ---
> > From b7a8f10666325ca70020769dc20d47776ccae440 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?=C3=80lex=20Fern=C3=A1ndez?= <tomaquet18@protonmail.com>
> > Date: Mon, 4 May 2026 09:51:40 +0200
> > Subject: [PATCH v3] netfilter: conntrack: fix integer overflow in expectation
> >  timeout
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > In ctnetlink_change_expect(), the expectation timeout is calculated by
> > multiplying the user-provided timeout value by HZ. Because ntohl()
> > returns a 32-bit unsigned integer, this multiplication is performed in
> > 32-bit arithmetic before being promoted to the 64-bit jiffies format.
> >
> > If a user provides a large enough timeout (e.g., 42949673 on a system
> > with HZ=100), the multiplication wraps around the 32-bit limit,
> > resulting in a near-zero jiffies value. This causes the expectation
> > to be immediately collected by the garbage collector instead of staying
> > open for the requested duration.
> >
> > This patch casts the result of ntohl() to u64 prior to multiplication,
> > matching the safe pattern already used for standard conntrack timeouts.
> >
> > Signed-off-by: Àlex Fernández <tomaquet18@protonmail.com>
> > ---
> >  net/netfilter/nf_conntrack_netlink.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
> > index eda5fe4a7..be89bf1ba 100644
> > --- a/net/netfilter/nf_conntrack_netlink.c
> > +++ b/net/netfilter/nf_conntrack_netlink.c
> > @@ -3466,7 +3466,7 @@ ctnetlink_change_expect(struct nf_conntrack_expect *x,
> >                         return -ETIME;
> >
> >                 x->timeout.expires = jiffies +
> > -                       ntohl(nla_get_be32(cda[CTA_EXPECT_TIMEOUT])) * HZ;
> > +                       (u64)ntohl(nla_get_be32(cda[CTA_EXPECT_TIMEOUT])) * HZ;
> >                 add_timer(&x->timeout);
> >         }
> >         return 0;
> > --
> > 2.43.0
> >
> > On Monday, May 4th, 2026 at 10:10, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > > On Mon, May 04, 2026 at 08:05:45AM +0000, tomaquet18 wrote:
> > > > Hi Willy,
> > > >
> > > > Thank you for the feedback and the guidance regarding the requirements. I completely understand.
> > > >
> > > > I have updated my identity to my real name. I am resending the fix as a v2 patch and including the Netfilter maintainers in CC as requested.
> > >
> > > As this isn't a security issue, shouldn't this just be sent to the
> > > normal mailing list and maintainers that way?  Again, no need to cc:
> > > security@kernel.org anymore, right?
> > >
> > > Also, you should wrap your changelog text at 72 columns.
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
>