From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C21F4746B7; Thu, 27 Aug 2026 13:33:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787837614; cv=none; b=m4ZfeMmAsW9itgXaVEMQ/ASEVjCz7UZ6SXEkaHWBIB2sA2BQXlIek53pm90O6H1qE3NRnxWvHGX3t6r8JOO16Sf8xViWWrpWXZDCp9SNff+fJu62b85ED9kz3F/80FGXRF0E1B8UPzzIJbslQ6pEYEPIKTuDVuGTEZxyVNpp1RQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787837614; c=relaxed/simple; bh=MmhRczpeait+8pej4NW6iWlfBLKfTeVw/6dAVLLtbUE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rHUkjtRs/YAxqxgZJuVpPaeyEPc6deL13XX5aFRBtqRT8dEbhG+H8ug5zw3ixzY7N+OdRkjlltxxMS5Rpl9XMuESgOmfk/VDJ2HPB5HArsL8F2UBOU3rh/e0jO93TH2aEeQPPvDnXHrMN30fICOd1PI1lKjWwVE9negjiszlfXA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JiTRj2c5; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JiTRj2c5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 548C61F000E9; Thu, 27 Aug 2026 13:33:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787837602; bh=VWLd3sU9atQfIoDce7jl0NZ8RDqno2g42DMkclW3s2E=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=JiTRj2c5TEgZDqNGP/gwA6qAeqCW2m94hZugSCyqcfvN1RfoLyTD/kiRcj2+CD/qk nU8QeIYTFRX+iBGSxhyFEthALC+BsFUMCgTn/8RGriu1mRdcyQNaDV7eh0AWTMwpaw rKeDsXzBzUqLySAvK1g4tzU9s8y0ef/HECYEZed5wslXyKduIOIxUKTYLBuRGG1Vbg kXQkv69f2iqqDLfv/ndP1jYauBgVZasQJ2/OsSXwV73AdLBriw8d0/RqD4iQn3bnBc ixFSv/cl1ow/fCzS2NDNXQe/jDegFPT7u6jfdqQBRaxOLM9ClKqs7w8xoeMFuyLqtw iIYE93xYUphLg== Received: from johan by xi.lan with local (Exim 4.99.4) (envelope-from ) id 1wzaEJ-000000031ue-2nz6; Thu, 27 Aug 2026 15:33:19 +0200 Date: Thu, 27 Aug 2026 15:33:19 +0200 From: Johan Hovold To: Greg Kroah-Hartman Cc: Luis Chamberlain , Petr Pavlu , Daniel Gomez , Sami Tolvanen , Aaron Tomlin , Jonathan Corbet , Shuah Khan , Randy Dunlap , "Rafael J. Wysocki" , Danilo Krummrich , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-usb@vger.kernel.org, driver-core@lists.linux.dev, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] driver core: add TAINT_FORCED_BIND for when userspace manually messes with devices and drivers Message-ID: References: <20260826-bind_taint-v1-0-52b05f4a965c@linuxfoundation.org> <20260826-bind_taint-v1-2-52b05f4a965c@linuxfoundation.org> Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260826-bind_taint-v1-2-52b05f4a965c@linuxfoundation.org> On Wed, Aug 26, 2026 at 11:19:33AM +0200, Greg Kroah-Hartman wrote: > The ability to add and remove devices from a driver through the sysfs > "bind" and "unbind" files was created all those decades ago as a way > that kernel developers can iterate faster, and provide a debugging way > for users to attempt to add a new device to a driver without having to > rebuild their kernel. > > This api over the years has been abused and recently come under a major > fuzzing "attack" through tools like syzbot which decided that it would > attempt to just randomly bind any driver to any type of device, causing > loads of unneeded errors and pointless kernel patches to be generated by > unsuspecting new developers. > > Handle all of this by adding a new taint flag, TAINT_FORCED_BIND, which > will be set on the driver if the bind/unbind sysfs files are ever > successfully written to. This lets kernel developers "know" that a user > is attempting to do something that is not normal, and as such, if the > kernel breaks they get to keep the shiny pieces laying around on the > floor. > > Note, the taint flag gets set _BEFORE_ the bind/unbind callback happens, > as many times crashes/oops/warnings/failures happen within the callback, > and the taint flag needs to be there to show what was being attempted. > If it were to be set after the callback happens, the oops report would > not properly reflect what foolishness was being attempted. > > Signed-off-by: Greg Kroah-Hartman This makes it clear that this is a development tool, and it is a good compromise preferable to adding unnecessary complexity or suppressing the attributes completely just to prevent root from shooting themselves in the foot: Reviewed-by: Johan Hovold Tested-by: Johan Hovold Johan