On Fri, May 03, 2024 at 01:16:25PM -0700, Kees Cook wrote: > It should never happen that get_file() is called on a file with > f_count equal to zero. If this happens, a use-after-free condition > has happened[1], and we need to attempt a best-effort reporting of > the situation to help find the root cause more easily. Additionally, > this serves as a data corruption indicator that system owners using > warn_limit or panic_on_warn would like to have detected. > > Link: https://lore.kernel.org/lkml/7c41cf3c-2a71-4dbb-8f34-0337890906fc@xxxxxxxxx/ [1] > Suggested-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> > --- > Cc: Christian Brauner <brauner@xxxxxxxxxx> > Cc: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx> > Cc: Jens Axboe <axboe@xxxxxxxxx> > Cc: Jann Horn <jannh@xxxxxxxxxx> > Cc: Jan Kara <jack@xxxxxxx> > Cc: linux-fsdevel@xxxxxxxxxxxxxxx > --- > include/linux/fs.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 00fc429b0af0..fa9ea5390f33 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1038,7 +1038,8 @@ struct file_handle { > > static inline struct file *get_file(struct file *f) > { > - atomic_long_inc(&f->f_count); > + long prior = atomic_long_fetch_inc_relaxed(&f->f_count); > + WARN_ONCE(!prior, "struct file::f_count incremented from zero; use-after-free condition present!\n"); This reminds me, I should some day try and fix the horrible code-gen for WARN() :/ WARN_ON_*() and friends turn into a single trap instruction, but the WARN() and friends thing turns into a horrible piece of crap for the printk().
