Its possible to set both HANDLE and POSITION when replacing a rule.
In this case, the rule at POSITION gets replaced using the
userspace-provided handle. Rule handles are supposed to be generated
by the kernel only.
Duplicate handles should be harmless, however better disable this "feature"
by
conn_free() holds lock with spin_lock(). and it is called by both
nf_conncount_lookup() and nf_conncount_gc_list().
nf_conncount_lookup() is bottom-half context and nf_conncount_gc_list()
is process context. so that spin_lock() is not safe.
Hence conn_free() should use spin_lock_bh() instead of
nf_conncount_tuple is an element of nft_connlimit and that is deleted by
conn_free(). elements can be deleted by both GC routine and
data path functions(nf_conncount_lookup, nf_conncount_add) and they
calls conn_free() to free elements.
But conn_free() only protects lists, not each element.
So
Three bugs in nf_conncount are fixed by this patch series.
First patch fixes inconsistent lock state in conn_free().
conn_free() is called both BH and process context. so that
spin_lock_bh() should be used.
Second patch fixes unsafe locking scenario of list element.
conn_free() can't protect
Signed-off-by: Florian Westphal
---
doc/primary-expression.txt | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/doc/primary-expression.txt b/doc/primary-expression.txt
index 761f50bc1392..5846898e170e 100644
--- a/doc/primary-expression.txt
+++
When list->count is 0, the list is deleted by GC.
But list->count is never reached 0. because Initial count value is 1
and it is increased when node is inserted.
So that initial value of list->count should be 0.
Originally GC always finds zero count list through deleting node and
decreasing