thunderbolt: Prevent XDomain delayed work use-after-free on disconnect
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.266, 5.15.217, 6.1.184, 6.6.151, 6.12.103, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Prevent XDomain delayed work use-after-free on disconnect tb_xdp_handle_request() runs on system_wq and queues xd->state_work via queue_delayed_work() in three request handlers: PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake), and LINK_STATE_CHANGE_REQUEST. Similarly, update_xdomain() queues xd->properties_changed_work when local properties change. Concurrently, tb_xdomain_remove() calls stop_handshake() which does cancel_delayed_work_sync() on both delayed works. Later, tb_xdomain_unregister() calls device_unregister() which eventually frees the xdomain. Since commit 559c1e1e0134 ("thunderbolt: Run tb_xdp_handle_request() in system workqueue") moved the request handler off tb->wq, the handler and the remove path are no longer serialized. If queue_delayed_work() executes after cancel_delayed_work_sync() but before the xdomain is freed, the delayed work fires on a freed object. Add xd->removing that tb_xdomain_remove() sets under xd->lock before calling stop_handshake(). Each external queue site holds the same lock and checks removing before calling queue_delayed_work(). This provides the mutual exclusion needed: either the queue site acquires the lock first and queues work that the subsequent cancel will see, or the remove path acquires the lock first and the queue site observes removing == true and skips the queue.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From 559c1e1e013437bf190469efbcbd8bc803285853 · fixed in d4fa0d544c04dea636bf821ff5582cd7d63e2c34; From 559c1e1e013437bf190469efbcbd8bc803285853 · fixed in cfbd2dba3d862c9be8c92bea2a357d9ed828a54a; From 559c1e1e013437bf190469efbcbd8bc803285853 · fixed in dc11d5118f9da6ea28487ffe055de5a0d0734125; From 559c1e1e013437bf190469efbcbd8bc803285853 · fixed in 91b40862a02000f490b63f1d315be3ee31e83871; From 559c1e1e013437bf190469efbcbd8bc803285853 · fixed in 33c0ee18cf8665c974b00f4e0ba769fbc07efe10; From 559c1e1e013437bf190469efbcbd8bc803285853 · fixed in 54a62153c765cd24239cde1f2633f2a2fd005368; From 559c1e1e013437bf190469efbcbd8bc803285853 · fixed in 2aa2cde2cc79a79d8ea4a15be9f4a67fc528ae91; From 559c1e1e013437bf190469efbcbd8bc803285853 · fixed in 2c5d2d3c3f70cde2565d7b279b544893a2035842
- Linux Linux
5.2
- KernelLinux
From 5.2.0 · fixed in 5.10.266; From 5.11.0 · fixed in 5.15.217; From 5.16.0 · fixed in 6.1.184; From 6.2.0 · fixed in 6.6.151; From 6.7.0 · fixed in 6.12.103; From 6.13.0 · fixed in 6.18.44; From 6.19.0 · fixed in 7.1.8
References 8
git.kernel.org
- stable/c/d4fa0d544c04dea636bf821ff5582cd7d63e2c34
- stable/c/cfbd2dba3d862c9be8c92bea2a357d9ed828a54a
- stable/c/dc11d5118f9da6ea28487ffe055de5a0d0734125
- stable/c/91b40862a02000f490b63f1d315be3ee31e83871
- stable/c/33c0ee18cf8665c974b00f4e0ba769fbc07efe10
- stable/c/54a62153c765cd24239cde1f2633f2a2fd005368
- stable/c/2aa2cde2cc79a79d8ea4a15be9f4a67fc528ae91
- stable/c/2c5d2d3c3f70cde2565d7b279b544893a2035842