Using a rather simple test-case, it is possible to provoke NULL-pointer derefs in iptables-nft-restore. Said test-case involves a rule set with a thousand custom chains in each table, a thousand rules in each builtin chain and one rule in each custom chain - details are not important though, it is enough to have reasonably large tables to cause delays. The test script simply starts ten instances of iptables-nft-restore in background and ten instances in a loop in foreground, all reading above rule set. Critical detail is iptables-nft-restore pushing to kernel at each COMMIT line, so nft_rebuild_cache() may run multiple times during a single restore. The actual fix is contained in patch one. Patch two is actually a performance optimization, the behaviour it changes is not wrong per se. Patches three and four are fall-out from the first one. Phil Sutter (4): nft: cache: Fix nft_release_cache() under stress nft: cache: Make nft_rebuild_cache() respect fake cache nft: cache: Simplify chain list allocation nft: cache: Review flush_cache() iptables/nft-cache.c | 87 +++++++++++++++++++++++--------------------- iptables/nft.h | 3 +- 2 files changed, 48 insertions(+), 42 deletions(-) -- 2.25.1
