linux-kernel - Re: [PATCH] sunrpc: Fix incorrect parsing of expiry time

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: <CAMKO5Cv1Uh1rSFQ0cR1kfA88iXXHP5RMO-euU15Xrn2i93J5rg@mail.gmail.com>
Date:   Tue, 7 Mar 2023 14:52:53 -0800
From:   Jerry Zhang <jerry@...dio.com>
To:     NeilBrown <neilb@...e.de>
Cc:     embedded@...dio.com, Chuck Lever <chuck.lever@...cle.com>,
        Jeff Layton <jlayton@...nel.org>,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        Anna Schumaker <anna@...nel.org>,
        "J. Bruce Fields" <bfields@...hat.com>, linux-nfs@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sunrpc: Fix incorrect parsing of expiry time

On Tue, Mar 7, 2023 at 2:31 PM NeilBrown <neilb@...e.de> wrote:
>
> On Wed, 08 Mar 2023, Jerry Zhang wrote:
> > The expiry time field is mean to be expressed in seconds since boot.
>
> Correct.
>
> > The get_expiry() function parses a relative time value in seconds.
>
> Incorrect.  It parses and absoulte wall-clock time.
I'm not familiar with the source of truth for this info. Is there a
specification of some sort?

For reference, we were seeing writes to
/proc/net/rpc/nfsd.export/channel randomly fail with EINVAL despite
usually succeeding with the same invocation. Upon investigation this
was the string that exportfs was writing "-test-client- /path/to/mount
 3 0 65534 65534 0". "3" was the value for expiry in this message,
which led me to conclude that this is a relative field. If it isn't,
perhaps this is a bug in userspace nfs tools?

The failure in this was if nfs-server starts exactly 3s after bootup,
boot.tv_sec would be 3 and thus get_expiry() returns 0, causing a
failure to be returned.
>
> NeilBrown
>
> > In order to get the absolute time of seconds since boot that the given
> > message will expire, the right thing is to add seconds_since_boot()
> > to the given relative value.
> >
> > Previously this logic was subtracting boot.tv_sec from the relative
> > value, which was causing some confusing behavior. The return type of
> > time64_t could possibly underflow if time since boot is greater than
> > the passed in relative argument. Also several checks in nfs code compare
> > the return value to 0 to indicate failure, and this could spuriously
> > be tripped if seconds since boot happened to match the argument.
> >
> > Fixes: c5b29f885afe ("sunrpc: use seconds since boot in expiry cache")
> > Signed-off-by: Jerry Zhang <Jerry@...dio.com>
> > ---
> >  include/linux/sunrpc/cache.h | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/include/linux/sunrpc/cache.h b/include/linux/sunrpc/cache.h
> > index ec5a555df96f..b96b1319c93d 100644
> > --- a/include/linux/sunrpc/cache.h
> > +++ b/include/linux/sunrpc/cache.h
> > @@ -301,16 +301,14 @@ static inline int get_time(char **bpp, time64_t *time)
> >  }
> >
> >  static inline time64_t get_expiry(char **bpp)
> >  {
> >       time64_t rv;
> > -     struct timespec64 boot;
> >
> >       if (get_time(bpp, &rv))
> >               return 0;
> >       if (rv < 0)
> >               return 0;
> > -     getboottime64(&boot);
> > -     return rv - boot.tv_sec;
> > +     return rv + seconds_since_boot();
> >  }
> >
> >  #endif /*  _LINUX_SUNRPC_CACHE_H_ */
> > --
> > 2.37.3
> >
> >
>