CVE-2026-93050ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup on remove
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Sep 17, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from 05e5027efc9c0bb6d1d04cde279afbafca0a7929 before ab5f5b27a340004b92252c6a5f23bf1c6cf3b02a; from 05e5027efc9c0bb6d1d04cde279afbafca0a7929 before c92ef8fd834521f0b788e0511976c689fe57c63c; from 05e5027efc9c0bb6d1d04cde279afbafca0a7929 before a4613140f01bd0fb9980e2746ed9aaa65a29b5d6; 05e5027efc9c0bb6d1d04cde279afbafca0a7929 builds before 1a3258e105f711538201bdd2ac2a05b11554eabc; 05e5027efc9c0bb6d1d04cde279afbafca0a7929 builds before 4a6518be316029650301f2a5e8f0def229b895d9; from 05e5027efc9c0bb6d1d04cde279afbafca0a7929 before b6b5d64cb161a28347d64dc3168a636c4abb68d5 | CNA record |
References
- https://git.kernel.org/stable/c/ab5f5b27a340004b92252c6a5f23bf1c6cf3b02a
- https://git.kernel.org/stable/c/c92ef8fd834521f0b788e0511976c689fe57c63c
- https://git.kernel.org/stable/c/a4613140f01bd0fb9980e2746ed9aaa65a29b5d6
- https://git.kernel.org/stable/c/1a3258e105f711538201bdd2ac2a05b11554eabc
- https://git.kernel.org/stable/c/4a6518be316029650301f2a5e8f0def229b895d9
- https://git.kernel.org/stable/c/b6b5d64cb161a28347d64dc3168a636c4abb68d5
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.