Cloudanix VulnDB

CVE-2026-93050

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in a Linux kernel driver for certain serial hardware can let the system crash or become unstable if the device is removed while still in use.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free of struct ipoctal, null pointer dereference on xmit_buf, and use-after-free on carrier owner pointer during tty operations after device removal in the ipoctal driver.

Why it matters to the business

Potential system instability, crashes, or kernel-level compromise on Linux systems using affected ipack hardware, increasing operational risk until patched.

How an attack unfolds

An attacker maintains an open tty session on the ipoctal device, triggers device removal while the session remains active, then performs write, set_termios, or other tty operations that access already-freed memory or unmapped regions.

How to fix it

Apply the upstream kernel patch introducing kref lifetime management, the removed flag, NULL checks, and cached carrier_owner; rebuild and deploy the fixed kernel on affected systems.

How to confirm the fix worked

Verify the patch is present by inspecting ipoctal.c for kref usage in install/cleanup, the removed flag checks in tty ops, and NULL guard in write_tty; test device removal while a tty session is active.

Typical attack path

  1. Open and hold a tty file descriptor on the ipoctal device
  2. Trigger __ipoctal_remove via physical removal or driver unload
  3. Continue tty operations such as write_tty or hangup that dereference freed structures
  4. Trigger kernel panic, null dereference, or memory corruption leading to potential code execution

How to detect it

Search kernel logs and dmesg for oops, page faults, or warnings referencing ipoctal_write_tty, ipoctal_cleanup, __ipoctal_remove, or ipack_put_carrier around device removal events.

  • ipack_put_carrier
  • ipoctal_write_tty
  • __ipoctal_remove
  • tty_port_free_xmit_buf
  • kref_put.*ipoctal

What your security team should do

  • Prioritize kernel update on systems exposing ipoctal tty devices
  • Monitor vendor and distribution kernel advisories for backported fixes
  • Restrict physical or privileged access to ipack hardware until patched
  • Add kernel crash and oops monitoring for ipoctal-related symbols

The record

In the Linux kernel, the following vulnerability has been resolved: ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup on remove Three issues arise when the device is removed while a tty session is still active: 1. UAF of struct ipoctal: the remove callback frees ipoctal via kfree() while tty ops may still access it. Fix by introducing kref-based lifetime management — kref is taken in install() when a tty is opened and released in cleanup() when the tty is finally destroyed; remove() uses kref_put() instead of kfree(). 2. NULL dereference in ipoctal_write_tty(): __ipoctal_remove() frees xmit_buf via tty_port_free_xmit_buf() while a userspace process may still hold the tty fd and call write(). Fix by checking for NULL xmit_buf in ipoctal_write_tty(). 3. UAF in ipoctal_cleanup(): ipack_put_carrier(ipoctal->dev) dereferences ipoctal->dev after the ipack_device has been freed by ipack_device_del(). Fix by caching ipoctal->carrier_owner during probe() and calling module_put() on the cached pointer directly in cleanup(), avoiding any access to ipoctal->dev. Also introduce a "removed" flag in struct ipoctal, set at the start of __ipoctal_remove(), and checked in every tty op that accesses hardware resources (port_activate, write_tty, set_termios, hangup, shutdown). This prevents page faults when devm_ioremap() regions are unmapped after remove() returns.

Affected packages

Ecosystem Package Introduced Fixed