Yi-Hung Wei and Justin Pettit found a race in the garbage collection scheme
used by nf_conncount.
When doing list walk, we lookup the tuple in the conntrack table.
If the lookup fails we remove this tuple from our list because
the conntrack entry is gone.
This is the common cause, but turns out its not the only one.
The list entry could have been created just before by another cpu, i.e. the
conntrack entry might not yet have been inserted into the global hash.
The avoid this, we introduce a timestamp and the owning cpu.
If the entry appears to be stale, evict only if:
1. The current cpu is the one that added the entry, or,
2. The timestamp is older than two jiffies
The second constraint allows GC to be taken over by other
cpu too (e.g. because a cpu was offlined or napi got moved to another
cpu).
We can't pretend the 'doubtful' entry wasn't in our list.
Instead, when we don't find an entry indicate via IS_ERR
that entry was removed ('did not exist' or withheld
('might-be-unconfirmed').
This most likely also fixes a xt_connlimit imbalance earlier reported by
Dmitry Andrianov.
Currently, we use check_hlist() for garbage colleciton. However, we
use the ‘zone’ from the counted entry to query the existence of
existing entries in the hlist. This could be wrong when they are in
different zones, and this patch fixes this issue.
Fixes: e59ea3df3fc2 ("netfilter: xt_connlimit: honor conntrack zone if available")
Signed-off-by: Yi-Hung Wei <email address hidden>
Signed-off-by: Pablo Neira Ayuso <email address hidden>
(backported from commit 21ba8847f857028dc83a0f341e16ecc616e34740)
[mfo: backport: refresh context lines and use older symbol/file names, note hunk 5:
- nf_conncount.c -> xt_connlimit.c
- nf_conncount_rb -> xt_connlimit_rb
- nf_conncount_tuple -> xt_connlimit_conn
- hunk 5: remove check for non-NULL 'tuple', that isn't required as it's introduced
by upstream commit 35d8deb80 ("netfilter: conncount: Support count only use case")
which addresses nf_conncount_count() that does not exist yet -- it's introduced by
upstream commit 625c556118f3 ("netfilter: connlimit: split xt_connlimit into front
and backend"), a refactor change.
- nft_connlimit.c -> removed, not used/doesn't exist yet.]
Signed-off-by: Mauricio Faria de Oliveira <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
089f2f9...
by
Pablo Neira Ayuso <email address hidden>
netfilter: nf_conncount: expose connection list interface
The previous commit made the 'addr' parameter in add_hlist() unused. So remove it
with a SAUCE patch, to simplify the backport of the next patches, as it is removed
anyway in upstream later (but before the next patches) through commit 625c556118f3
("netfilter: connlimit: split xt_connlimit into front and backend"), in the rename
from 'xt_connlimit.c' to 'nf_conncount.c', which is a large refactor we don't need.
Signed-off-by: Mauricio Faria de Oliveira <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
845edf5...
by
Florian Westphal <email address hidden>
netfilter: xt_connlimit: don't store address in the conn nodes
Only stored, never read. This is a leftover from commit 7d08487777c8
("netfilter: connlimit: use rbtree for per-host conntrack obj storage"),
which added the rbtree node struct that stores the address instead.
Signed-off-by: Florian Westphal <email address hidden>
Signed-off-by: Pablo Neira Ayuso <email address hidden>
(cherry picked from commit ce49480dba8666cba0106e8e31a942c9ce4c438a)
Signed-off-by: Mauricio Faria de Oliveira <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
UBUNTU: SAUCE: x86/speculation: Cleanup IBRS runtime control handling
In Ubuntu, we have runtime control for enabling/disabling IBRS via the
commandline ("noibrs") and through the proc interface
/proc/sys/kernel/ibrs_enabled. This commit simplifies the current
(probably broken) implementation by merging it with all the IBRS-related
upstream changes from previous commits.
What we have now is the upstream implementation for detecting the presence
of IBRS support. This commit adds a global state variable 'ibrs_enabled'
which is set to 1 if the CPU supports IBRS but can be overridden via the
commandline "noibrs" switch or by writting 0, 1 or 2 to
/proc/sys/kernel/ibrs_enabled at runtime.
Note that the runtime controls are disabled if the CPU runs in Enhanced
IBRS mode.
CVE-2017-5715
Signed-off-by: Juerg Haefliger <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
UBUNTU: SAUCE: x86/speculation: Cleanup IBPB runtime control handling
In Ubuntu, we have runtime control for enabling/disabling IBPB via the
commandline ("noibpb") and through the proc interface
/proc/sys/kernel/ibpb_enabled. This commit simplifies the current
(broken) implementation by merging it with all the IBPB-related upstream
changes from previous commits.
What we have now is the upstream implementation for detecting the presence
of IBPB support which is used in the alternative MSR write in
indirect_branch_prediction_barrier() to enable IBPB. On top of that, this
commit adds a global state variable 'ibpb_enabled' which is set to 1 if
the CPU supports IBPB but can be overridden via the commandline "noibpb"
switch or by writting 0 or 1 to /proc/sys/kernel/ibpb_enabled at runtime.
If ibpb_enabled is 0, indirect_branch_prediction_barrier() is turned into a
no-op, same as if the platform doesn't support IBPB.
CVE-2017-5715
Signed-off-by: Juerg Haefliger <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
