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-033789090...@gmail.com/ > [1] > Suggested-by: Peter Zijlstra <pet...@infradead.org> > Signed-off-by: Kees Cook <keesc...@chromium.org> > --- > Cc: Christian Brauner <brau...@kernel.org> > Cc: Alexander Viro <v...@zeniv.linux.org.uk> > Cc: Jens Axboe <ax...@kernel.dk> > Cc: Jann Horn <ja...@google.com> > Cc: Jan Kara <j...@suse.cz> > Cc: linux-fsde...@vger.kernel.org > --- > 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().
