On 5/5/24 11:55 AM, Linus Torvalds wrote: > epoll can call out to vfs_poll() with a file pointer that may race with > the last 'fput()'. That would make f_count go down to zero, and while > the ep->mtx locking means that the resulting file pointer tear-down will > be blocked until the poll returns, it means that f_count is already > dead, and any use of it won't actually get a reference to the file any > more: it's dead regardless. > > Make sure we have a valid ref on the file pointer before we call down to > vfs_poll() from the epoll routines. > > Link: https://lore.kernel.org/lkml/0000000000002d631f0615918f1e@xxxxxxxxxx/ > Reported-by: syzbot+045b454ab35fd82a35fb@xxxxxxxxxxxxxxxxxxxxxxxxx > Reviewed-by: Jens Axboe <axboe@xxxxxxxxx> > Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > --- > > Changes since v1: > > - add Link, Reported-by, and Jens' reviewed-by. And sign off on it > because it looks fine to me and we have some testing now. > > - move epi_fget() closer to the user > > - more comments about the background > > - remove the rcu_read_lock(), with the comment explaining why it's not > needed > > - note about returning zero rather than something like EPOLLERR|POLLHUP > for a file that is going away I did look at that 0 return as well and agreed this is the right choice, but adding the comment is a good idea. Anyway, patch still looks fine to me. I'd word wrap the comment section above epi_fget() wider, but that's just a stylistic choice... -- Jens Axboe
