On Sat, Jan 01, 2022 at 02:08:54PM +0100, Greg Kroah-Hartman wrote: > On Fri, Dec 31, 2021 at 07:35:07PM +0000, Al Viro wrote: > > 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@xxxxxxxxx/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@xxxxxxxxx> > > > > > > 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. > > Sorry, yes, I agree with you, but never deleted this commit from this > "scratch" branch of mine. I'll go rebase the branch and purge it from > the system so that 0-day doesn't hit it anymore, sorry for the noise. OK... I'll probably throw something along the lines of "negative => EINVAL, positive greater than 32Kb - adjust the buffer and length to the last 32Kb of what had been passed" into the misc queue. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
