On Mon, 2021-04-19 at 16:36 +0000, Kurt Manucredo wrote: > Fix shift-out-of-bounds in xprt_calc_majortimeo(). > > UBSAN: shift-out-of-bounds in net/sunrpc/xprt.c:658:14 > shift exponent 536871232 is too large for 64-bit type 'long u > > Reported-by: syzbot+ba2e91df8f74809417fa@xxxxxxxxxxxxxxxxxxxxxxxxx > Signed-off-by: Kurt Manucredo <fuzzybritches0@xxxxxxxxx> > --- > net/sunrpc/xprt.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c > index 691ccf8049a4..07128ac3d51d 100644 > --- a/net/sunrpc/xprt.c > +++ b/net/sunrpc/xprt.c > @@ -655,7 +655,10 @@ static unsigned long xprt_calc_majortimeo(struct > rpc_rqst *req) > unsigned long majortimeo = req->rq_timeout; > > if (to->to_exponential) > - majortimeo <<= to->to_retries; > + if (to->to_retries >= sizeof(majortimeo) * 8) > + majortimeo = to->to_maxval; > + else > + majortimeo <<= to->to_retries; > else > majortimeo += to->to_increment * to->to_retries; > if (majortimeo > to->to_maxval || majortimeo == 0) I've already stated on the mailing list that I'm not accepting any changes to xprt_calc_majortimeo() for this problem. There is a fix to the NFS mount code that addresses this bounds issue, and that commit is already being tested in linux-next. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
