All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
Cc: Jeongjun Park <aha310510@gmail.com>,
	wei.liu@kernel.org, paul@xen.org, davem@davemloft.net,
	edumazet@google.com, madhuparnabhowmik04@gmail.com,
	xen-devel@lists.xenproject.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net/xen-netback: prevent UAF in xenvif_flush_hash()
Date: Tue, 27 Aug 2024 07:14:27 -0700	[thread overview]
Message-ID: <20240827071427.4c45fdb8@kernel.org> (raw)
In-Reply-To: <fd2a06d5-370f-4e07-af84-cab089b82a4b@redhat.com>

On Tue, 27 Aug 2024 13:19:59 +0200 Paolo Abeni wrote:
> On 8/22/24 20:11, Jeongjun Park wrote:
> > During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,
> > kfree_rcu does not exist inside the rcu read critical section, so if  
> 
> The above wording is confusing, do you mean "kfree_rcu does not exit 
> from "...?

I think they mean that kfree_rcu() is called without holding RCU read
lock..

> > kfree_rcu is called when the rcu grace period ends during the iteration,
> > UAF occurs when accessing head->next after the entry becomes free.  

.. so it can run immediately. Therefore the loop fetching head->next
may cause a UAF.

> The loop runs with irq disabled, the RCU critical section extends over 
> it, uninterrupted.

Is this an official RCU rule? I remember Paul told us it's the case for
softirq, but IDK if it is also for local IRQ disable.

> Do you have a splat for the reported UAF?
> 
> This does not look the correct solution.

The problem may not exist, but FWIW the change makes sense to me :)
We hold the write lock, and modify the list. for_each_entry_safe()
seems like a better fit than for_each_entry_rcu()


  reply	other threads:[~2024-08-27 14:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-22 18:11 [PATCH net] net/xen-netback: prevent UAF in xenvif_flush_hash() Jeongjun Park
2024-08-27 11:19 ` Paolo Abeni
2024-08-27 14:14   ` Jakub Kicinski [this message]
2024-08-28 12:52   ` Jeongjun Park
2024-08-29  0:06     ` Jakub Kicinski
2024-08-29  0:20 ` patchwork-bot+netdevbpf

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=20240827071427.4c45fdb8@kernel.org \
    --to=kuba@kernel.org \
    --cc=aha310510@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=madhuparnabhowmik04@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=paul@xen.org \
    --cc=wei.liu@kernel.org \
    --cc=xen-devel@lists.xenproject.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.