{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.170-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.85-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.18.14-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003etty 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-\u003etty)       [tty may be freed here]                      \u003c-- race window --\u003e                                       caif_xmit()                                         handle_tx()                                           tty = ser-\u003etty  // dangling ptr                                           tty-\u003eops-\u003ewrite() // 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-\u003etty 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:  \u003cTASK\u003e  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 \u003effff8881131e1480: 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",
  "id": "DEBIAN-CVE-2026-45866",
  "modified": "2026-09-14T16:47:34.932082133Z",
  "published": "2026-05-27T14:16:58.963Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-45866"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-45866"
  ]
}