In the Linux kernel, the following vulnerability has been resolved: slip: fix use-after-free in sl_sync() slip_devs[] stores bare net_device pointers and takes no reference on them
Why It Matters
Analysis dossierWhy It Matters
In the Linux kernel, the following vulnerability has been resolved: slip: fix use-after-free in sl_sync() slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: /* Snapshot list, allow later requests */ list_replace_init(&net_todo_list, &list); __rtnl_unlock(); ... if (dev->priv_destructor) dev->priv_destructor(dev); /* slip_devs[i] = NULL */ if (dev->needs_free_netdev) free_netdev(dev); ... /* Free network device */ kobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 ("slip: Fix use-after-free Read in slip_open") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: the ---truncated---
High
Unknown
Unknown
Risk basis: SOC ecosystem technology relevance; HIGH severity; No confirmed exploitation signal in current enrichment
Affected Products & Remediation
0 source-backed productsVendor or catalog guidance (source)
Not provided by source
Known exploitation (source facts)
Only what a source states. Unknown means no source has said either way; it is not "not exploited".
- CISA KEV
- Unknown
- Exploited (source statement)
- Unknown
- Publicly disclosed (source)
- Unknown
Suggested hunting (rule-based inference)
SecOps Signal recommendation (rule-based inference). These steps are hunting hypotheses from the vulnerability class; they do not state or imply that exploitation occurred here or anywhere.
Matched local-privilege-escalation (CVSS AV:L, CVSS PR:L)
Exposure
- Identify hosts reporting this CVE, prioritising shared or multi-user systems.Telemetry: DeviceTvmSoftwareVulnerabilities · A local, low-privilege vector matters most where untrusted users can run code. · Rule local-privilege-escalation
Exploitation evidence
- Look for low-privileged processes spawning SYSTEM or root-level child processes on affected hosts.Telemetry: DeviceProcessEvents · Hunting hypothesis from the CVSS vector; privilege transitions are a focused starting point, not evidence of attack. · Rule local-privilege-escalation
Response
- Confirm the source-stated update on affected hosts.Telemetry: DeviceTvmSoftwareVulnerabilities · Host inventory can verify remediation. · Rule local-privilege-escalation
CISA KEV Record
CISA KEV status was not determined for this record.
Change History & Source Data
— No recorded material change
- CNA / source
- 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- Record status · verification
- UPDATED · NVD API
- CPE
- Unknown
Evidence & Provenance
— No published hunting query names this record. Browse community and library queries instead.
Correlated briefings
— No published briefing references this CVE