Re: [PATCH] rust: file: handle fd table teardown in file descriptor APIs

[Christian Brauner <brauner@kernel.org>]

On Sun, Sep 20, 2026 at 09:48:54PM +0100, Gary Guo wrote:
> On Sun Sep 20, 2026 at 9:01 PM BST, Georgios Androutsopoulos wrote:
> > Several Rust file descriptor APIs rely on `current->files` being
> > available. However, `exit_files()` clears it while execution may still
> > continue on the same task.
> >
> > This affects `LocalFile::fget()` and the
> > `FileDescriptorReservation` operations that call
> > `get_unused_fd_flags()`, `fd_install()`, and `put_unused_fd()`.
> > `FileDescriptorReservation` cannot cross task boundaries, but remaining
> > on the same task does not guarantee that `current->files` is still
> > available when these operations are performed.
> >
> > Guard the affected operations against a missing `current->files`.
> > `LocalFile::fget()` returns `EBADF` and
> > `FileDescriptorReservation::get_unused_fd_flags()` returns `EMFILE`.
> > For the infallible `fd_install()` and drop paths, warn once and avoid
> > calling the corresponding C helper when the fd table is already gone.
> >
> > This prevents NULL dereferences through these safe Rust APIs after
> > `exit_files()`.
> 
> I suppose we could add these checks to C side instead, although perhaps one may
> say "its bad caller code and not worth checking"?

It is a bug to call fd_install() or anything like that post
exit_files(). Whatever code is doing that needs to get fixed.

Similarly it is a bug to call fd_install() on kernel thread which do not
have files at all. So whoever you're doing this for is breaching core
api assumptions big time and I would like a detailed explanation
otherwise I see no reason to merge this.