CVE-2026-45866: serial: caif: fix use-after-free in caif_serial ldisc_close()

CVE-2026-45866: serial: caif: fix use-after-free in caif_serial ldisc_close()

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

serial: caif: fix use-after-free in caif_serial ldisc_close()

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 allocated in ldisc_open and freed in ser_release
via unregister_netdevice, 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 likely caused by 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

The Linux kernel CVE team has assigned CVE-2026-45866 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 3.11 with commit 56e0ef527b184b3de2d7f88c6190812b2b2ac6bf and fixed in 5.10.252 with commit 5e266ba8d330d3b8e5bc198f238cd8901826cfa1
	Issue introduced in 3.11 with commit 56e0ef527b184b3de2d7f88c6190812b2b2ac6bf and fixed in 5.15.202 with commit d3c75db4e0460641dbcd274b40867e252d801da1
	Issue introduced in 3.11 with commit 56e0ef527b184b3de2d7f88c6190812b2b2ac6bf and fixed in 6.1.165 with commit 4e63d6f68544ae5269ac9735ae5b69b59b5b8725
	Issue introduced in 3.11 with commit 56e0ef527b184b3de2d7f88c6190812b2b2ac6bf and fixed in 6.6.128 with commit 331e2b7051635780edea248dd08ae2026c126f4a
	Issue introduced in 3.11 with commit 56e0ef527b184b3de2d7f88c6190812b2b2ac6bf and fixed in 6.12.75 with commit 52731ef4438155cea782fac74e547a327ab9e7c5
	Issue introduced in 3.11 with commit 56e0ef527b184b3de2d7f88c6190812b2b2ac6bf and fixed in 6.18.14 with commit c8c197aaa56b25a2d54f3aa07e27e228d6c08546
	Issue introduced in 3.11 with commit 56e0ef527b184b3de2d7f88c6190812b2b2ac6bf and fixed in 6.19.4 with commit 40962f2bf8cdba63af23aec95ad3f49b689e58e2
	Issue introduced in 3.11 with commit 56e0ef527b184b3de2d7f88c6190812b2b2ac6bf and fixed in 7.0 with commit 308e7e4d0a846359685f40aade023aee7b27284c

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-45866
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/net/caif/caif_serial.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/5e266ba8d330d3b8e5bc198f238cd8901826cfa1
	https://git.kernel.org/stable/c/d3c75db4e0460641dbcd274b40867e252d801da1
	https://git.kernel.org/stable/c/4e63d6f68544ae5269ac9735ae5b69b59b5b8725
	https://git.kernel.org/stable/c/331e2b7051635780edea248dd08ae2026c126f4a
	https://git.kernel.org/stable/c/52731ef4438155cea782fac74e547a327ab9e7c5
	https://git.kernel.org/stable/c/c8c197aaa56b25a2d54f3aa07e27e228d6c08546
	https://git.kernel.org/stable/c/40962f2bf8cdba63af23aec95ad3f49b689e58e2
	https://git.kernel.org/stable/c/308e7e4d0a846359685f40aade023aee7b27284c