Skip to content

Commit 86e8705

Browse files
committed
eventpoll: move epi_fget() up
We'll need it when removing files so move it up. No functional change. Link: https://patch.msgid.link/20260423-work-epoll-uaf-v1-5-2470f9eec0f5@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
1 parent 0bade23 commit 86e8705

1 file changed

Lines changed: 28 additions & 28 deletions

File tree

fs/eventpoll.c

Lines changed: 28 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -826,6 +826,34 @@ static void ep_free(struct eventpoll *ep)
826826
kfree_rcu(ep, rcu);
827827
}
828828

829+
/*
830+
* The ffd.file pointer may be in the process of being torn down due to
831+
* being closed, but we may not have finished eventpoll_release() yet.
832+
*
833+
* Normally, even with the atomic_long_inc_not_zero, the file may have
834+
* been free'd and then gotten re-allocated to something else (since
835+
* files are not RCU-delayed, they are SLAB_TYPESAFE_BY_RCU).
836+
*
837+
* But for epoll, users hold the ep->mtx mutex, and as such any file in
838+
* the process of being free'd will block in eventpoll_release_file()
839+
* and thus the underlying file allocation will not be free'd, and the
840+
* file re-use cannot happen.
841+
*
842+
* For the same reason we can avoid a rcu_read_lock() around the
843+
* operation - 'ffd.file' cannot go away even if the refcount has
844+
* reached zero (but we must still not call out to ->poll() functions
845+
* etc).
846+
*/
847+
static struct file *epi_fget(const struct epitem *epi)
848+
{
849+
struct file *file;
850+
851+
file = epi->ffd.file;
852+
if (!file_ref_get(&file->f_ref))
853+
file = NULL;
854+
return file;
855+
}
856+
829857
/*
830858
* Called with &file->f_lock held,
831859
* returns with it released
@@ -1018,34 +1046,6 @@ static __poll_t __ep_eventpoll_poll(struct file *file, poll_table *wait, int dep
10181046
return res;
10191047
}
10201048

1021-
/*
1022-
* The ffd.file pointer may be in the process of being torn down due to
1023-
* being closed, but we may not have finished eventpoll_release() yet.
1024-
*
1025-
* Normally, even with the atomic_long_inc_not_zero, the file may have
1026-
* been free'd and then gotten re-allocated to something else (since
1027-
* files are not RCU-delayed, they are SLAB_TYPESAFE_BY_RCU).
1028-
*
1029-
* But for epoll, users hold the ep->mtx mutex, and as such any file in
1030-
* the process of being free'd will block in eventpoll_release_file()
1031-
* and thus the underlying file allocation will not be free'd, and the
1032-
* file re-use cannot happen.
1033-
*
1034-
* For the same reason we can avoid a rcu_read_lock() around the
1035-
* operation - 'ffd.file' cannot go away even if the refcount has
1036-
* reached zero (but we must still not call out to ->poll() functions
1037-
* etc).
1038-
*/
1039-
static struct file *epi_fget(const struct epitem *epi)
1040-
{
1041-
struct file *file;
1042-
1043-
file = epi->ffd.file;
1044-
if (!file_ref_get(&file->f_ref))
1045-
file = NULL;
1046-
return file;
1047-
}
1048-
10491049
/*
10501050
* Differs from ep_eventpoll_poll() in that internal callers already have
10511051
* the ep->mtx so we need to start from depth=1, such that mutex_lock_nested()

0 commit comments

Comments
 (0)