From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailgw.kylinos.cn (mailgw.kylinos.cn [124.126.103.232]) (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 9DD7028373 for ; Wed, 1 Jul 2026 02:01:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=124.126.103.232 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782871283; cv=none; b=lh7a2JAZlYmq4OoGDnPUvUQijPb7PlNuLMUpNLANGMvGYLdeQ+SPPdBd/H/i7JpZdl+vvMy1I8QTnjE2IWT7PUjOgx6XjvLoFkQGcevia5Ie/QkxUfYC+cBHqROresdMAXvzJnv39HOad8BCgZIQ3q28vsC9UUQRGJWwVJb8eRU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782871283; c=relaxed/simple; bh=s3RsY73OfkyZlfM+nOxpy0uUV5+gRaqAThhVI6YTQTs=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=Ug8Xr0N9Wy7kNSCl5XWx/ThiVCGSpHq1Cot9e+7tkpsxtv6ZC8HtfZhEuqUWCTjRN8UE/g6pw2LPKJJQbzICf8qRO+Lde3YeRjm9jLiVYNxzsnmxbM9j6HjMM9Obq1emUfOUbu5hYtyzXtWc5hYHpxrt+NeOgSpCm2CHKWFXclY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylinos.cn; spf=pass smtp.mailfrom=kylinos.cn; arc=none smtp.client-ip=124.126.103.232 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylinos.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kylinos.cn X-UUID: bd38d16274f011f1aa26b74ffac11d73-20260701 X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.3.12,REQID:646b2437-a9af-4584-a331-dac0e7714fd6,IP:0,U RL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION: release,TS:0 X-CID-META: VersionHash:e7bac3a,CLOUDID:3e8a1c864bacd0ff8733641aa6a6e6f8,BulkI D:nil,BulkQuantity:0,Recheck:0,SF:102|850|865|898,TC:nil,Content:0|15|50,E DM:-3,IP:nil,URL:99|1,File:nil,RT:nil,Bulk:nil,QS:nil,BEC:nil,COL:0,OSI:0, OSA:0,AV:0,LES:1,SPR:NO,DKR:0,DKP:0,BRR:0,BRE:0,ARC:0 X-CID-BVR: 2,SSN|SDN X-CID-BAS: 2,SSN|SDN,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR,TF_CID_SPAM_ULS X-CID-RHF: D41D8CD98F00B204E9800998ECF8427E X-UUID: bd38d16274f011f1aa26b74ffac11d73-20260701 X-User: xiaopei01@kylinos.cn Received: from localhost.localdomain [(10.44.16.150)] by mailgw.kylinos.cn (envelope-from ) (Generic MTA with TLSv1.3 TLS_AES_256_GCM_SHA384 256/256) with ESMTP id 922366620; Wed, 01 Jul 2026 10:01:14 +0800 From: Pei Xiao To: vaibhavgupta40@gmail.com, jens.taprogge@taprogge.org, gregkh@linuxfoundation.org, kees@kernel.org, industrypack-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Cc: Pei Xiao , Shuangpeng Bai Subject: [PATCH 0/2] ipack: ipoctal: fix races and UAFs during module removal Date: Wed, 1 Jul 2026 10:01:08 +0800 Message-Id: X-Mailer: git-send-email 2.25.1 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-Transfer-Encoding: 8bit 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: 1. UAF of struct ipoctal: the remove callback freed ipoctal via kfree() while in-flight tty ops could still be accessing it. 2. NULL dereference in ipoctal_write_tty(): __ipoctal_remove() freed xmit_buf while a concurrent write() could still dereference it. 3. UAF in ipoctal_cleanup(): ipack_put_carrier(ipoctal->dev) walked through ipoctal->dev to reach the carrier module, but the ipack_device could have already been freed by then. 4. Page faults due to devm_ioremap() regions being unmapped while tty ops still access hardware registers. 5. TOCTOU race between the removed-flag check and the subsequent hardware access in each tty op. Patch 1 introduces kref-based lifetime management, caches the carrier owner module pointer to avoid chasing a dangling dev->bus pointer, adds a "removed" flag with checks in all tty ops that touch hardware, and adds a NULL guard on xmit_buf in the write path. Patch 2 adds a read-write semaphore (remove_sem) to close the TOCTOU window: the tty ops hold the read lock for the duration of the hardware access, while __ipoctal_remove() acquires the write lock when setting the removed flag, ensuring that once removed is true no in-flight tty op is still inside a critical section. Reported-by: Shuangpeng Bai Link: https://lore.kernel.org/lkml/178144969601.60470.1257088106279546587@gmail.com/ Pei Xiao (2): ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup on remove ipack: ipoctal: add rwsem to guard against TOCTOU in remove path drivers/ipack/devices/ipoctal.c | 60 ++++++++++++++++++++++++++++++--- 1 file changed, 56 insertions(+), 4 deletions(-) -- 2.25.1