Hi,
Indeed, eventpoll_release_file() is on the 'write' side of the rcu
here (the read-side being in reverse_path_check_proc()). It's a race,
in that 'struct epitem' has to be freed by rcu before the next loop
iteration such that epi->fllink.next pointer is no longer valid. So,
I suspect that makes
On Tue, Jun 17, 2014 at 06:58:05AM +0400, Konstantin Khlebnikov wrote:
> This fixes use-after-free of epi->fllink.next inside list loop macro.
> This loop actually releases elements in the body. List is rcu-protected
> but here we cannot hold rcu_read_lock because we need to lock mutex inside.
>
>
On Tue, Jun 17, 2014 at 6:58 AM, Konstantin Khlebnikov wrote:
> This fixes use-after-free of epi->fllink.next inside list loop macro.
> This loop actually releases elements in the body. List is rcu-protected
> but here we cannot hold rcu_read_lock because we need to lock mutex inside.
>
> Obvious
This fixes use-after-free of epi->fllink.next inside list loop macro.
This loop actually releases elements in the body. List is rcu-protected
but here we cannot hold rcu_read_lock because we need to lock mutex inside.
Obvious solution is to use list_for_each_entry_safe(). RCU-ness isn't essential
4 matches
Mail list logo
