Netdev List
 help / color / mirror / Atom feed
From: Aaron Conole <aconole@redhat.com>
To: andrew@lunn.ch
Cc: Yuan Tan <yuantan098@gmail.com>, Ren Wei <enjou1224z@gmail.com>,
	xuyuqiabc@gmail.com, netdev@vger.kernel.org, dev@openvswitch.org,
	echaudro@redhat.com, i.maximets@ovn.org, davem@davemloft.net,
	edumazet@google.com, pabeni@redhat.com, horms@kernel.org,
	pshelar@ovn.org, yihung.wei@gmail.com, tonanli66@gmail.com
Subject: Re: [PATCH net 1/1] openvswitch: Fix CT limit teardown use-after-free
Date: Mon, 20 Jul 2026 15:29:59 -0400	[thread overview]
Message-ID: <f7tmrvla288.fsf@redhat.com> (raw)
In-Reply-To: <c9a39c7f-cdad-4e8d-b516-b727806525a0@lunn.ch>

Andrew Lunn <andrew@lunn.ch> writes:

> On Sun, Jul 19, 2026 at 11:54:31PM -0700, Yuan Tan wrote:
> > 
> > On 7/19/26 19:52, Andrew Lunn wrote:
> > > On Mon, Jul 20, 2026 at 10:14:16AM +0800, Ren Wei wrote:
> > >> From: Yuqi Xu <xuyuqiabc@gmail.com>
> > >>
> > >> Packet processing uses CT limit state under RCU, while netns teardown
> > >> frees that state under ovs_mutex. The CT limit pointer was neither removed
> > >> from readers nor protected by a grace period, allowing packet processing to
> > >> dereference the freed state.
> > >>
> > >> Replace the pointer before freeing the CT limit state. Wait for in-flight
> > >> RCU readers before freeing its contents. Serialize CT limit netlink
> > >> operations with teardown for the full lifetime of their state accesses.
> > >>
> > >> Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
> > >> Cc: stable@vger.kernel.org
> > >> Reported-by: Vega <vega@nebusec.ai>
> > > Is Vega a person?
> > 
> > Hi Andrew,
> > 
> > Thank you very much for your review!
> > For context, we had previously understood that using the tool name in
> > the Reported-by tag was acceptable, based on examples such as
> > Reported-by: AutonomousCodeSecurity@microsoft.com and Reported-by:
> > Anthropic.
> > 
> > https://lore.kernel.org/all/20260630171016.11c02dec@kernel.org/
> 
> https://docs.kernel.org/process/submitting-patches.html
> 
>   The Reported-by tag gives credit to people who find bugs and report
>   them and it hopefully inspires them to help us again in the
>   future. The tag is intended for bugs; please do not use it to credit
>   feature requests. The tag should be followed by a Closes: tag
>   pointing to the report, unless the report is not available on the
>   web.
> 
> If you believe this is out of date, please submit a patch with new
> text to this document.

It is common practice to accept syzbot reports as well, which look like:

    Reported-by: syzbot+36256deb69a588e9290e@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=36256deb69a588e9290e

(see commit 539dfcf69105d8d3d4d677b71de6e5ede2e6dfa0 for example).

> I find it valuable being a person. It indicate somebody is bothered by
> the problem you are fixing. We see a lot theoretical bug fixes, which
> in practice nobody ever hit. I would prefer to spend my time reviewing
> real issues, not theoretical issues, and the Reported-by: is a quick
> indicator of this.

+1

In the case of syzbot reports, they are real actionable reports that we
can look at and address (and I agree with your sentiment of wanting to
focus on real issues).  They include the 'Closes:' tag as well, and a
reviewer can just visit the link and see the splat.  If there is a
report link that this Vega tool pushes, maybe that would be acceptable
since it's the way syzbot works as well.  It also makes sense to update
the documentation to reflect how it is used currently.

As for the v2, it would help my review to include some kind of
reproducer description - I usually try to experience OVS splats for
myself.


      reply	other threads:[~2026-07-20 19:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1784355642.git.xuyuqiabc@gmail.com>
2026-07-20  2:14 ` [PATCH net 1/1] openvswitch: Fix CT limit teardown use-after-free Ren Wei
2026-07-20  2:52   ` Andrew Lunn
2026-07-20  6:54     ` Yuan Tan
2026-07-20 13:29       ` Andrew Lunn
2026-07-20 19:29         ` Aaron Conole [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=f7tmrvla288.fsf@redhat.com \
    --to=aconole@redhat.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=dev@openvswitch.org \
    --cc=echaudro@redhat.com \
    --cc=edumazet@google.com \
    --cc=enjou1224z@gmail.com \
    --cc=horms@kernel.org \
    --cc=i.maximets@ovn.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pshelar@ovn.org \
    --cc=tonanli66@gmail.com \
    --cc=xuyuqiabc@gmail.com \
    --cc=yihung.wei@gmail.com \
    --cc=yuantan098@gmail.com \
    /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