Florent Revest revest@chromium.org wrote:
in this case an initcall is failing and I think panic is preferrable to a kernel that behaves like NF_CONNTRACK_FTP=n.
In that case, it seems like what you'd want is nf_conntrack_standalone_init() to BUG() instead of returning an error then ? (so you'd never get to NF_CONNTRACK_FTP or any other if nf_conntrack failed to initialize) If this is the prefered behavior, then sure, why not.
AFAICS this problem is specific to NF_CONNTRACK_FTP=y (or any other helper module, for that matter).
Even with NF_CONNTRACK_FTP=m, the initialization failure in nf_conntrack_standalone_init() still happens. Therefore, the helper hashtable gets freed and when the nf_conntrack_ftp.ko module gets insmod-ed, it calls nf_conntrack_helpers_register() and this still causes a use-after-free.
Can you send a v2 with a slightly reworded changelog?
It should mention that one needs NF_CONNTRACK=y, so that when the failure happens during the initcall (as oposed to module insertion), nf_conntrack_helpers_register() can fail cleanly without followup splat?
Thanks.