From: Florian Westphal <fw@strlen.de>
To: <netfilter-devel@vger.kernel.org>
Subject: [PATCH nf-next 0/4] netfilter: nf_queue: rework refcount handling
Date: Fri, 27 Mar 2020 03:24:45 +0100 [thread overview]
Message-ID: <20200327022449.7411-1-fw@strlen.de> (raw)
running nft_queue.sh selftest with refcount debugging
enabled triggers following splat:
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 0 PID: 2441 at lib/refcount.c:25 refcount_warn_saturate+0xbc/0x110
RIP: 0010:refcount_warn_saturate+0xbc/0x110
[..]
Call Trace:
nf_queue_entry_get_refs+0x194/0x1b0
nf_queue+0x38b/0x640
nf_reinject+0x264/0x280
nfqnl_recv_verdict+0x5d5/0x920
nfnetlink_rcv_msg+0x27a/0x460
This is because nf_queue uses following pattern:
nf_queue_entry_get_refs()
nf_queue() // leave rcu protection
// nfnetlink, wait for verdict
// sk might be closed now
nf_reinject // reenter rcu protection
nf_queue_entry_release_refs // refcount can drop to 0
// iterate/call remaining hooks and okfn
If the hook iteration results in another nf_queue() call, above splat
might be triggered.
This series fixes this by deferring the call to
nf_queue_entry_release_refs() until after the hook iteration/okfn
returns; i.e. another nf_queue invocation from nf_reinject path will
not observe a zero refcount.
This series also applies to nf, but given we're a bit further along in
release cycle nf-next might be better; this fix isn't simple,
unfortunately.
next reply other threads:[~2020-03-27 2:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-27 2:24 Florian Westphal [this message]
2020-03-27 2:24 ` [PATCH nf-next 1/4] netfilter: nf_queue: make nf_queue_entry_release_refs static Florian Westphal
2020-03-27 2:24 ` [PATCH nf-next 2/4] netfilter: nf_queue: place bridge physports into queue_entry struct Florian Westphal
2020-03-27 2:24 ` [PATCH nf-next 3/4] netfilter: nf_queue: do not release refcouts until nf_reinject is done Florian Westphal
2020-03-27 2:24 ` [PATCH nf-next 4/4] netfilter: nf_queue: prefer nf_queue_entry_free Florian Westphal
2020-03-29 15:07 ` [PATCH nf-next 0/4] netfilter: nf_queue: rework refcount handling Pablo Neira Ayuso
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=20200327022449.7411-1-fw@strlen.de \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).