From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752111AbcAFSTU (ORCPT ); Wed, 6 Jan 2016 13:19:20 -0500 Received: from kanga.kvack.org ([205.233.56.17]:44591 "EHLO kanga.kvack.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751865AbcAFSTQ (ORCPT ); Wed, 6 Jan 2016 13:19:16 -0500 X-Greylist: delayed 1034 seconds by postgrey-1.27 at vger.kernel.org; Wed, 06 Jan 2016 13:19:15 EST Date: Wed, 6 Jan 2016 13:01:58 -0500 From: Benjamin LaHaise To: Dmitry Vyukov Cc: Jan Kara , Alexander Viro , linux-aio , "linux-fsdevel@vger.kernel.org" , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Sasha Levin , Andrey Ryabinin Subject: Re: int overflow in io_getevents Message-ID: <20160106180158.GE4439@kvack.org> References: <20151216125618.GA16918@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 16, 2015 at 07:38:33PM +0100, Dmitry Vyukov wrote: > > Yup, looks correct. Will you send a patch? > > I've drafted the verification: > > @@ -1269,6 +1269,8 @@ static long read_events(struct kioctx *ctx, long > min_nr, long nr, > > if (unlikely(copy_from_user(&ts, timeout, sizeof(ts)))) > return -EFAULT; > + if (!timespec_valid_strict(&strict)) > + return -EINVAL; > > until = timespec_to_ktime(ts); > } > > But now I am thinking whether it is the right solution. > First, user does not know about KTIME_MAX, so it is not unreasonable > to pass timespec{INT64_MAX, INT64_MAX} as timeout expecting that it > will block for a long time. And it actually probably mostly works now, > because after the overflow you still get something large with high > probability. If we do the fix, then users will need to pass seconds < > KTIME_MAX, while they don't know KTIME_MAX value. > Second, there seems to be more serious issue in ktime_set() which > checks seconds for KTIME_MAX, but on the next line addition still > overflows int64. > Thoughts? I finally had some time to look over this after the holidays, and I don't think using timespec_valid_strict() is the right approach here, as userspace will have no idea what KTIME_MAX is. Instead, I think the right approach is to -EINVAL for negative values (which should avoid the overflow), and to allow too large values to be silently truncated by timespec_to_ktime(). The truncation doesn't matter all that much given that it's in the hundreds of years ballpark. I'll push the patch below if there are no objections. -ben -- "Thought is the essence of where you are now." commit 4304367826d0df42086ef24428c6c277acd822a9 Author: Benjamin LaHaise Date: Wed Jan 6 12:46:12 2016 -0500 aio: handle integer overflow in io_getevents() timespec usage Dmitry Vyukov reported an integer overflow in io_getevents() when running a fuzzer. Upon investigation, the triggers appears to be that a negative value for the tv_sec or tv_nsec was passed in which is not handled by timespec_to_ktime(). This patch fixes that by making io_getevents() return -EINVAL when negative timeouts are passed in. Signed-off-by: Benjamin LaHaise diff --git a/fs/aio.c b/fs/aio.c index 155f842..f325ed4 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -1269,6 +1269,8 @@ static long read_events(struct kioctx *ctx, long min_nr, long nr, if (unlikely(copy_from_user(&ts, timeout, sizeof(ts)))) return -EFAULT; + if ((ts.tv_sec < 0) || (ts.tv_nsec < 0)) + return -EINVAL; until = timespec_to_ktime(ts); }