From nobody Fri Sep 25 14:31:46 2026 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 847A53F822F for ; Fri, 11 Sep 2026 06:58:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789109931; cv=none; b=KZkm/E499G59w8XaoncBUBqgFgcv0fXUz6v7Go2++J51x4ZxOPiPkkC3zuLpoz+xzxED45NaPB8bgXylP8YlU6SVr+dht6f9F/MhHdpZ8A16ZjOs9dhT1KKtVHbqrPw0/AYKiwWCLlSxvrnUpEMFQYZHcchX+Y8NoOo5AroWwsc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789109931; c=relaxed/simple; bh=a605jU1pvQWqUiL7tcAWYklt0O8GbI56dhq13ru7r/8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=TEB7jS28ywibreWtq7TDQlsSnn0QebYY/aE8igq97JOydatOkSueFJCZMZAyYj1o0Yyn7/3YedLkTUoQrAvJDhh7E5pfp8WPD6DrCmjPKKTPdWVVkUGmsYdueqmUfrEX2EvL/fUqc/9WD999HeA45tqn7sRpiCSaFcPRJouKTe8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=H5ZIm9HZ; arc=none smtp.client-ip=209.85.214.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="H5ZIm9HZ" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2db3305f94fso8163445ad.0 for ; Thu, 10 Sep 2026 23:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789109924; x=1789714724; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=fJmAEC50POxoDcN++SEhq+0rid1s+953+Y3vycFEQyk=; b=H5ZIm9HZJYAwpXJDQjioWAlsQ3Y3qlgYeusOH3a3tmeAi6JA/O2d5wiOfpsEA3L/HQ jd/nxcbRZFDi5lIbWLNQ2OeBTlYPsUzzKL+Vfkwmnfy1IO4/1fGnNKm0ifLUyz0KbLqL m7AWAHko95vlyjCAvtQ7cD8JoHNKLs9U1WtwzXDfnLXYSn810SEErxT0iRLzNqJl1ekP 4xoY5CKx9Gf/DW//yo0ZFIx332UybVtHvBN+EWr6qzd/yVmDVcFDGyTyM4hoGiFUACjw Y99mqYfCylBcBKkcDfvibh3C5pGZ85wa4uq4Kd6NHpCJfpVeKPPcyh+XhAFBkyfifxHo 8PeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789109924; x=1789714724; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=fJmAEC50POxoDcN++SEhq+0rid1s+953+Y3vycFEQyk=; b=g+Ibw856FBlK1UDg0nTJmP1VkjTIqrCZgWUvKnfkqlMmK9HBXldazBdxUjYP67e3nj f2OAKjGPWSDfoBWj4fKNRLaYgFw9zb3WAZ7vNN1+QlkxGY/ksxOc2MENqcgVSU766ZXh EDr+fqfDWZcD+qa7TB92kiAXJe9pM7Szwr9ycoIajoODDDOUTdAcWShnhCslV1TxFMJL mwRMh2zUK34eO2R2MFmtsSuh+PyfDbkc2CLeS6IgiqCUBDquC0Ytq8fT1VnfquhbLQZO hgV2t9mGCos5aAdmjl0U46mkB02juHo2W/FSnPSOvo1zpoy1Nxybc5+Xm0c60grQcFuO X2WQ== X-Forwarded-Encrypted: i=1; AKwUvBxMRh/SZ5FAsm13fqLcgk5noX5NBzvNj+aryjxrLwhRHUZvgV7dARc+RM2h2ixLeNkb6wo0ajCYhC9SQUU=@vger.kernel.org X-Gm-Message-State: AFuF++k6PBkD2Pts5lddRkvTK4lZTqeRYuk3ePRXcd6Pi9S1yuEtHvqk cRoKmsEMMjnl0MEd0q7b01LYZU0Sjkiquh9me2jZRlIQfh8lJVPLDZ+N X-Gm-Gg: AYBFou2LFyz6J2HDiJb1R0jvfmynKHIqai4wvw54h2YC9zcNdzXBIKxK2jhVidy17p5 O1dHmwLhv6QdK5VKy0SSqD5gAPf5fMbc+HsmVLe0YmZBkmRmLiayFuf46VhaNH9KK4+1+p2Hqib fcwsgCjGva6oJT2RRcqbQBoA89FLMkxU7U3lEjXy6+d1oIH1OX9DPgWnDD56kNuwT6nIC/bDz2o 5XFW/xXvVwTwalVN+++zX2zNJeXHPTgSVqzFUky872u15Iypfx25sbEvQ7TuJ9PQAM4eg3GvO7A ogXfl1pSI4w9r/wc4od97FVpCigLbbq+FihA/snBPQ0JPKfgoC/n77A1IsnZPC55tLr/ims8uwu 8PRZt8FIuWcZzbAcyy+SSkXo0aljBC9DznaZ37FkH8FNpoCp+oot1fPiZ4HGWxVuFJvBedf1hlZ 1My9Q5aGUjrKaOOswCuJG1Q6T4TKVotb6Erz9R7Mt9zNuc11Oi+GfW56CLVjrt7u8sn53sEqYXU jkdbhEEey+F9pWUflBCZQdRYc/9y8rZjtfj202sUjg= X-Received: by 2002:a17:90a:e710:b0:398:d843:cad9 with SMTP id 98e67ed59e1d1-39d9c202f33mr5190127a91.19.1789109924394; Thu, 10 Sep 2026 23:58:44 -0700 (PDT) Received: from localhost.localdomain ([117.88.121.70]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-39d99531b21sm3061850a91.13.2026.09.10.23.58.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 23:58:43 -0700 (PDT) From: henrymei X-Google-Original-From: henrymei To: gregkh@linuxfoundation.org Cc: jirislaby@kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, Aohan Mei , TencentOS Corvus AI , stable@vger.kernel.org Subject: [PATCH] tty: n_gsm: keep DLCI 0 object across mux restarts Date: Fri, 11 Sep 2026 14:58:26 +0800 Message-ID: <20260911065826.3515170-1-henrymei@tencent.com> X-Mailer: git-send-email 2.43.7 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Aohan Mei gsmtty_install() takes a reference on the object occupying the gsm->dlci[0] slot, and gsmtty_cleanup() drops a reference on whatever object occupies the slot at cleanup time. The two are expected to balance on the same object, but gsm_activate_mux() breaks that: on a mux restart (GSMIOC_SETCONF with a need_restart change) it unconditionally allocates a fresh DLCI 0 into the slot, orphaning the old object which still has install-time references outstanding. When the last of those old gsmttys is closed, gsmtty_cleanup() then drops its slot reference on the *new* DLCI 0, driving its base kref from 1 to 0: gsm_dlci_free() frees it and NULLs the slot while the mux stays alive (dead =3D=3D false), and the old object is leaked. The next gsmtty open passes the dead check and dereferences the NULL slot in gsmtty_install() (dlci_get(gsm->dlci[0])), crashing the kernel. Keep the DLCI 0 object in the slot on reactivation when one is still present: it can only still be there because open gsmttys hold references on it, and gsm_dlci_free() is the only code that clears the slot and only runs at kref 0, so the slot identity can no longer change while install-time references are outstanding. Re-take the base reference that gsm_cleanup_mux() dropped via gsm_dlci_release(), clear the dead flag it set, and refresh the per-object config fields exactly like a fresh gsm_dlci_alloc() would, since the restart may carry a config change. This also restores the invariant that dead =3D=3D false implies gsm->dlci[0] !=3D NULL, making the NULL dereference structurally impossible. Fixes: 6ab8fba7fcb0 ("tty: n_gsm: Added refcount usage to gsm_mux and gsm_d= lci structs") Reported-by: TencentOS Corvus AI Cc: stable@vger.kernel.org Assisted-by: CodeBuddy:Kimi-K3 Signed-off-by: Aohan Mei --- drivers/tty/n_gsm.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c index c13e050de83b..2ca7e18addc5 100644 --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -3186,7 +3186,29 @@ static int gsm_activate_mux(struct gsm_mux *gsm) struct gsm_dlci *dlci; int ret; =20 - dlci =3D gsm_dlci_alloc(gsm, 0); + dlci =3D gsm->dlci[0]; + if (dlci) { + /* + * gsmtty_install() takes a reference on the object that + * occupies the dlci[0] slot and gsmtty_cleanup() drops a + * reference on the object occupying the slot at cleanup + * time. Replacing the object here while such references + * are still outstanding makes the cleanup reference drop + * on the wrong (new) object, freeing it prematurely, and + * leaks the old one. Keep the still-referenced object in + * the slot and re-take the base reference that + * gsm_cleanup_mux() dropped so the install and cleanup + * references always balance on the same object. + */ + dlci_get(dlci); + dlci->dead =3D false; + dlci->adaption =3D gsm->adaption; + dlci->mtu =3D gsm->mtu; + dlci->ftype =3D gsm->ftype; + dlci->k =3D gsm->k; + } else { + dlci =3D gsm_dlci_alloc(gsm, 0); + } if (dlci =3D=3D NULL) return -ENOMEM; =20 --=20 2.43.7