From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40042C61D85 for ; Thu, 23 Nov 2023 09:44:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235039AbjKWJn4 (ORCPT ); Thu, 23 Nov 2023 04:43:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234566AbjKWJnd (ORCPT ); Thu, 23 Nov 2023 04:43:33 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1DFC2107 for ; Thu, 23 Nov 2023 01:41:54 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A0F2C433C7; Thu, 23 Nov 2023 09:41:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1700732513; bh=L1HU47elgDtXBHr6aW6J+6GyoSBIGTHAwEytneSgsx4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bIl4xvQN+8xZnm3sHyWuYtjeO5nCx8uM1ub3wg70cVOGJVP1CGBUJSfg1gnvjONj1 9WN+0sTeXcG/s4qPNSqbumcS2xHPuoskC/UzjA/CpMK3qma0L7bcbtAvkUkVSDN8VP m1HF4OB4zJpI2sF95dj7+XIGrCkXKDB2ZHAEf3Do= Date: Thu, 23 Nov 2023 09:41:49 +0000 From: "gregkh@linuxfoundation.org" To: Aleksandr Nogikh Cc: xingwei lee , "syzbot+786b124fe4ce4dc99357@syzkaller.appspotmail.com" , "linux-kernel@vger.kernel.org" , "rafael@kernel.org" , "syzkaller-bugs@googlegroups.com" , Dmitry Vyukov Subject: Re: [syzbot] [kernel?] general protection fault in joydev_connect Message-ID: <2023112306-diner-jawline-c7dc@gregkh> References: <2023112332-award-fanciness-2bcf@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 23, 2023 at 10:32:26AM +0100, Aleksandr Nogikh wrote: > On Thu, Nov 23, 2023 at 9:55 AM gregkh@linuxfoundation.org > wrote: > > > > On Wed, Nov 22, 2023 at 07:55:50PM +0800, xingwei lee wrote: > > > Hi. I have reproduced this bug with repro.txt and repro.c below: > > > > > > repro.txt > > > r0 = openat$uinput(0xffffffffffffff9c, &(0x7f0000000500), 0x802, 0x0) > > > ioctl$UI_DEV_SETUP(r0, 0x405c5503, &(0x7f0000000080)={{0x0, 0xffff, > > > 0x3}, 'syz0\x00'}) > > > ioctl$UI_DEV_CREATE(r0, 0x5501) (fail_nth: 51) > > > > You are using fault injection, which, by it's very name, causes faults :) > > But those injected failures (that do not break the kernel, but just > emulate an error returned from a function that should be expected to > sometimes return an error) still should not lead to general protection > fault panics, shouldn't they? It all depends on what exactly the fault is happening for. Some allocations in the kernel just "will not fail ever" so when you add fault injection testing, you are doing things that really can not ever happen. So the proof is first on the reporter, prove that this type of fault _can_ actually happen, and then, make a fix to properly handle it. Don't expect us to make a fix for something that can not actually occur, as that would be pointless (hint, we have been down this path before, it doesn't work...) thanks, greg k-h