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"); return f; } -- 2.34.1
