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 3305831E84B for ; Tue, 16 Jun 2026 02:47:05 +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=1781578026; cv=none; b=VDPouOn9wm/I8+NHtZZO3imUk1uMWduYZGJt5W/1vxnYf01an8X2StbQowOp2mvjfIyPUfcoAdY5/5pPdBMd1m6Wb8qP0vzn8L77hrTzHNM9VWbQgnRJECX2ZIuPzvQf2W5rS11O+v1pn4m7Fu01T80ZoTuP1S0IDYlIR7X+klI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781578026; c=relaxed/simple; bh=yH0uER8SdRqCYBXx2FdmXuoNAcKAYQaC5a3XpqDQjiM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oPS0f7zvcCk+/4E9gEBaytVmS3ZZutqnc5e2Oe7/BeE74gpJY4CzSsR1hzMityfjCn7xjyHRe/1B5mnN+2Xc8Tm1fObEDaZ9kv7wY4yaeRxjbiqMyNAOhDU6zYRhOnJGnzg2citjMn2hEiOFs78XjbnN+BJIYpnBOUEpFbkgMJU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=MzhLgXX3; 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="MzhLgXX3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23D541F000E9; Tue, 16 Jun 2026 02:47:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1781578025; bh=erGNSoO4KiD1ab+JIUB0YQYKUnhb92Ltx25lwwJgzpw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=MzhLgXX3XowUK9qR8OEZjwg87ugTVtevlpNeakllujEtaBoXVs9TEufboxMIzrJ/b 0fUFV1xY1RSOI1Muda5zT+Upfsdv8O0cSIrI0lwjNsRrklyKVamj2d87ToUdDuuJiy VL1QIzFu6VshGLJRWTUM0VcXTIqpkJqjyRXoGE2I= Date: Tue, 16 Jun 2026 08:16:00 +0530 From: Greg KH To: Shuangpeng Cc: vaibhavgupta40@gmail.com, jens.taprogge@taprogge.org, kees@kernel.org, industrypack-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [BUG] KASAN: slab-use-after-free in ipoctal_write_tty Message-ID: <2026061658-expert-chimp-f49c@gregkh> References: <178144969601.60470.1257088106279546587@gmail.com> <2026061553-childcare-rush-8f26@gregkh> <53780D3D-9EE8-4032-BC37-F17694C4D685@gmail.com> <2026061543-require-phrasing-e2c2@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=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Jun 15, 2026 at 08:11:49PM -0400, Shuangpeng wrote: > > > > On Jun 15, 2026, at 16:49, Greg KH wrote: > > > > On Mon, Jun 15, 2026 at 04:33:09PM -0400, Shuangpeng wrote: > >> > >> > >>> On Jun 15, 2026, at 00:03, Greg KH wrote: > >>> > >>> On Sun, Jun 14, 2026 at 03:48:50PM -0400, Shuangpeng Bai wrote: > >>>> Hi Kernel Maintainers, > >>>> > >>>> I hit the following report while testing current upstream kernel: > >>>> > >>>> KASAN: slab-use-after-free in ipoctal_write_tty > >>> > >>> Cool, do you have this hardware, or is this only virtual testing? > >> > >> No, I do not have the physical hardware. This was reproduced with > >> unmodified QEMU using its existing TPCI200/IP-Octal emulation. > >> > >>> > >>> If virtual, are you sure that the hardware is being emulated properly? > >> > >> > >> I understand this is not the same as testing on real hardware. However, > >> my current understanding is that the crash is triggered after a > >> successful probe through the normal sysfs unbind/remove path while the > >> ipoctal tty fd is still open. The failing path does not seem to rely on > >> device-specific emulation details after probe, but rather on the > >> lifetime of the tty/device state during removal. > > > > What specific sysfs unbind path? That's only for root and for testing > > kernel development, it's not a normal thing that a user does at all, > > right? > > > > The sysfs path used by the reproducer is: > > /sys/bus/pci/drivers/tpci200/unbind > > So yes, this is a root-only kernel testing/development path, not a > normal unprivileged user path. > > >> Please let me know if I am missing anything here. I would also > >> appreciate any suggestions on what I could check to better evaluate > >> whether the emulation is appropriate for this report. > > > > What exactly are you trying to test? > > I was trying to test whether the driver handles open ipoctal tty file > descriptors safely when the backing TPCI200/IPack device is removed. As you found, it doesn't :) See the discussions about device unbind and misc/char device nodes on the mailing lists for many messages about this and potential ways to resolve it. As it's not a real issue for drivers like this, it's a very low priority for other people to resolve, but we will always gladly review patches from others. thanks, greg k-h