[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [driver-core:debugfs_cleanup 4/5] fs/d_path.c:59 prepend() warn: unsigned 'p->len' is never less
From:       Al Viro <viro () zeniv ! linux ! org ! uk>
Date:       2021-12-31 19:35:07
Message-ID: Yc9ba7ur1iVhaJd5 () zeniv-ca ! linux ! org ! uk
[Download RAW message or body]

On Sat, Jan 01, 2022 at 01:08:41AM +0800, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git \
>                 debugfs_cleanup
> head:   a04bbe0a2c7e98669e11a47f94e53dd8228bbeba
> commit: e95d5bed5d58c2f5352969369827e7135fa2261e [4/5] fs: make d_path-like \
>                 functions all have unsigned size
> config: i386-randconfig-m031-20211228 \
> (https://download.01.org/0day-ci/archive/20220101/202201010156.bJvO7Gaw-lkp@intel.com/config)
>                 
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
> 
> smatch warnings:
> fs/d_path.c:59 prepend() warn: unsigned 'p->len' is never less than zero.

What do you mean, "unsigned p->len"?

->len really *can* be negative - that's how running out of buffer is indicated.

Greg, I stand by the comment I made back in July - this kind of "hardening" is
useless; there's no legitimate reason to pass a huge buffer length, especially
since there's a limit on the length of pathname any syscall would accept.
See https://www.spinics.net/lists/linux-fsdevel/msg200370.html for the
variant I would prefer.


[prev in list] [next in list] [prev in thread] [next in thread]