From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756854AbdLOQk3 (ORCPT ); Fri, 15 Dec 2017 11:40:29 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:40430 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756697AbdLOQkY (ORCPT ); Fri, 15 Dec 2017 11:40:24 -0500 Date: Fri, 15 Dec 2017 17:40:15 +0100 (CET) From: Thomas Gleixner To: Eric Biggers cc: Dmitry Vyukov , Greg KH , Kees Cook , Alexey Dobriyan , security@kernel.org, Akinobu Mita , Andrew Morton , "Eric W. Biederman" , Josh Poimboeuf , LKML , Ingo Molnar , syzkaller-bugs@googlegroups.com, Vegard Nossum Subject: Re: general protection fault in show_timer In-Reply-To: <20171214183607.GB259981@gmail.com> Message-ID: References: <20171212083343.GG22935@kroah.com> <20171214183607.GB259981@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Dec 2017, Eric Biggers wrote: > On Thu, Dec 14, 2017 at 04:34:12PM +0100, Thomas Gleixner wrote: > > On Thu, 14 Dec 2017, Dmitry Vyukov wrote: > > > On Thu, Dec 14, 2017 at 3:26 PM, Thomas Gleixner wrote: > > > > On Tue, 12 Dec 2017, Greg KH wrote: > > > >> Did this ever go anywhere? I don't see it in Linus's tree yet... > > > > > > > > I learned yesterday that syzboz is understuffed and cannot test patches, so > > > > I need to find a minute to run the reproducer myself and verify that the > > > > patch is correct. > > > > > > Hi Thomas, > > > > > > Why do you say so? Have you tried to ask it to test? > > > https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot > > > What happened? > > > > Eric explained that to me yesterday and I did not try yet. > > > > Your patch definitely fixes the bug (I tested the C reproducers, you just need > to build a kernel with CONFIG_CHECKPOINT_RESTORE=y and CONFIG_POSIX_TIMERS=y, > then run them). The real question is whether the check being introduced is too > strict -- are there users passing in other values for ->sigev_notify that would > be broken? That I can't really answer. Me neither. The manpage is rather clear about the possible values, so I don't expect wreckage. Aside of that non canonical values would have to have bit 2, i.e. SIGEV_THREAD_ID cleared because that already has a restriction that it's only allowed with SIGEV_SIGNAL. So unlikely... If really some crap application breaks we can handle it in the default clause by setting it to SIGEV_SIGNAL. Though I rather prefer not to do that unless it turns out to be absolutely necessary. Thanks, tglx