netdev - Re: [PATCH nf] netfilter: nf_reject: init skb->dev for reset packet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZmCwlbF8BvLGNgRM@calendula>
Date: Wed, 5 Jun 2024 20:38:13 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Christoph Paasch <cpaasch@...le.com>
Cc: Florian Westphal <fw@...len.de>,
	Netfilter <netfilter-devel@...r.kernel.org>,
	Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
	daniel@...earbox.net
Subject: Re: [PATCH nf] netfilter: nf_reject: init skb->dev for reset packet

On Wed, Jun 05, 2024 at 08:14:50PM +0200, Florian Westphal wrote:
> Christoph Paasch <cpaasch@...le.com> wrote:
> > > Reported-by: Christoph Paasch <cpaasch@...le.com>
> > > Suggested-by: Paolo Abeni <pabeni@...hat.com>
> > > Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/494
> > > Signed-off-by: Florian Westphal <fw@...len.de>
> >
> > I just gave this one a shot in my syzkaller instances and am still hitting the issue.
>
> No, different bug, this patch is correct.
>
> I refuse to touch the flow dissector.

I see callers of ip_local_out() in the tree which do not set skb->dev.

I don't understand this:

bool __skb_flow_dissect(const struct net *net,
                        const struct sk_buff *skb,
                        struct flow_dissector *flow_dissector,
                        void *target_container, const void *data,
                        __be16 proto, int nhoff, int hlen, unsigned int flags)
{
[...]
        WARN_ON_ONCE(!net);
        if (net) {

it was added by 9b52e3f267a6 ("flow_dissector: handle no-skb use case")

Is this WARN_ON_ONCE() bogus?