CVE-2026-23192
Unknown Unknown - Not Provided
Use-After-Free in Linux Kernel linkwatch Component Causes Crash

Publication date: 2026-02-14

Last updated on: 2026-04-03

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: linkwatch: use __dev_put() in callers to prevent UAF After linkwatch_do_dev() calls __dev_put() to release the linkwatch reference, the device refcount may drop to 1. At this point, netdev_run_todo() can proceed (since linkwatch_sync_dev() sees an empty list and returns without blocking), wait for the refcount to become 1 via netdev_wait_allrefs_any(), and then free the device via kobject_put(). This creates a use-after-free when __linkwatch_run_queue() tries to call netdev_unlock_ops() on the already-freed device. Note that adding netdev_lock_ops()/netdev_unlock_ops() pair in netdev_run_todo() before kobject_put() would not work, because netdev_lock_ops() is conditional - it only locks when netdev_need_ops_lock() returns true. If the device doesn't require ops_lock, linkwatch won't hold any lock, and netdev_run_todo() acquiring the lock won't provide synchronization. Fix this by moving __dev_put() from linkwatch_do_dev() to its callers. The device reference logically pairs with de-listing the device, so it's reasonable for the caller that did the de-listing to release it. This allows placing __dev_put() after all device accesses are complete, preventing UAF. The bug can be reproduced by adding mdelay(2000) after linkwatch_do_dev() in __linkwatch_run_queue(), then running: ip tuntap add mode tun name tun_test ip link set tun_test up ip link set tun_test carrier off ip link set tun_test carrier on sleep 0.5 ip tuntap del mode tun name tun_test KASAN report: ================================================================== BUG: KASAN: use-after-free in netdev_need_ops_lock include/net/netdev_lock.h:33 [inline] BUG: KASAN: use-after-free in netdev_unlock_ops include/net/netdev_lock.h:47 [inline] BUG: KASAN: use-after-free in __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245 Read of size 8 at addr ffff88804de5c008 by task kworker/u32:10/8123 CPU: 0 UID: 0 PID: 8123 Comm: kworker/u32:10 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: events_unbound linkwatch_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x156/0x4c9 mm/kasan/report.c:482 kasan_report+0xdf/0x1a0 mm/kasan/report.c:595 netdev_need_ops_lock include/net/netdev_lock.h:33 [inline] netdev_unlock_ops include/net/netdev_lock.h:47 [inline] __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245 linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304 process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x5da/0xe40 kernel/workqueue.c:3421 kthread+0x3b3/0x730 kernel/kthread.c:463 ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 </TASK> ==================================================================
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-14
Last Modified
2026-04-03
Generated
2026-05-27
AI Q&A
2026-02-14
EPSS Evaluated
2026-05-25
NVD
CVE-2026-23192
EUVD
EUVD-2026-5851
Affected Vendors & Products
Showing 16 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.15
linux linux_kernel 6.15
linux linux_kernel 6.15
linux linux_kernel 6.15
linux linux_kernel 6.15
linux linux_kernel 6.15
linux linux_kernel 6.15
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.15.1 (inc) to 6.18.10 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-416 The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a use-after-free (UAF) issue in the Linux kernel's linkwatch component. It occurs because the device reference count is improperly managed when releasing a device reference with __dev_put(). After linkwatch_do_dev() calls __dev_put(), the device reference count may drop to 1, allowing netdev_run_todo() to proceed and eventually free the device. However, __linkwatch_run_queue() later tries to access the already-freed device, causing a use-after-free error.

The root cause is that __dev_put() is called too early in linkwatch_do_dev(), before all device accesses are complete. The fix involves moving __dev_put() calls to the callers of linkwatch_do_dev(), ensuring the device reference is released only after all accesses finish, preventing the use-after-free condition.


How can this vulnerability impact me? :

This use-after-free vulnerability can lead to undefined behavior in the Linux kernel, including potential system crashes, kernel panics, or memory corruption. Since it involves accessing freed memory, it could be exploited by attackers to execute arbitrary code with kernel privileges or cause denial of service by crashing the system.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be reproduced and thus detected by running a specific sequence of commands that trigger the use-after-free condition in the Linux kernel's linkwatch subsystem.

  • ip tuntap add mode tun name tun_test
  • ip link set tun_test up
  • ip link set tun_test carrier off
  • ip link set tun_test carrier on
  • sleep 0.5
  • ip tuntap del mode tun name tun_test

Additionally, enabling Kernel Address Sanitizer (KASAN) can help detect the use-after-free bug by reporting errors related to netdev_need_ops_lock and netdev_unlock_ops in the kernel logs.


What immediate steps should I take to mitigate this vulnerability?

I don't know


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart