* [PATCH v2] netfilter: conntrack: clamp timeouts to INT_MAX
@ 2017-11-11 10:08 Jay Elliott
2017-11-11 18:27 ` Florian Westphal
0 siblings, 1 reply; 4+ messages in thread
From: Jay Elliott @ 2017-11-11 10:08 UTC (permalink / raw)
To: pablo; +Cc: Jay Elliott, fw, netfilter-devel
As of commit 58e207e4983d ("netfilter: evict stale entries when user reads
/proc/net/nf_conntrack"), timeouts are evaluated by casting the difference
between a timeout value and the nfct_time_stamp to a signed integer and
comparing that to zero.
This means that any timeout greater than or equal to (1<<31) will be
considered negative, and the conntracking code will think it has
immediately expired. Prior to 58e207e4983d, they would have been treated
as very large positive timeouts.
The upshot of this is that userspace software which is used to being able
to create conntracking timeouts >= (1<<31) can accidentally create a
negative timeout which will expire immediately. To protect against this,
incoming timeouts are clamped to INT_MAX after they are added to the
nfct_time_stamp.
Fixes: 58e207e4983d ("netfilter: evict stale entries when user reads /proc/net/nf_conntrack")
Signed-off-by: Jay Elliott <jelliott@arista.com>
---
net/netfilter/nf_conntrack_core.c | 6 +++++-
net/netfilter/nf_conntrack_netlink.c | 15 ++++++++++++---
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 0113039..8f55da3 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -734,6 +734,7 @@ static int nf_ct_resolve_clash(struct net *net, struct sk_buff *skb,
struct net *net;
unsigned int sequence;
int ret = NF_DROP;
+ u_int64_t timeout64;
ct = nf_ct_get(skb, &ctinfo);
net = nf_ct_net(ct);
@@ -796,7 +797,10 @@ static int nf_ct_resolve_clash(struct net *net, struct sk_buff *skb,
/* Timer relative to confirmation time, not original
setting time, otherwise we'd get timer wrap in
weird delay cases. */
- ct->timeout += nfct_time_stamp;
+ timeout64 = (u_int64_t)ct->timeout + nfct_time_stamp;
+ if (timeout64 > INT_MAX)
+ timeout64 = INT_MAX;
+ ct->timeout = timeout64;
atomic_inc(&ct->ct_general.use);
ct->status |= IPS_CONFIRMED;
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index de4053d..3db8e03 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -1560,9 +1560,12 @@ static int ctnetlink_change_helper(struct nf_conn *ct,
static int ctnetlink_change_timeout(struct nf_conn *ct,
const struct nlattr * const cda[])
{
- u_int32_t timeout = ntohl(nla_get_be32(cda[CTA_TIMEOUT]));
+ u_int64_t timeout = ntohl(nla_get_be32(cda[CTA_TIMEOUT]));
+ u_int64_t timeout_absolute = timeout * HZ + (u_int64_t)nfct_time_stamp;
- ct->timeout = nfct_time_stamp + timeout * HZ;
+ if (timeout_absolute > INT_MAX)
+ timeout_absolute = INT_MAX;
+ ct->timeout = timeout_absolute;
if (test_bit(IPS_DYING_BIT, &ct->status))
return -ETIME;
@@ -1762,6 +1765,8 @@ static int change_seq_adj(struct nf_ct_seqadj *seq,
int err = -EINVAL;
struct nf_conntrack_helper *helper;
struct nf_conn_tstamp *tstamp;
+ u_int64_t timeout_absolute;
+ u_int64_t timeout_nla;
ct = nf_conntrack_alloc(net, zone, otuple, rtuple, GFP_ATOMIC);
if (IS_ERR(ct))
@@ -1770,7 +1775,11 @@ static int change_seq_adj(struct nf_ct_seqadj *seq,
if (!cda[CTA_TIMEOUT])
goto err1;
- ct->timeout = nfct_time_stamp + ntohl(nla_get_be32(cda[CTA_TIMEOUT])) * HZ;
+ timeout_nla = ntohl(nla_get_be32(cda[CTA_TIMEOUT]));
+ timeout_absolute = (u_int64_t)nfct_time_stamp + timeout_nla * HZ;
+ if (timeout_absolute > INT_MAX)
+ timeout_absolute = INT_MAX;
+ ct->timeout = timeout_absolute;
rcu_read_lock();
if (cda[CTA_HELP]) {
--
1.8.1.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2] netfilter: conntrack: clamp timeouts to INT_MAX
2017-11-11 10:08 [PATCH v2] netfilter: conntrack: clamp timeouts to INT_MAX Jay Elliott
@ 2017-11-11 18:27 ` Florian Westphal
2017-11-14 2:25 ` Jay Elliott
0 siblings, 1 reply; 4+ messages in thread
From: Florian Westphal @ 2017-11-11 18:27 UTC (permalink / raw)
To: Jay Elliott; +Cc: pablo, fw, netfilter-devel
Jay Elliott <jelliott@arista.com> wrote:
> As of commit 58e207e4983d ("netfilter: evict stale entries when user reads
> /proc/net/nf_conntrack"), timeouts are evaluated by casting the difference
> between a timeout value and the nfct_time_stamp to a signed integer and
> comparing that to zero.
>
> This means that any timeout greater than or equal to (1<<31) will be
> considered negative, and the conntracking code will think it has
> immediately expired. Prior to 58e207e4983d, they would have been treated
> as very large positive timeouts.
>
> The upshot of this is that userspace software which is used to being able
> to create conntracking timeouts >= (1<<31) can accidentally create a
> negative timeout which will expire immediately. To protect against this,
> incoming timeouts are clamped to INT_MAX after they are added to the
> nfct_time_stamp.
>
> Fixes: 58e207e4983d ("netfilter: evict stale entries when user reads /proc/net/nf_conntrack")
> Signed-off-by: Jay Elliott <jelliott@arista.com>
> ---
> net/netfilter/nf_conntrack_core.c | 6 +++++-
> net/netfilter/nf_conntrack_netlink.c | 15 ++++++++++++---
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> index 0113039..8f55da3 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -734,6 +734,7 @@ static int nf_ct_resolve_clash(struct net *net, struct sk_buff *skb,
> struct net *net;
> unsigned int sequence;
> int ret = NF_DROP;
> + u_int64_t timeout64;
>
> ct = nf_ct_get(skb, &ctinfo);
> net = nf_ct_net(ct);
> @@ -796,7 +797,10 @@ static int nf_ct_resolve_clash(struct net *net, struct sk_buff *skb,
> /* Timer relative to confirmation time, not original
> setting time, otherwise we'd get timer wrap in
> weird delay cases. */
> - ct->timeout += nfct_time_stamp;
> + timeout64 = (u_int64_t)ct->timeout + nfct_time_stamp;
> + if (timeout64 > INT_MAX)
> + timeout64 = INT_MAX;
> + ct->timeout = timeout64;
I don't understand why this needs to be changed. It also looks wrong.
let ct->timeout be 1000.
let nfct_time_stamp be 0x80000000
Then ct->timout is capped to 0x7fffffff.
Next check considers the timeout to be expired, as 0x7fff... - 0x800 < 0.
> diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
> index de4053d..3db8e03 100644
> --- a/net/netfilter/nf_conntrack_netlink.c
> +++ b/net/netfilter/nf_conntrack_netlink.c
> @@ -1560,9 +1560,12 @@ static int ctnetlink_change_helper(struct nf_conn *ct,
> static int ctnetlink_change_timeout(struct nf_conn *ct,
> const struct nlattr * const cda[])
> {
> - u_int32_t timeout = ntohl(nla_get_be32(cda[CTA_TIMEOUT]));
> + u_int64_t timeout = ntohl(nla_get_be32(cda[CTA_TIMEOUT]));
> + u_int64_t timeout_absolute = timeout * HZ + (u_int64_t)nfct_time_stamp;
>
> - ct->timeout = nfct_time_stamp + timeout * HZ;
> + if (timeout_absolute > INT_MAX)
> + timeout_absolute = INT_MAX;
> + ct->timeout = timeout_absolute;
Same applies here.
I would have expected something like
u_int32_t timeout = ntohl(nla_get_be32(cda[CTA_TIMEOUT]));
if (timeout > INT_MAX)
timeout = INT_MAX;
> + u_int64_t timeout_nla;
>
> ct = nf_conntrack_alloc(net, zone, otuple, rtuple, GFP_ATOMIC);
> if (IS_ERR(ct))
> @@ -1770,7 +1775,11 @@ static int change_seq_adj(struct nf_ct_seqadj *seq,
> if (!cda[CTA_TIMEOUT])
> goto err1;
>
> - ct->timeout = nfct_time_stamp + ntohl(nla_get_be32(cda[CTA_TIMEOUT])) * HZ;
and here something similar, read CTA_TIMEOUT, cap to INT_MAX.
Actually looking ast this this was always a bit broken because * HZ can
overflow.
So I guess best bet is to actually do a 64bit multiplication, as you
did, then truncate.
Please use u64 for this (the u_intXX_t types are prehistoric leftovers).
Thanks!
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] netfilter: conntrack: clamp timeouts to INT_MAX
2017-11-11 18:27 ` Florian Westphal
@ 2017-11-14 2:25 ` Jay Elliott
2017-11-14 6:41 ` Florian Westphal
0 siblings, 1 reply; 4+ messages in thread
From: Jay Elliott @ 2017-11-14 2:25 UTC (permalink / raw)
To: Florian Westphal; +Cc: pablo, netfilter-devel
On Sat, Nov 11, 2017 at 10:27 AM, Florian Westphal <fw@strlen.de> wrote:
> It also looks wrong.
> let ct->timeout be 1000.
> let nfct_time_stamp be 0x80000000
>
> Then ct->timout is capped to 0x7fffffff.
> Next check considers the timeout to be expired, as 0x7fff... - 0x800 < 0.
Thanks for pointing that out; it does look like something that could
cause troubles.
Is it alright if I submit a fix to this as a separate patch? I
*think* I have a solution (pending some testing), but I also think
it's outside of the scope of this commit since it's a pre-existing
problem so I'd like to fix it separately.
> So I guess best bet is to actually do a 64bit multiplication, as you
> did, then truncate.
>
> Please use u64 for this (the u_intXX_t types are prehistoric leftovers).
So to clarify, are changing the u_int64_t variables to u64 and fixing
the case where nfct_time_stamp >= 0x8000... the only changes that need
to be made based on the v2 patch I sent out?
Thank you,
Jay Elliott
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] netfilter: conntrack: clamp timeouts to INT_MAX
2017-11-14 2:25 ` Jay Elliott
@ 2017-11-14 6:41 ` Florian Westphal
0 siblings, 0 replies; 4+ messages in thread
From: Florian Westphal @ 2017-11-14 6:41 UTC (permalink / raw)
To: Jay Elliott; +Cc: Florian Westphal, pablo, netfilter-devel
Jay Elliott <jelliott@arista.com> wrote:
> On Sat, Nov 11, 2017 at 10:27 AM, Florian Westphal <fw@strlen.de> wrote:
> > It also looks wrong.
> > let ct->timeout be 1000.
> > let nfct_time_stamp be 0x80000000
> >
> > Then ct->timout is capped to 0x7fffffff.
> > Next check considers the timeout to be expired, as 0x7fff... - 0x800 < 0.
>
> Thanks for pointing that out; it does look like something that could
> cause troubles.
>
> Is it alright if I submit a fix to this as a separate patch? I
> *think* I have a solution (pending some testing), but I also think
> it's outside of the scope of this commit since it's a pre-existing
> problem so I'd like to fix it separately.
Sorry, I am not following. This problem is added with this patch.
> > So I guess best bet is to actually do a 64bit multiplication, as you
> > did, then truncate.
> >
> > Please use u64 for this (the u_intXX_t types are prehistoric leftovers).
>
> So to clarify, are changing the u_int64_t variables to u64 and fixing
> the case where nfct_time_stamp >= 0x8000... the only changes that need
> to be made based on the v2 patch I sent out?
Yes, I think so, only changes in nfnetlink.c are needed, i.e. (totally untested):
- u_int32_t timeout = ntohl(nla_get_be32(cda[CTA_TIMEOUT]));
+ u64 timeout = ntohl(nla_get_be32(cda[CTA_TIMEOUT])) * HZ;
+
+ if (timeout > INT_MAX)
timeout = INT_MAX;
- ct->timeout = nfct_time_stamp + timeout * HZ;
+ ct->timeout = nfct_time_stamp + (u32)timeout;
if (test_bit(IPS_DYING_BIT, &ct->status))
return -ETIME;
@@ -1762,6 +1765,8 @@ static int change_seq_adj(struct nf_ct_seqadj *seq,
int err = -EINVAL;
struct nf_conntrack_helper *helper;
struct nf_conn_tstamp *tstamp;
+ u64 timeout_nla;
ct = nf_conntrack_alloc(net, zone, otuple, rtuple, GFP_ATOMIC);
if (IS_ERR(ct))
@@ -1770,7 +1775,11 @@ static int change_seq_adj(struct nf_ct_seqadj *seq,
if (!cda[CTA_TIMEOUT])
goto err1;
- ct->timeout = nfct_time_stamp + ntohl(nla_get_be32(cda[CTA_TIMEOUT])) * HZ;
+ timeout_nla = ntohl(nla_get_be32(cda[CTA_TIMEOUT])) * HZ;
+ if (timeout_nla > INT_MAX)
+ timeout_nla = INT_MAX;
+ ct->timeout = nfct_time_stamp + timeout_nla;
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-11-14 6:41 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-11-11 10:08 [PATCH v2] netfilter: conntrack: clamp timeouts to INT_MAX Jay Elliott
2017-11-11 18:27 ` Florian Westphal
2017-11-14 2:25 ` Jay Elliott
2017-11-14 6:41 ` Florian Westphal
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).