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 BEA5E3F86EE for ; Wed, 1 Jul 2026 10:37:39 +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=1782902260; cv=none; b=Stt8/AtJMkj0BfnagUZET+uAT+21jYwut4W/t/skuduEmLQEAfxc6F9srH38imimBXr9c5PIRi/QwyfcEJPjx/SVk9iO9vltD3VpWIkfCmJwdPvtFOOWwAQHWVHp1O0YKfZulVYpHqTJGkRkjbQDBiY4vhGL44VTBuVL2peIy34= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782902260; c=relaxed/simple; bh=DXOxTDr/g9MPUaci9lNcdHYlk57AbDLL3TjGh4pvPMk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tSGasJgBPDASOL0C8KYRhxs8WOa2zbU5qW5cIst9pcybPjQQB9h+sgQGOtlZLvwjZNbruTyd0t761rFKqtooLpuS2HznoVIcC8idH9ZqcPuBQqEAZyYoNxISw6/m14VCEaGEpdHjpo6EMV2nJaWOtO7rN3pHlMiUCziUI42ATvM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ZM1x9yJJ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ZM1x9yJJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE6001F000E9; Wed, 1 Jul 2026 10:37:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1782902259; bh=f6aL+J7wcdRDjGGTJ3ryrlimU2h7Telr5JeoLnSwaqY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ZM1x9yJJA2TfjoXyfy75BuVtaozKAdk5zy62CFu7KcRB15SH2EPiBcQ8sPXNv9Apf ulRL1bI4O7/VANTYlkRJlQrIrBOV77klZ0DK6E9ANEHtuBTmHIE4weV70XDi07eW4G xBfTgNLHbOzMpo1DTSX2zojK/Z/Y24Gy20w0LMS0= Date: Wed, 1 Jul 2026 12:37:36 +0200 From: Greg KH To: Pei Xiao Cc: vaibhavgupta40@gmail.com, jens.taprogge@taprogge.org, kees@kernel.org, industrypack-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Shuangpeng Bai Subject: Re: [PATCH 0/2] ipack: ipoctal: fix races and UAFs during module removal Message-ID: <2026070103-lustrous-reimburse-0eb2@gregkh> References: <2026070152-recycled-outcast-3060@gregkh> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Jul 01, 2026 at 02:16:50PM +0800, Pei Xiao wrote: > > > 在 2026/7/1 13:41, Greg KH 写道: > > On Wed, Jul 01, 2026 at 10:01:08AM +0800, Pei Xiao wrote: > >> When the ipoctal device is removed while a userspace process still > >> holds a tty fd open, several races and use-after-free bugs can be > >> triggered. This series addresses the following issues: > > Cool, but why remove the module at all? > 1. Carrier hot-unplug: the IPack carrier (e.g., TPCI-200) is a PCI >    device.  When the carrier is physically removed or the PCI device >    is unbound via sysfs, ipack_bus_unregister() calls >    ipack_device_del() on every mezzanine device, which invokes >    ipoctal_remove().  This happens regardless of whether userspace >    still holds a tty fd open -- the carrier is gone, so the devices >    must go too.  The ipack_get_carrier()/try_module_get() in >    ipoctal_install() only prevents rmmod of the carrier module, not >    physical removal. Yes, but does anyone actually remove the module or unbind it or remove it physically in a real system? This is very very old hardware, removing it while active is not something that the hardware is designed to support, so why do we need to support it in the kernel? Do you have this hardware? > 2. Syzkaller/syzbot-style fuzzing: the original report from >    Shuangpeng Bai  exercises exactly these paths.  Even without >    real hardware, syzkaller can trigger the races by binding and >    unbinding drivers. Sure, but remember bind/unbind is a DEBUG TOOL! And it is controlled by root, so it is a "best effort" thing that is there for kernel developers to use for working on their code. No real customer runs that code path (and if they do, they are an admin and can do much worse things to the system if they wanted to.) > So while rmmod of ipoctal itself is blocked by the tty layer (via > drv->owner), the remove callback can and will be called through > carrier removal or driver unbind.  The crashes are real. But not a real use case ;) > > And do you have this hardware to test with? > I don't have the hardware.  However: > > - The fixes are structural and follow well-established kernel >   patterns: kref for lifetime management, rwsem for TOCTOU races, >   and caching a module pointer to avoid chasing a freed bus pointer. >   These are the same idioms used across the tty layer and other >   subsystems. > > The original reporter (Shuangpeng, CC'd) has tested this crash passed. With real hardware? Ideally we could just remove the driver as I doubt anyone uses it anymore. You can't even buy the device. thanks, greg k-h