CVE-2026-45866

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: caif: fix use-after-free in caif_serial ldisc_close()<br /> <br /> There is a use-after-free bug in caif_serial where handle_tx() may<br /> access ser-&gt;tty after the tty has been freed.<br /> <br /> The race condition occurs between ldisc_close() and packet transmission:<br /> <br /> CPU 0 (close) CPU 1 (xmit)<br /> ------------- ------------<br /> ldisc_close()<br /> tty_kref_put(ser-&gt;tty)<br /> [tty may be freed here]<br /> <br /> caif_xmit()<br /> handle_tx()<br /> tty = ser-&gt;tty // dangling ptr<br /> tty-&gt;ops-&gt;write() // UAF!<br /> schedule_work()<br /> ser_release()<br /> unregister_netdevice()<br /> <br /> The root cause is that tty_kref_put() is called in ldisc_close() while<br /> the network device is still active and can receive packets.<br /> <br /> Since ser and tty have a 1:1 binding relationship with consistent<br /> lifecycles (ser is allocated in ldisc_open and freed in ser_release<br /> via unregister_netdevice, and each ser binds exactly one tty), we can<br /> safely defer the tty reference release to ser_release() where the<br /> network device is unregistered.<br /> <br /> Fix this by moving tty_kref_put() from ldisc_close() to ser_release(),<br /> after unregister_netdevice(). This ensures the tty reference is held<br /> as long as the network device exists, preventing the UAF.<br /> <br /> Note: We save ser-&gt;tty before unregister_netdevice() because ser is<br /> embedded in netdev&amp;#39;s private data and will be freed along with netdev<br /> (needs_free_netdev = true).<br /> <br /> How to reproduce: Add mdelay(500) at the beginning of ldisc_close()<br /> to widen the race window, then run the reproducer program [1].<br /> <br /> Note: There is a separate deadloop issue in handle_tx() when using<br /> PORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper<br /> serial backend). This deadloop exists even without this patch,<br /> and is likely caused by inconsistency between uart_write_room() and<br /> uart_write() in serial core. It has been addressed in a separate<br /> patch [2].<br /> <br /> KASAN report:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620<br /> Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x10e/0x1f0<br /> print_report+0xd0/0x630<br /> kasan_report+0xe4/0x120<br /> handle_tx+0x5d1/0x620<br /> dev_hard_start_xmit+0x9d/0x6c0<br /> __dev_queue_xmit+0x6e2/0x4410<br /> packet_xmit+0x243/0x360<br /> packet_sendmsg+0x26cf/0x5500<br /> __sys_sendto+0x4a3/0x520<br /> __x64_sys_sendto+0xe0/0x1c0<br /> do_syscall_64+0xc9/0xf80<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f615df2c0d7<br /> <br /> Allocated by task 9930:<br /> <br /> Freed by task 64:<br /> <br /> Last potentially related work creation:<br /> <br /> The buggy address belongs to the object at ffff8881131e1000<br /> which belongs to the cache kmalloc-cg-2k of size 2048<br /> The buggy address is located 1168 bytes inside of<br /> freed 2048-byte region [ffff8881131e1000, ffff8881131e1800)<br /> <br /> The buggy address belongs to the physical page:<br /> page_owner tracks the page as allocated<br /> page last free pid 9778 tgid 9778 stack trace:<br /> <br /> Memory state around the buggy address:<br /> ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> &gt;ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ==================================================================<br /> [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb<br /> [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u