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/[email protected]/ > [1] > Suggested-by: Peter Zijlstra <[email protected]> > Signed-off-by: Kees Cook <[email protected]> > --- > Cc: Christian Brauner <[email protected]> > Cc: Alexander Viro <[email protected]> > Cc: Jens Axboe <[email protected]> > Cc: Jann Horn <[email protected]> > Cc: Jan Kara <[email protected]> > Cc: [email protected] > --- > 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().
