linux-kernel - Re: [driver-core:debugfs_cleanup 4/5] fs/d_path.c:59 prepend() warn: unsigned 'p->len' is never less than zero.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sat, 1 Jan 2022 18:40:38 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     kernel test robot <lkp@...el.com>, devel@...verdev.osuosl.org,
        kbuild-all@...ts.01.org, linux-kernel@...r.kernel.org
Subject: Re: [driver-core:debugfs_cleanup 4/5] fs/d_path.c:59 prepend() warn:
 unsigned 'p->len' is never less than zero.

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@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@...el.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.
> 
> 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.