From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (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 BE1DF329E6C for ; Thu, 19 Feb 2026 21:47:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771537665; cv=none; b=lWKBH691L6fujLVVifaEdRuZGPwrMQgvmyP1bqbWqhmW1SwZZLnTzUb9d+itySILyIFihZazEkTFAi2XV+juPD2b0NpH+xF36+FmNPzG7w0cXgECMeu+sSI1MgLswYxZCNXi1Re0VuUi0V9pmn/B/Y/bSRjeebRjA2C4wBylfR8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771537665; c=relaxed/simple; bh=hI/HB47KJY0BxEspPFN6Pc/qn4qAqWa84rV9wMoXVK4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=BiYJLqhsGBWOLtPbWeLQ1ZnILnlNj0zAqjbkasgk7H1M6qHcuyKrofrh31MR6soilTpK6tV2K+THF0u/6/e0qHRu9Mo8hLe/3RbIVX7jiCGhX1rlFkKnim0zVFwo1jYb6teVD1T0LBFdk1lvnnNMrARK1k4jCdg5AK21GniCWAA= 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=ET68yUaT; arc=none smtp.client-ip=209.85.219.46 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="ET68yUaT" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-89545bd3324so16787536d6.1 for ; Thu, 19 Feb 2026 13:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771537662; x=1772142462; 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=XqS+BeGnJuxOwDv6sYFOeLw7hL+AMH9ZPpuLvHVhUkQ=; b=ET68yUaTdmbGqcWjDLkaSsacos6wSAStBU9r9AhEu4hN3B8hDyh+7k3YBf43I3i5g6 xd0dmAdO9Akr2egskwQ3O+3QeWXZMqKZgPK0DZntm9pi6G/KGdqB0HvmDc85wJuZTJ8J aumsyCHcQ2B/DhjWuUHunQ8ATPcuPBum0hdNIKDex9vmJUzW853o4WjFzM3t3EgD/Lx1 5yUjH+zfdnc4iwJMUsWIoQ1yp82qGnaPHjERmWoHERuSqZGN8Ccro2nFd+5//JsbmoPz vzFIPP8gvgAW/3OML3mgmYnMJqNsgE+27DL0rBzmA8xAA3b6sSuD5Pv3/JDC7Q2Wp3D+ g9Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771537662; x=1772142462; 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=XqS+BeGnJuxOwDv6sYFOeLw7hL+AMH9ZPpuLvHVhUkQ=; b=lwAru/RmvNaQj0HI1+FAf6VlEH9t3jk1TKjYoGRVOY4su7O/zl7ge62mUfGkeifl4F dBVd/eUX4a3HI2DuUZKpKTtJgtxcEoEo3CctOiCmateB7/D8IY6IvklO+MeNIBDrsN4V RVFsrM8dPuwTChtbW5alZHnJRSbMqdLWTNP43CRkM9nHkuxvegnAXaB9s0GnQsb5ULtL TCp3a8iBQEjKD1vo1xCRyhTupVWkxOxHXiku/AddlV5Bh3zzg2o92aPmZbbYbpcaJwV3 S78N6BW1gEh0BQ1nKrI014+aQaW2r9PVyfPaG1vsvtBapq/lmeARfHNCHINq7X/DN3n1 Hseg== X-Forwarded-Encrypted: i=1; AJvYcCWTw3N3yjLHzzaRvVSFb13EIIGEs0lLFPhda0h8N7cOdlsxzGfV7f1igoqyBIjUXgKFRMqV3aWABKXEiog=@vger.kernel.org X-Gm-Message-State: AOJu0Yx6f463h3E45pRdyhIPVNyUxSGL3z6GwetrAWSElkMV/ZkizISk GPtfd6Q1UekFQvTRU9glhMCMzpyrzitRzwI8kAR3PtIiGwj980sZFZ24 X-Gm-Gg: AZuq6aJvRZv2X3ATDzLbJl3LpjgENexN1kOnTrquXH5Dp2SrqShgcbQFLTQBgY5KgWM 78/ukQpp9D6jGnfsnbTLq4hVO2ZywEfkSgi28P+tNEZIHv/Wkf6D0HKlNf7iFk0+CLimrxw9t6m 0PoE6bN4hT3H/3gPchA+mcnzLQ33/9CTkxnhbb2YcmmH3A/jNL3pAHou8OQxNWiuqaSuSW0FcM/ tPioNCwx3glZ1IIEflSf+tNLlaEqp4KTu4iDOXUk5Ifn4AdQkficOxx0pT/nl207m5aspCz/Iyn 96nMZCLNxC7sy3Y7D02Z5eHZFCS8KSsja0Z2Dg1FLXKDlajqVbYpsmYih1rTeyLNjigB6B2fU2S 6moudNnVA97OPqbw/+xC+ESZWwv4Bm26+UV+EwEjVB4JYY53QEWM3nQRLcYBj5XRmL6FkfOWyko hKni/LuXV4a+QxN1a8FfTZAagRC7YpMugn1DZyOTlVM/aMzGm9ktMKF1WVOrZvxiVA X-Received: by 2002:a05:6214:b6a:b0:895:bcc0:2e1a with SMTP id 6a1803df08f44-8996204f3e1mr63110106d6.37.1771537662503; Thu, 19 Feb 2026 13:47:42 -0800 (PST) Received: from smtpclient.apple ([104.39.198.53]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8971cdd1541sm228186556d6.49.2026.02.19.13.47.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Feb 2026 13:47:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii 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: <3c9706a3-92c6-414e-ad60-4bc29c5d621d@linux.dev> Date: Thu, 19 Feb 2026 16:47:31 -0500 Cc: pabeni@redhat.com, andrew+netdev@lunn.ch, hdanton@sina.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, linux-kernel@vger.kernel.org, Vadim Fedorenko Content-Transfer-Encoding: quoted-printable Message-Id: References: <20260215025141.1106576-1-shuangpeng.kernel@gmail.com> <20260215025141.1106576-2-shuangpeng.kernel@gmail.com> <3c9706a3-92c6-414e-ad60-4bc29c5d621d@linux.dev> To: netdev@vger.kernel.org X-Mailer: Apple Mail (2.3864.300.41.1.7) Hi all, Thanks for the previous feedback and suggestions. We explored several mitigations to address the remaining UAF in the caif_serial TX path, including: 1. Taking a tty reference in handle_tx() using a new tty_kref_get_unless_zero() helper. 2. Setting and checking ser->state to avoid internal races. However, our reproducer still triggers a UAF. Link: = https://gist.github.com/shuangpengbai/c898debad6bdf170a84be7e6b3d8707f After further debugging, the KASAN report consistently points to the memory access in pty_write_room(): tty_buffer_space_avail(tty->link->port); Two different tty objects are dereferenced here: 'tty' and 'tty->link'. In debugging, we found the invalid access is specifically on = 'tty->link', rather than 'tty' itself, based on comparing the runtime addresses. Therefore, our previous analysis for the race could be inaccurate. We will continue investigating the root cause and we are happy to=20 provide any additional information for you to debug this bug. Below is the report showing the fault location: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BUG: KASAN: slab-use-after-free in pty_write_room = (drivers/tty/pty.c:131) Read of size 8 at addr ffff888116df7018 by task a.out/8414 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) pty_write_room (drivers/tty/pty.c:131) handle_tx (drivers/net/caif/caif_serial.c:213) dev_hard_start_xmit (./include/linux/netdevice.h:5275=20 ./include/linux/netdevice.h:5284 net/core/dev.c:3871 = net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:?) transmit (net/caif/caif_dev.c:237) cfserl_transmit (net/caif/cfserl.c:185) cffrml_transmit (net/caif/cffrml.c:?) cfmuxl_transmit (net/caif/cfmuxl.c:240) caif_connect_client (net/caif/cfcnfg.c:355) caif_connect (net/caif/caif_socket.c:828) __sys_connect (net/socket.c:2089 net/socket.c:2108) __x64_sys_connect (net/socket.c:2114 net/socket.c:2111) do_syscall_64 (arch/x86/entry/syscall_64.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Freed by task 4526: kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:587) __kasan_slab_free (mm/kasan/common.c:287) kfree (mm/slub.c:6082 mm/slub.c:6399) process_scheduled_works (kernel/workqueue.c:3280 = kernel/workqueue.c:3358) worker_thread (./include/linux/list.h:381 kernel/workqueue.c:3440) kthread (kernel/kthread.c:468) ret_from_fork (arch/x86/kernel/process.c:164) > On Feb 18, 2026, at 09:25, Vadim Fedorenko = wrote: >=20 > On 15/02/2026 02:51, 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()"). >> 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: >> CPU 0 (ser_release worker) CPU 1 (xmit) >> ------------------------- ------------ >> caif_xmit() >> handle_tx() >> tty =3D ser->tty >> 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 >> Fix it by serializing accesses to ser->tty with a dedicated lock. The = TX >> path grabs a tty kref under the lock and drops it after the TX = attempt, >> while ser_release() clears ser->tty under the same lock before = putting the >> old tty reference. This prevents the TX path from observing a freed = tty >> object via ser->tty. >> With this change applied, the reproducer no longer triggers the UAF = in my >> test. >> One concern is that handle_tx() can be a hot path. This fix adds a = short >> lock-held section plus an extra tty kref get/put per TX run. Feedback = on >> the performance impact, or suggestions for a lower-overhead approach, = are >> welcome. >=20 > I'm not quite sure we actually need spinlock here. It looks like just = adding simple helper tty_kref_get_unless_zero() and using it in = handle_xt() will solve the problem? >=20 >=20