From: Greg KH <gregkh@linuxfoundation.org>
To: Florian Westphal <fw@strlen.de>
Cc: Jaeyeong Lee <iostreampy@proton.me>,
netfilter-devel@vger.kernel.org, pablo@netfilter.org,
phil@nwl.cc
Subject: Re: [PATCH nf] netfilter: nf_nat: do not reuse an unexpected expectation on RTCP clash
Date: Sun, 12 Jul 2026 10:20:31 +0200 [thread overview]
Message-ID: <2026071210-grid-runaround-4318@gregkh> (raw)
In-Reply-To: <alNLcE1qJ5fwBO0N@strlen.de>
On Sun, Jul 12, 2026 at 10:08:16AM +0200, Florian Westphal wrote:
> Greg KH <gregkh@linuxfoundation.org> wrote:
> > > This is no different than the WARNs on list corruption or refcount
> > > under/overflows.
> >
> > True, but adding new ones is not a good idea, and removing the existing
> > ones is a good idea.
>
> We're fucked, then. Can we at least use DEBUG_NET_WARN or something
> like that so at least fizzers can give us hints about bugs?!
That's up to you. If panic_on_warn wasn't an option, about half of the
kernel CVEs would disappear tomorrow.
> > > Would you propose to remove those? I hope not, they help catch bugs.
> >
> > Bugs that userspace can trigger? If so, then properly catch them by
> > testing and handling the issue.
>
> Aka "Don't write buggy code". Should have thought of that.
No, I'm not saying that, I'm saying that if this is something that could
possibly happen, then let's catch that with a real check.
> > If userspace can never trigger it, then
> > it's not really needed as the code is never going to trigger.
>
> It causes memory corruption and evidently triggers.
>
> With "silently catch error" and no WARN there will be rare,
> intermittent connectivity issues.
>
> We are NOT in a syscall, there is no process to return
> a meaningful error code to.
It's up to you, if you really want WARN_ON(), that's fine, but realize
that if it can be triggered, it will require a round of fixing as it can
take down systems.
thanks,
greg k-h
next prev parent reply other threads:[~2026-07-12 8:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 23:19 netfilter: nf_nat_sip expectation UAF permits local privilege escalation Jaeyeong Lee
2026-07-11 5:29 ` Greg KH
2026-07-11 14:21 ` [PATCH nf] netfilter: nf_nat: do not reuse an unexpected expectation on RTCP clash Jaeyeong Lee
2026-07-11 16:29 ` Florian Westphal
2026-07-12 5:54 ` Greg KH
2026-07-12 7:40 ` Florian Westphal
2026-07-12 7:54 ` Greg KH
2026-07-12 8:08 ` Florian Westphal
2026-07-12 8:20 ` Greg KH [this message]
2026-07-12 8:40 ` panic_on_warn and lack of lesser-WARN (was: Re: [PATCH nf] netfilter: nf_nat: do not reuse an unexpected expectation on RTCP clash) Florian Westphal
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=2026071210-grid-runaround-4318@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=fw@strlen.de \
--cc=iostreampy@proton.me \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
/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.