Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp147343imw; Thu, 7 Jul 2022 23:35:35 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sHKYabmoRoTaWdJt6TlhlgwbO0JdcchssBp4GXYybl9aGAJEclBLfWZqQJ+CR9q4IXLnvY X-Received: by 2002:aa7:d30b:0:b0:43a:4bea:75c6 with SMTP id p11-20020aa7d30b000000b0043a4bea75c6mr2662346edq.12.1657262134964; Thu, 07 Jul 2022 23:35:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657262134; cv=none; d=google.com; s=arc-20160816; b=BZTLOAf2KAN3hCxh9oedCSZjQtS6r0ieR1ZSfG1RE0uKEoa7BPhLbWjjDNVX/Fav2z 4sIYdcJUuQ4hgE1L9nGrLO7bhnNMijCBJTu6SJQlt8SaW1O/3eYWnaFB9OzWF2oNoVHA DNkXG+u2fuSc94w+pbG33sw5RWwXDBL8wmcaRMC8KbtvhLBrEBCwo0C2Ta9EHh6APbwy uwl/S/cNbZqb31rJZMeWjA2soc6K3rrX7AvqeoGyhyeWm6pLZC0qLdXapOorSf0CZcR2 VK+Xlqml7QUiQQUFfJbkpwjaUpdzGn6NKCmZaJBrr4egBLdJhT4T1UpU6ENhnMW3aSFO oIGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=yDcFqeczHGyZYd7T238OgZvCCK1eXFIoTBdYc3SeZos=; b=i99QPw7zkvqCZDPXcWS36t86TqswUP4lT5Ye9mSlG42FSuQNCkqg12ibVZmVa08TL8 MNsfA1AcyPh7kap4oAUFIFfUts3bBZb3iR2e+H3ZuqJ7hPgfGselzzoTrbouCFQweXSK xWPQm+Ct8G9Q07xhu5xlFaVXE5zAJfD96zZqdxPmYQnRZ+J1E3N2xBpZ0CtHGpHMV3aw TJdUPSqbocEWsH3Uao8w78jQD9vUJlW7k3zjmuMnuJXEXuNZKU8GksvzD9knsFqXYfHl gV0z7XxXzhRDDmJgB9RWN0GlaluX4FoFYf+Tc4TkEBnzGTcGeyzcRlAs6+X+AGt9THcO S/Og== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=DittmnZP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sa27-20020a1709076d1b00b00726aff09ffbsi5047619ejc.933.2022.07.07.23.35.07; Thu, 07 Jul 2022 23:35:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=DittmnZP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237126AbiGHGGs (ORCPT + 99 others); Fri, 8 Jul 2022 02:06:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237037AbiGHGGq (ORCPT ); Fri, 8 Jul 2022 02:06:46 -0400 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DCB624F17 for ; Thu, 7 Jul 2022 23:06:44 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id t19so34033319lfl.5 for ; Thu, 07 Jul 2022 23:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yDcFqeczHGyZYd7T238OgZvCCK1eXFIoTBdYc3SeZos=; b=DittmnZPcRT+xjFr0ed9UvAlzAFmVKUPNDmbhL2Xp88Abar5gi3sxJN4MHIPC8oBri +kAmgOZX95RtjJD6AcqYQIdiw1XHTh3e5knHYqmil56Av1TN6O4cOoQHvI26Iyc73Y90 VJBKK8nB8ovQ5ZPoeO8+A2MTtM0qgCutPIz/D/nBnhMmFMfLU3Aw4DMieUBq6JwHLUOy g6M/acHahuel+dFTIQAKAhLLEpbugR5KCP5VNdLxC5iWqB8rrqL6iUPylXYrxlv2YBvT x5CYJWIQvNFNAzsixoH8VJDl+lngq0VfCvAM5PPFxoJaqEVzI3CkI6fd049rvjlAjxDL Iapw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yDcFqeczHGyZYd7T238OgZvCCK1eXFIoTBdYc3SeZos=; b=YXL5KzNrEqMVZEoCut6ll3mE9yUUrwgAi7K97eozntGTYR1QtVuRqKurcXDGAsknJY ryFdG3Oe7jg+NnoEMsRIEttggENyA6+3HOq8d49HOLnHiFwGwgErAc5lAlmPqmYUIl4X yyMZ4XsS8xzuYYGx9vfOVwFAkSKBBPaM+PhhPFfwc0kqXfEFN9QwR1pDGgrWWL7kKahL aglV9QTXp0kb4y/YPDRMsWdScf922WVhQgJ5Mlz35v7CSBVBm2J3DRHVBODiIg/hvsQB klj0et4VdPgYdwa6dxjMkJ5dxGT2SgeaGuPrnaxV/e5pi6yDQsUqMGckkNGwNxmqRQty fD0g== X-Gm-Message-State: AJIora8Cv62h7iuDZ6jVUxMa8+9RYHqT54i3ckoMPnnqiXy51kGOdvnG 2fAV7etccRxwXFKwy9z9IGK1hKnGN68usrshS4ZzNA== X-Received: by 2002:a05:6512:114b:b0:482:c057:60b3 with SMTP id m11-20020a056512114b00b00482c05760b3mr1284786lfg.206.1657260402433; Thu, 07 Jul 2022 23:06:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dmitry Vyukov Date: Fri, 8 Jul 2022 08:06:30 +0200 Message-ID: Subject: Re: [PATCH] char: misc: make misc_open() and misc_register() killable To: Greg Kroah-Hartman Cc: Tetsuo Handa , syzkaller , Aleksandr Nogikh , "Rafael J. Wysocki" , Len Brown , Pavel Machek , Arnd Bergmann , LKML , linux-pm@vger.kernel.org, Wedson Almeida Filho Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 Jul 2022 at 12:10, Greg Kroah-Hartman wrote: > > On Tue, Jul 05, 2022 at 09:20:24AM +0200, Dmitry Vyukov wrote: > > On Tue, 5 Jul 2022 at 07:54, Tetsuo Handa > > wrote: > > > On Tue, Jul 05, 2022 at 02:21:17PM +0900, Tetsuo Handa wrote: > > > > On 2022/07/04 23:31, Greg KH wrote: > > > > > I don't understand what you are trying to "fix" here. What is userspace > > > > > doing (as a normal user) that is causing a problem, and what problem is > > > > > it causing and for what device/hardware/driver is this a problem? > > > > > > > > Currently the root cause is unknown. > > > > This might be another example of deadlock hidden by device_initialize(). > > > > > > > > We can see from https://syzkaller.appspot.com/text?tag=CrashReport&x=11feb7e0080000 that > > > > when khungtaskd reports that a process is blocked waiting for misc_mtx at misc_open(), > > > > there is a process which is holding system_transition_mutex from snapshot_open(). > > > > > > /dev/snapshot is not read/writable by anyone but root for obvious > > > reasons. > > > > > > And perhaps it's something that syzbot shouldn't be fuzzing unless it > > > wants to take the system down easily :) > > > > We could turn CONFIG_HIBERNATION_SNAPSHOT_DEV off for syzbot, but it > > will also mean this part of the kernel won't be tested at all. > > I see it has 14 ioclt's (below) and not all of them look problematic > > (like POWER_OFF). > > Perhaps the kernel could restrict access only to reboot/restore > > functionality? This way we could at least test everything related to > > snapshot creation. > > This is already restricted to root, why would you want to restrict it > anymore? Root like the wrong criteria here. Root protection is for global machine state and in some cases closing unreliable code. It's not about if this code should be randomly tested or not. In fact, unreliable code (bpf, filesystems) is exactly the code that needs to be tested as much as possible. But it is restricted with root as well. Though, I noticed syzkaller already avoids SNAPSHOT_FREEZE and SNAPSHOT_POWER_OFF: https://github.com/google/syzkaller/blob/bff65f44b47bd73f56c3d6a5c3899de5f5775136/sys/linux/init.go#L310-L315 This should work fine (unless the IOCTL const values don't collide with any other IOCTL const values, otherwise these duplicate values won't be tested as well). > > #define SNAPSHOT_FREEZE _IO(SNAPSHOT_IOC_MAGIC, 1) > > #define SNAPSHOT_UNFREEZE _IO(SNAPSHOT_IOC_MAGIC, 2) > > #define SNAPSHOT_ATOMIC_RESTORE _IO(SNAPSHOT_IOC_MAGIC, 4) > > #define SNAPSHOT_FREE _IO(SNAPSHOT_IOC_MAGIC, 5) > > #define SNAPSHOT_FREE_SWAP_PAGES _IO(SNAPSHOT_IOC_MAGIC, 9) > > #define SNAPSHOT_S2RAM _IO(SNAPSHOT_IOC_MAGIC, 11) > > #define SNAPSHOT_SET_SWAP_AREA _IOW(SNAPSHOT_IOC_MAGIC, 13, struct > > resume_swap_area) > > #define SNAPSHOT_GET_IMAGE_SIZE _IOR(SNAPSHOT_IOC_MAGIC, 14, __kernel_loff_t) > > #define SNAPSHOT_PLATFORM_SUPPORT _IO(SNAPSHOT_IOC_MAGIC, 15) > > #define SNAPSHOT_POWER_OFF _IO(SNAPSHOT_IOC_MAGIC, 16) > > #define SNAPSHOT_CREATE_IMAGE _IOW(SNAPSHOT_IOC_MAGIC, 17, int) > > #define SNAPSHOT_PREF_IMAGE_SIZE _IO(SNAPSHOT_IOC_MAGIC, 18) > > #define SNAPSHOT_AVAIL_SWAP_SIZE _IOR(SNAPSHOT_IOC_MAGIC, 19, __kernel_loff_t) > > #define SNAPSHOT_ALLOC_SWAP_PAGE _IOR(SNAPSHOT_IOC_MAGIC, 20, __kernel_loff_t) > > Fuzzing this is always nice, but be very aware of the system state > changes that you are creating. Also know when you make these state > changes, the rest of the system's functionality also changes. > > thanks, > > greg k-h