From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) (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 56E8017A30A for ; Sun, 15 Feb 2026 19:22:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771183336; cv=none; b=uIJxsVcl1aD4x3JArbxbGt4fZzMO2oCkbbtWkU0uGGJdggXD+EHdJlBPuP3vCKBWNRb0WNIhieR8ngxT7aEr79w+iChf4yUJAIhM2tvetFnqj/MnTZqUbkI+38+FoMQSh+3YFuwTeBz1ZZ0anF/TpiGHSm+xgLBl3e+kYJ6M5MY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771183336; c=relaxed/simple; bh=rPIaYVvi/NhaRLJdyluxXKQmCXnhOwFnZrZdjVPXSHo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=jTVtaZ/1CbnCiThHb41nI6M48IH1jYs5ni74262p/6OHHH+mNffbrwUt1URYxAB/JDn/oAccj+Clwal2Y0Dg4JKXlxQt/ICSegD4F5x7YEHocZErAmdsjOfNLl/ifpq4j4MuEN59ZdMZYTrwXdxDjjjKjJjeolDe2kT8RC+s/bU= 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=iWc3joUS; arc=none smtp.client-ip=209.85.219.51 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="iWc3joUS" Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-8954ae375efso47558286d6.1 for ; Sun, 15 Feb 2026 11:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771183334; x=1771788134; darn=vger.kernel.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=bi15ShqOTIuUPpfpFCRX8OP6IwOyBKheQ25AkLpKxYg=; b=iWc3joUS81MLBUQT7bohJawKMN67hv3CZUl7uHGkPY8ZjsSmH/sJOAkrfHlB7GpWQF wvj//z5RBkphd0942u4Xntx8rsiCi8drCIHfqc85kCne0ueMX2TbwGqw2FnoeTPlogFx vlSw7HlKHuUxkpxsDfsKJCl6LnI2Ln4dGTUlmH9fBncDLu/iB+RticoQ2VI11VhJoab9 gLlLm8Vp3Od7+7VVLqd6zzJXop1UA2ykv61e8MDTIE74uqyI+ZGPKaxAY56MmLUATdAC 0dtgUQbGUd4H2XpZMHjULpIhFv2JSgu160yXm+CgjkDW1wpgTHM7NoLa9Pi7IZ7kwyGw XBQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771183334; x=1771788134; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=bi15ShqOTIuUPpfpFCRX8OP6IwOyBKheQ25AkLpKxYg=; b=nUUpmBAo3/HtpIQbezL+hw75H9F7lwVSbxfhZERDCSirK0Y6SosvvjB9ixH/++BxdG DOpuq8s0p24MfAkuqVcY4a7HQlcqFYObYkkUNhKcvR0/zFoKjZ9jrrqmyyVlj1Vice2/ gJyQWFbMNT4ZzyTFuj6mSet/IeXpQCD/zYuQ4gufBqvkCB07E2esgb50jF42WtBX0uiF pAMUxn8GPVlZnpbR4X8QhIf+qQChjQqeRjBmjzq2cpICZDW1Lhh8V2O4ILBknvW6iblZ phJk1MAj0kAV/FHrH83ahMLq7HR5uXdNhpgaHoLTBTiTjBbYQZxcc0sAICdrt0OpwLIw oVvg== X-Forwarded-Encrypted: i=1; AJvYcCV3FyXbRfUzkBuTAl/Nr0l20aVoPsNSQp2G60LiVbSB69JUt2PA+WDYh7A9J1wYsXaZyx2eDqCV4uthRXI=@vger.kernel.org X-Gm-Message-State: AOJu0YxTfSX952Xiogb2ziJqdW7iyD/DevuqZOKCe6N3ZPbPm7ghC26G MY4QujtQLeEI/qC3B1UuHlPsuDSPzz93xMN0D6fiDqdViuqMSTjzfXiH X-Gm-Gg: AZuq6aLbxqX95gqeIQP2Z6NkbRKQf/2hYlIX1e+1O4/ZdXQwhc3PB8w3SthoLTdqZio rUwB/xovAC7VK0sBtQ2voMvnBAix9KHnPfPzpGfaFDKPmPu7ec+G9fkRfXyYw7xTfyiZ2yFTfph o56ExacDgjQWvt1CQmz+JVKTXH6TLaD0sP/Hyx52opjDgtXXdaw92Q1p33GC8LqtJwfv+pEo3VU imjAbUOGcYJ/h7DeUFf/xYtNQ7MxHiaymLcv7GnDqTOTA1I0B8JsBkSMHrw2sU1+p/37TTT1vUx VCk5PQA0qvACx2WQgRrbCPX90Uvetyv4SLI9dKoWLlWpKG5/l/NAqApPXCFYVLAn3jNGSS75tvt pDoclZxPVHIrIVkvCId2yId/UrHT2kDhAll7FlM9j6mMSL6ji4QEEUWPlhPjn+i2/KPHB3sfDzG ojK9P3yTNZa4XXt3xRKAbnzlWV0/EUrKDyX8t+APXP04fP0nyO3u782U+r5Um+Ltaz X-Received: by 2002:ad4:5d45:0:b0:896:f589:cd7 with SMTP id 6a1803df08f44-8973f276ee5mr93788006d6.6.1771183334344; Sun, 15 Feb 2026 11:22:14 -0800 (PST) Received: from smtpclient.apple ([2601:985:4601:5df0:1939:c7b0:bc30:a1f7]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8971cc95acasm117675646d6.18.2026.02.15.11.22.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Feb 2026 11:22:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\)) Subject: Re: [PATCH net v2 1/1] serial: caif: fix remaining ser->tty UAF in TX path From: Shuangpeng In-Reply-To: <20260215085510.3081-1-hdanton@sina.com> Date: Sun, 15 Feb 2026 14:22:02 -0500 Cc: netdev@vger.kernel.org, edumazet@google.com, linux-kernel@vger.kernel.org, Jiayuan Chen Content-Transfer-Encoding: quoted-printable Message-Id: <2CCEDE30-6BDF-4815-9975-40EF6C982520@gmail.com> References: <20260215085510.3081-1-hdanton@sina.com> To: Hillf Danton X-Mailer: Apple Mail (2.3864.300.41.1.7) > On Feb 15, 2026, at 03:55, Hillf Danton wrote: >=20 > On Sat, 14 Feb 2026 21:51:41 -0500 Shuangpeng Bai wrote: >> A reproducer exposes a KASAN use-after-free in caif_serial's TX path >> (e.g., via tty_write_room() / tty->ops->write()) on top of commit >> <308e7e4d0a84> ("serial: caif: fix use-after-free in caif_serial >> ldisc_close()"). >>=20 >> That commit moved tty_kref_put() to ser_release(). There is still a = race >> because the TX path may fetch ser->tty and use it while ser_release() >> drops the last tty reference: >>=20 >> CPU 0 (ser_release worker) CPU 1 (xmit) >> ------------------------- ------------ >> caif_xmit() >> handle_tx() >> tty =3D ser->tty >>=20 >> ser_release() >> tty =3D ser->tty >> dev_close(ser->dev) >> unregister_netdevice(ser->dev) >> debugfs_deinit(ser) >> tty_kref_put(tty) // may drop the last ref >> <-- race window --> >> tty->ops->write(tty, ...) // = UAF >>=20 > What is unclear is -- why is the xmit callback still active after > unregister_netdevice(). In my understanding, no new ndo_start_xmit should begin after unregister_netdevice() has completed, but an in-flight TX still needs proper synchronization with teardown. Concretely, CPU1 enters the TX path (ndo_start_xmit -> caif_xmit -> handle_tx) and reads ser->tty to use it. Before CPU1 actually uses the tty, CPU0 drops the last tty kref during teardown, so the tty may get freed. CPU1 then continues and dereferences the stale tty in tty_write_room() / tty->ops->write(), triggering the UAF. The KASAN stack trace is in the report: https://groups.google.com/g/syzkaller/c/usNe0oKtoXw/m/x8qUc3yUAQAJ Please let me know if I=E2=80=99m missing anything. Best, Shuangpeng=