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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190108050739.GQ12689@magnolia>
Date:   Mon, 7 Jan 2019 21:07:39 -0800
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     "Su Yanjun <suyj.fnst@...fujitsu.com>" <suyj.fnst@...fujitsu.com>
Cc:     Eric Sandeen <sandeen@...deen.net>, linux-xfs@...r.kernel.org,
        linux-kernel@...r.kernel.org, suyanjun218@...il.com
Subject: Re: [PATCH] xfs: correct statx's result_mask value

On Tue, Jan 08, 2019 at 12:58:43PM +0800, Su Yanjun <suyj.fnst@...fujitsu.com> wrote:
> 
> 
> On 1/8/2019 2:04 AM, Eric Sandeen wrote:
> > On 1/7/19 11:52 AM, Darrick J. Wong wrote:
> > > On Mon, Jan 07, 2019 at 04:53:10AM -0500, Su Yanjun wrote:
> > > > For statx syscall, xfs return the wrong result_mask.
> > > > 
> > > > Signed-off-by: Su Yanjun<suyj.fnst@...fujitsu.com>
> > > > ---
> > > >   fs/xfs/xfs_iops.c | 3 +++
> > > >   1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
> > > > index f48ffd7..3811457 100644
> > > > --- a/fs/xfs/xfs_iops.c
> > > > +++ b/fs/xfs/xfs_iops.c
> > > > @@ -521,6 +521,9 @@ xfs_vn_getattr(
> > > >   			stat->btime.tv_nsec = ip->i_d.di_crtime.t_nsec;
> > > >   		}
> > > >   	}
> > > > +	
> > > > +	/* Only return mask that we care */
> > > > +	stat->result_mask &= request_mask;
> > > Why not just:
> > > 
> > > 	stat->result_mask = STATX_BASIC_STATS;
> > > 
> > > at the top of the function?
> > > 
> > > I don't see the need to mask off result_mask at all, since we could some
> > > day elect to return more than what's in request_mask...
> When we run xfstests with nfs, the generic/423 case runs failed. So i review
> the nfs'
> nfs_getattr code it does validate the request_mask.
> 
> Then i review the xfs' getattr code, it has no such check. Whatever
> request_mask
>  is set, the stat's result_mask always the 0x7ff.

Yes, statx can return more data than what userspace callers ask for:

> Maybe it has Unclear semantics about statx's result_mask.

"A filesystem may also fill in fields that the caller didn't ask for if
it has values for them available and the information is available at no
extra cost.  If this happens, the  corresponding  bits will be set in
stx_mask."

--D

> > > ...waitaminute, are you seeing garbage in the result_mask that's
> > > returned to userspace?  I also noticed the vfs stat functions declare
> > > "struct kstat stat;" without explicitly zeroing the structure fields,
> > > which means (I think) that we can leak stack information if the kernel
> > > isn't built with the stackleak plugin?
> No such problem.
> > A clear problem statement and reproducer steps would be hugely useful
> > here.
> > 
> > -Eric
> Thanks,
> Su
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ