We've gotten reports of a persistent memory leak in long running
ip{,6}tables-restore processes on Android R (where we merged in a
newer iptables release).
Memory usage has been seen to hit 100MB each.
As a reminder, android runs iptables-restore/ip6tables-restore as a
long running child process of netd (to eliminate process startup
overhead, which is not insignificant) and communicates to it over a
pipe. We don't use 'nft' nor 'ebtables'.
To quote/paraphrase a coworker: "I got a heap profile while playing
around with the networking config (connect & disconnect from wifi,
change hotspot params etc) which repros a leak. It looks like
xtables_find_target can malloc, but we don't free the results."
We believe (unconfirmed) it's likely due to this commit:
commit 148131f20421046fea028e638581e938ec985783[log] [tgz]
author Phil Sutter <phil@xxxxxx>Mon Feb 04 21:52:53 2019 +0100
committer Florian Westphal <fw@xxxxxxxxx>Tue Feb 05 16:09:41 2019 +0100
xtables: Fix for false-positive rule matching
Is this known? Fixed? I don't really understand what the commit is
trying to accomplish/fix. Could we just revert that commit (or the
libxtables/xtables.c portion there of)? Or is it perhaps obvious
where the free should be happening?
(and is there a similar problem with matches? the target and match
code seem equivalent wrt. to this clone behaviour, maybe there's a
similar issue)
Any hints?
- Maciej
