From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf,v2] netfilter: nf_tables: autoload modules from the abort path
Date: Thu, 23 Jan 2020 04:45:45 +0100 [thread overview]
Message-ID: <20200123034545.GS795@breakpoint.cc> (raw)
In-Reply-To: <20200122224947.iucrwyxmsrtm7ppe@salvia>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Wed, Jan 22, 2020 at 11:28:08PM +0100, Florian Westphal wrote:
> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > + list_for_each_entry(req, &net->nft.module_list, list) {
> > > + if (!strcmp(req->module, module_name) && req->done)
> > > + return 0;
> > > + }
> >
> > If the module is already on this list, why does it need to be
> > added a second time?
>
> The first time this finds no module on the list, then the module is
> added to the list and nft_request_module() returns -EAGAIN. This
> triggers abort path with autoload parameter set to true from
> nfnetlink, this sets the module done field to true.
I guess I was confused by the need for the "&& req->done" part.
AFAIU req->done is always true here.
> Now, on the second path, it will find that this already tried to load
> the module, so it does not add it again, nft_request_module() returns 0.
But the "I already tried this" is already implied by the presence of the
module name? Or did I misunderstand?
> Then, there is a look up to find the object that was missing. If
> module was successfully load, the object will be in place, otherwise
> -ENOENT is reported to userspace.
Good, that will prevent infite retries in case userspace requests
non-existent module.
> I can include this logic in the patch description in a v3.
That would be good, thanks!
> I run the syzbot reproducer for 1 hour and no problems, not sure how
> much I have to run it more. I guess the more time the better.
It triggers instantly for me provided:
1. CONFIG_MODULES=y (with MODULES=n the faulty code part isn't built...)
2. set "sysctl kernel.modprobe=/root/sleep1.sh"
I found that with normal modprobe the race window is rather small and
the thread doing the request_module has a decent chance of re-locking
the mutex before another syzkaller thread has a chance to alter the
current generation.
prev parent reply other threads:[~2020-01-23 3:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-22 21:17 [PATCH nf,v2] netfilter: nf_tables: autoload modules from the abort path Pablo Neira Ayuso
2020-01-22 22:28 ` Florian Westphal
2020-01-22 22:49 ` Pablo Neira Ayuso
2020-01-22 22:50 ` Pablo Neira Ayuso
2020-01-23 3:45 ` Florian Westphal [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200123034545.GS795@breakpoint.cc \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.