CVE-2026-43458

What it actually does

This is a local Linux kernel use-after-free in the CAIF serial line discipline. The vulnerable path can leave caif_serial using a tty->link object after its lifetime has ended; when the transmit path calls tty_write_room(), the kernel may dereference freed memory through tty->link->port. A local user able to interact with pseudo-terminal/TTY line discipline behavior may trigger memory corruption, causing a kernel crash and, depending on exploitability on a given kernel build and hardening configuration, potentially local privilege escalation with kernel-level code execution.

Why it matters to the business

Successful exploitation could allow a user or compromised low-privileged process on a Linux system to crash the host or potentially gain elevated privileges, increasing the blast radius of an initial foothold. The risk is most relevant for multi-user Linux systems, shared compute environments, developer workstations, containers with excessive device/TTY access, and servers where untrusted local code can run. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has very low EPSS, so it should be prioritized as a kernel hardening and privilege-escalation fix rather than treated as an actively exploited internet-facing emergency.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged or low-privileged user. They then exercise the vulnerable CAIF serial line discipline/TTY interaction, typically by creating or manipulating pseudo-terminals and causing the CAIF serial transmit path to call tty_write_room() while the linked TTY object has been released. On vulnerable kernels, this produces a use-after-free access to tty->link->port. In a simple exploitation scenario, this results in a kernel oops or panic and denial of service. In a more advanced scenario, the attacker attempts to groom kernel heap memory so that the stale pointer references attacker-influenced data, potentially converting the memory-safety bug into local privilege escalation. No public exploit maturity is indicated in the supplied data.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the CAIF serial line discipline reference-counting issue. The fix holds an additional reference on tty->link for the lifetime of the caif_serial line discipline, acquiring it in ldisc_open() and releasing it in ser_release() and on open-error paths. No exact fixed package versions were provided, so use vendor advisories for the relevant distribution or kernel supplier and install the first kernel version that explicitly includes the CVE-2026-43458 fix or the corresponding upstream patch. After updating, reboot into the fixed kernel. Where immediate patching is not possible, reduce exposure by restricting local shell access, limiting execution of untrusted code, disabling or avoiding unnecessary CAIF/TTY-related functionality where feasible, preventing containers from receiving broad device or TTY access, and ensuring kernel hardening features such as KASLR, SMEP/SMAP, lockdown, and panic/oops handling policies are appropriately configured.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not merely that an updated package is installed. Validate with uname -a, package-manager kernel version checks, and the relevant distribution security advisory. If maintaining custom kernels, verify that the serial caif fix is present in the source by checking that ldisc_open() obtains a tty->link reference and ser_release() releases it, including the error path. Review boot history to ensure systems have rebooted into the patched kernel. Exposure can be further assessed by checking whether CAIF serial support is built or loadable in the kernel configuration and whether local users or workloads can access TTY/PTY functionality needed to trigger the bug.

Typical attack path

1. Gain local execution on a vulnerable Linux host as a low-privileged user or through a compromised local service.
2. Open and manipulate TTY or pseudo-terminal resources associated with the CAIF serial line discipline.
3. Trigger the vulnerable lifecycle race/ordering where caif_serial retains or uses a released tty->link reference.
4. Cause the CAIF serial transmit path to call tty_write_room(), leading to dereference of freed memory through tty->link->port.
5. Achieve a kernel crash for denial of service, or attempt heap grooming to turn the use-after-free into privilege escalation.

How to detect it

Look for evidence of local triggering rather than remote network indicators. Primary sources are kernel logs, system journal, crash dumps, audit logs, and endpoint telemetry. Search dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, and crash collection systems for kernel oops, panic, KASAN, or slab use-after-free messages referencing pty_write_room(), tty_write_room(), tty->link, tty->link->port, caif_serial, ldisc_open(), or ser_release(). Review auditd or EDR process telemetry for unusual local programs repeatedly opening pseudo-terminals, changing TTY line disciplines, or causing kernel crashes shortly before reboot events. If kernel crash dumps are available, inspect stack traces for CAIF serial and TTY functions. Absence of these artifacts does not prove non-exploitation, because successful privilege escalation may not leave a distinctive log entry and non-KASAN production kernels may log only a generic oops or unexpected reboot.

• KASAN: slab-use-after-free
• slab-use-after-free in pty_write_room
• BUG: KASAN: slab-use-after-free in pty_write_room
• pty_write_room
• tty_write_room
• tty->link->port
• caif_serial
• ldisc_open
• ser_release
• serial: caif
• kernel BUG at
• Oops:
• general protection fault
• Kernel panic - not syncing
• /var/log/kern.log
• /var/log/messages
• journalctl -k

What your security team should do

• Inventory Linux systems and identify kernels that predate the vendor fix for this issue.
• Prioritize patching multi-user hosts, shared compute platforms, CI/CD runners, developer workstations, bastion hosts, and container hosts where untrusted local code may execute.
• Apply the vendor-fixed kernel and reboot; verify the active running kernel version after reboot.
• For custom or self-compiled kernels, backport the CAIF serial tty->link reference-counting patch and validate it with regression testing.
• Temporarily reduce local attack surface by limiting shell access, restricting untrusted workloads, and avoiding privileged container/device mappings that expose TTY/serial interfaces unnecessarily.
• Monitor kernel logs for KASAN, use-after-free, tty, pty_write_room, and caif_serial crash signatures that may indicate attempted triggering.
• Because this is not currently KEV-listed and has low EPSS, handle through accelerated routine kernel patching unless local exploit attempts, public exploit code, or vendor emergency advisories emerge.