On Tue, Jul 24, 2018 at 06:17:26AM +0100, Al Viro wrote:
> Do we have LOOKUP_RCU in nd->flags at that point? And how in hell
> did we get that dentry there? In LOOKUP_RCU mode no freeing should
> be happening until after we call rcu_read_unlock(), unless the final
> dput() has happened before rc
Because our fuzzer has a problem, I don't have a C reproducer so far.
I reported the crash becasue I saw the crash repeatedly in our fuzzer and I
hoped the report is helpful. But it seems not enough.
If I was wrong and I made you confused, I am really sorry for that.
Could you give me a second?
I
On Tue, Jul 24, 2018 at 06:17:26AM +0100, Al Viro wrote:
> On Tue, Jul 24, 2018 at 12:45:42PM +0900, Dae R. Jeong wrote:
> > Diagnosis:
> > We think that it is possible that link_path_walk() dereferences a
> > freed pointer when cleanup_mnt() is executed between path_init() and
> > link_path_walk()
On Tue, Jul 24, 2018 at 12:45:42PM +0900, Dae R. Jeong wrote:
> Diagnosis:
> We think that it is possible that link_path_walk() dereferences a
> freed pointer when cleanup_mnt() is executed between path_init() and
> link_path_walk().
>
> Since I'm not an expert on a file system and don't fully und
I think that below two crashes are also related to the same race issue.
KASAN: use-after-free Read in nd_jump_root, found in v4.17-rc1
KASAN: use-after-free in set_root, found in v4.18-rc3
==
BUG: KASAN: use-after-free in nd_jump_ro
5 matches
Mail list logo
