From: Gao Feng <redacted>
When memory is exhausted, nfct_seqadj_ext_add may fail to add the seqadj
extension. But the function nf_ct_seqadj_init doesn't check if get valid
seqadj pointer by the nfct_seqadj.
Now drop the packet directly when fail to add seqadj extension to avoid
dereference NULL pointer in nf_ct_seqadj_init.
Signed-off-by: Gao Feng <redacted>
---
v5: Return NF_ACCEPT instead of NF_DROP when nfct_seqadj_ext_add failed in nf_nat_setup_info
v4: Drop the packet directly when fail to add seqadj extension;
v3: Remove the warning log when seqadj is null;
v2: Remove the unnessary seqadj check in nf_ct_seq_adjust
v1: Initial patch
net/netfilter/nf_conntrack_core.c | 6 +++++-
net/netfilter/nf_nat_core.c | 3 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
From: Gao Feng <redacted>
When memory is exhausted, nfct_seqadj_ext_add may fail to add the seqadj
extension. But the function nf_ct_seqadj_init doesn't check if get valid
seqadj pointer by the nfct_seqadj.
Now drop the packet directly when fail to add seqadj extension to avoid
dereference NULL pointer in nf_ct_seqadj_init.
Signed-off-by: Gao Feng <redacted>
---
v5: Return NF_ACCEPT instead of NF_DROP when nfct_seqadj_ext_add failed in nf_nat_setup_info
v4: Drop the packet directly when fail to add seqadj extension;
v3: Remove the warning log when seqadj is null;
v2: Remove the unnessary seqadj check in nf_ct_seq_adjust
v1: Initial patch
net/netfilter/nf_conntrack_core.c | 6 +++++-
net/netfilter/nf_nat_core.c | 3 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
Hmm, why accept?
We are asked to add extension to rewrite sequence numbers, but
we cannot. How can the connection work if we cannot munge/track
seqno rewrites?
inline
On Tue, Sep 6, 2016 at 10:51 PM, Florian Westphal [off-list ref] wrote:
fgao@ikuai8.com [off-list ref] wrote:
quoted
From: Gao Feng <redacted>
When memory is exhausted, nfct_seqadj_ext_add may fail to add the seqadj
extension. But the function nf_ct_seqadj_init doesn't check if get valid
seqadj pointer by the nfct_seqadj.
Now drop the packet directly when fail to add seqadj extension to avoid
dereference NULL pointer in nf_ct_seqadj_init.
Signed-off-by: Gao Feng <redacted>
---
v5: Return NF_ACCEPT instead of NF_DROP when nfct_seqadj_ext_add failed in nf_nat_setup_info
v4: Drop the packet directly when fail to add seqadj extension;
v3: Remove the warning log when seqadj is null;
v2: Remove the unnessary seqadj check in nf_ct_seq_adjust
v1: Initial patch
net/netfilter/nf_conntrack_core.c | 6 +++++-
net/netfilter/nf_nat_core.c | 3 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
Hmm, why accept?
We are asked to add extension to rewrite sequence numbers, but
we cannot. How can the connection work if we cannot munge/track
seqno rewrites?
I thought we should drop the packet in that case before.
But Pablo point out one case that the ctnetlink also could add the
seqadj extension too.
There is one synchronization case.
I think he is right. Then modify the patch according to his advice.
Best Regards
Feng
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2016-09-07 09:19:11
On Tue, Sep 06, 2016 at 04:51:17PM +0200, Florian Westphal wrote:
fgao@ikuai8.com [off-list ref] wrote:
quoted
From: Gao Feng <redacted>
When memory is exhausted, nfct_seqadj_ext_add may fail to add the seqadj
extension. But the function nf_ct_seqadj_init doesn't check if get valid
seqadj pointer by the nfct_seqadj.
Now drop the packet directly when fail to add seqadj extension to avoid
dereference NULL pointer in nf_ct_seqadj_init.
Signed-off-by: Gao Feng <redacted>
---
v5: Return NF_ACCEPT instead of NF_DROP when nfct_seqadj_ext_add failed in nf_nat_setup_info
v4: Drop the packet directly when fail to add seqadj extension;
v3: Remove the warning log when seqadj is null;
v2: Remove the unnessary seqadj check in nf_ct_seq_adjust
v1: Initial patch
net/netfilter/nf_conntrack_core.c | 6 +++++-
net/netfilter/nf_nat_core.c | 3 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
Hmm, why accept?
We are asked to add extension to rewrite sequence numbers, but
we cannot. How can the connection work if we cannot munge/track
seqno rewrites?
Actually we could just NF_DROP, but if we add support for ctnetlink to
inject entries with sequence adjustment with no NAT. I think we need
this to get synproxy working with conntrackd state synchronization.
Thanks!