[PATCH nf] netfilter: nf_tables: don't use position attribute on rule replacement

2018-11-04 Thread Florian Westphal
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

[PATCH nf v2 1/3] netfilter: nf_conncount: use spin_lock_bh instead of spin_lock

2018-11-04 Thread Taehee Yoo
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

[PATCH nf v2 2/3] netfilter: nf_conncount: fix list_del corruption in conn_free

2018-11-04 Thread Taehee Yoo
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

[PATCH nf v2 0/3] netfilter: nf_conncount: fix bugs in conn_free

2018-11-04 Thread Taehee Yoo
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

[PATCH nft] documentation: try to clarify iif vs. iifname.

2018-11-04 Thread Florian Westphal
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 +++

[PATCH nf v2 3/3] netfilter: nf_conncount: fix unexpected permanent node of list.

2018-11-04 Thread Taehee Yoo
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