Re: [PATCH net v1] serial: caif: fix use-after-free in caif_serial ldisc_close()

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Feb 04, 2026 at 04:19:33PM +0800, Jiayuan Chen wrote:
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
> 
> There is a use-after-free bug in caif_serial where handle_tx() may
> access ser->tty after the tty has been freed.
> 
> The race condition occurs between ldisc_close() and packet transmission:
> 
>     CPU 0 (close)                     CPU 1 (xmit)
>     -------------                     ------------
>     ldisc_close()
>       tty_kref_put(ser->tty)
>       [tty may be freed here]
>                      <-- race window -->
>                                       caif_xmit()
>                                         handle_tx()
>                                           tty = ser->tty  // dangling ptr
>                                           tty->ops->write() // UAF!
>       schedule_work()
>         ser_release()
>           unregister_netdevice()
> 
> The root cause is that tty_kref_put() is called in ldisc_close() while
> the network device is still active and can receive packets.
> 
> Since ser and tty have a 1:1 binding relationship with consistent
> lifecycles (ser is created/destroyed in ldisc_open/close, and each ser
> binds exactly one tty), we can safely defer the tty reference release
> to ser_release() where the network device is unregistered.
> 
> Fix this by moving tty_kref_put() from ldisc_close() to ser_release(),
> after unregister_netdevice(). This ensures the tty reference is held
> as long as the network device exists, preventing the UAF.
> 
> Note: We save ser->tty before unregister_netdevice() because ser is
> embedded in netdev's private data and will be freed along with netdev
> (needs_free_netdev = true).
> 
> How to reproduce: Add mdelay(500) at the beginning of ldisc_close()
> to widen the race window, then run the reproducer program [1].
> 
> Note: There is a separate deadloop issue in handle_tx() when using
> PORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper
> serial backend). This deadloop exists even without this patch,
> and is caused by an independent bug: inconsistency between
> uart_write_room() and uart_write() in serial core. It has been
> addressed in a separate patch [2].
> 
> KASAN report:
> 
> ==================================================================
> BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620
> Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929
> 
> Call Trace:
>  <TASK>
>  dump_stack_lvl+0x10e/0x1f0
>  print_report+0xd0/0x630
>  kasan_report+0xe4/0x120
>  handle_tx+0x5d1/0x620
>  dev_hard_start_xmit+0x9d/0x6c0
>  __dev_queue_xmit+0x6e2/0x4410
>  packet_xmit+0x243/0x360
>  packet_sendmsg+0x26cf/0x5500
>  __sys_sendto+0x4a3/0x520
>  __x64_sys_sendto+0xe0/0x1c0
>  do_syscall_64+0xc9/0xf80
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f615df2c0d7
> 
> Allocated by task 9930:
> 
> Freed by task 64:
> 
> Last potentially related work creation:
> 
> The buggy address belongs to the object at ffff8881131e1000
>  which belongs to the cache kmalloc-cg-2k of size 2048
> The buggy address is located 1168 bytes inside of
>  freed 2048-byte region [ffff8881131e1000, ffff8881131e1800)
> 
> The buggy address belongs to the physical page:
> page_owner tracks the page as allocated
> page last free pid 9778 tgid 9778 stack trace:
> 
> Memory state around the buggy address:
>  ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>                          ^
>  ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
> [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb
> [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u
> 
> Reported-by: syzbot+827272712bd6d12c79a4@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/000000000000a4a7550611e234f5@google.com/T/
> Fixes: 9b27105b4a44 ("net-caif-driver: add CAIF serial driver (ldisc)")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
>  drivers/net/caif/caif_serial.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/caif_serial.c
> index c398ac42eae9..b90890030751 100644
> --- a/drivers/net/caif/caif_serial.c
> +++ b/drivers/net/caif/caif_serial.c
> @@ -284,6 +284,7 @@ static void ser_release(struct work_struct *work)
>  {
>  	struct list_head list;
>  	struct ser_device *ser, *tmp;
> +	struct tty_struct *tty;
>  
>  	spin_lock(&ser_lock);
>  	list_replace_init(&ser_release_list, &list);
> @@ -292,9 +293,11 @@ static void ser_release(struct work_struct *work)
>  	if (!list_empty(&list)) {
>  		rtnl_lock();
>  		list_for_each_entry_safe(ser, tmp, &list, node) {
> +			tty = ser->tty;
>  			dev_close(ser->dev);
>  			unregister_netdevice(ser->dev);
>  			debugfs_deinit(ser);
> +			tty_kref_put(tty);
>  		}
>  		rtnl_unlock();
>  	}
> @@ -355,8 +358,6 @@ static void ldisc_close(struct tty_struct *tty)
>  {
>  	struct ser_device *ser = tty->disc_data;
>  
> -	tty_kref_put(ser->tty);
> -

Good catch!

While I don't have this hardware to test, this looks sane to me.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>