PT-2026-43733 · Linux · Linux
Published
2026-05-27
·
Updated
2026-05-27
·
CVE-2026-45866
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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:
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
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux