CVE-2026-45866

What it actually does

CVE-2026-45866 is a Linux kernel use-after-free race in the CAIF serial line discipline close path. The vulnerable code releases the tty reference in ldisc_close() while the associated CAIF network device can still transmit packets; a concurrent transmit path can then dereference ser->tty after the tty object has been freed and call tty->ops->write() through a dangling pointer. Because this occurs in kernel context, successful exploitation can cause kernel memory corruption and may allow a local low-privileged attacker to crash the system or potentially escalate privileges, depending on kernel configuration, hardening, and exploit reliability.

Why it matters to the business

Systems running affected Linux kernels with CAIF serial support exposed to local users or workloads may be vulnerable to local denial of service and possible privilege escalation. The operational risk is highest on shared Linux hosts, multi-user systems, developer workstations, CI runners, virtualization hosts, embedded Linux devices, and environments where untrusted local code can access tty devices or create packet transmissions against the CAIF interface. The vulnerability is not listed in CISA KEV, has low EPSS, and has no reported public exploit maturity in the supplied data, but the CVSS impact is high because exploitation occurs inside the kernel and can compromise host integrity and availability.

How an attack unfolds

An attacker first obtains local code execution with low privileges on a vulnerable Linux system. They then trigger creation of a CAIF serial line discipline binding to a tty and cause packet transmission through the associated CAIF network device. By racing closure of the line discipline against packet transmission, the close path can drop the tty reference while the network device remains active. During the race window, the transmit path reads the stale ser->tty pointer and invokes the tty write operation on freed memory. In the simplest case this produces a kernel crash; with sufficient control over timing, heap layout, and kernel mitigations, the same primitive may be shaped into kernel memory corruption for privilege escalation.

How to fix it

Apply a vendor-supplied kernel update containing the CAIF serial lifecycle fix that moves tty_kref_put() out of ldisc_close() and into ser_release() after unregister_netdevice(). Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, cloud image provider, or embedded device vendor. Reboot into the updated kernel after installation; merely installing kernel packages is not sufficient if the running kernel remains vulnerable. If immediate patching is not possible, reduce exposure by disabling or preventing loading of unused CAIF-related kernel support where operationally safe, restricting access to tty devices, limiting local shell/container access for untrusted users, and applying hardening controls such as module loading restrictions, kernel lockdown where applicable, and least-privilege access to device nodes.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated to a vendor build that includes the CAIF serial fix. Validate with uname -r, distribution package metadata, vendor advisories, and reboot status. Check whether CAIF support is present or loaded by reviewing kernel configuration and loaded modules, for example CONFIG_CAIF, CONFIG_CAIF_TTY, /proc/modules, lsmod, and modinfo where available. Confirm any temporary mitigation prevents CAIF serial support from loading or being used. In test environments only, validate the fix by attempting to reproduce the close/transmit race; patched kernels should not produce KASAN use-after-free reports in handle_tx() or related caif_serial transmit paths.

Typical attack path

1. Gain local, low-privileged execution on a Linux system running an affected kernel.
2. Identify that CAIF serial support is available, either built into the kernel or loaded as a module.
3. Open or interact with a tty device and configure the CAIF serial line discipline.
4. Generate packet transmission through the CAIF network device while concurrently closing the line discipline.
5. Win the race between ldisc_close() and caif_xmit()/handle_tx().
6. Trigger use-after-free when handle_tx() dereferences the stale tty pointer and calls tty->ops->write().
7. Cause kernel panic/denial of service or attempt to convert the memory corruption into local privilege escalation.

How to detect it

There are no universal network indicators because exploitation is local and targets a kernel race condition. To assess possible prior exploitation, review kernel logs, system journals, crash dumps, and EDR telemetry for kernel memory-safety failures involving CAIF serial transmission, tty line discipline close operations, or handle_tx(). Relevant log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dump/vmcore analysis, KASAN/KFENCE reports, auditd logs for ioctl activity on tty devices, and EDR process telemetry showing unusual access to /dev/tty* followed by packet socket activity or kernel crashes. Look for repeated local processes opening tty devices, setting line disciplines, triggering CAIF interface activity, and then causing kernel oops/panic events. If crash dumps are available, inspect call traces for handle_tx(), caif_xmit(), dev_hard_start_xmit(), __dev_queue_xmit(), packet_sendmsg(), ldisc_close(), and caif_serial paths. Absence of these artifacts does not prove non-exploitation, especially on systems without KASAN, persistent kernel logging, auditd, or crash dump collection.

• BUG: KASAN: slab-use-after-free in handle_tx
• slab-use-after-free in handle_tx
• handle_tx+0x
• caif_xmit
• caif_serial
• ldisc_close()
• tty_kref_put
• tty->ops->write
• unregister_netdevice
• packet_sendmsg
• packet_sendmsg+0x
• dev_hard_start_xmit
• __dev_queue_xmit
• Read of size 1 at addr
• freed 2048-byte region
• /dev/ttyS
• /dev/tty
• TIOCSETD
• N_CAIF
• CONFIG_CAIF
• CONFIG_CAIF_TTY

What your security team should do

• Prioritize patching shared, multi-user, CI/CD, container-hosting, virtualization, and edge/embedded Linux systems where untrusted local code can execute.
• Inventory Linux kernels that include CAIF serial support and identify systems where caif_serial or related CAIF modules are loaded or loadable.
• Upgrade to the vendor-fixed kernel and reboot; verify the active runtime kernel is the fixed version.
• If patching is delayed, disable unused CAIF serial support or block related module loading where feasible, and restrict access to tty device nodes.
• Increase monitoring for kernel oops, panic, KASAN, or slab-use-after-free messages involving handle_tx, caif_xmit, caif_serial, ldisc_close, or tty reference handling.
• Review local audit, EDR, and system logs for suspicious processes repeatedly opening tty devices, changing line disciplines, and generating packet transmissions around kernel crashes.
• Treat unexplained kernel crashes involving CAIF or tty transmit paths as potentially security-relevant and preserve logs, vmcore dumps, and process telemetry for investigation.