CVE-2025-38621
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2025-38621
- Import Source
- https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-38621.json
- JSON Data
- https://api.osv.dev/v1/vulns/CVE-2025-38621
- Downstream
- Related
- Published
- 2025-08-22T16:15:35Z
- Modified
- 2025-08-30T18:00:21Z
- Summary
- [none]
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
md: make rdev_addable usable for rcu mode
Our testcase trigger panic:
BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: mdmisc mdstartsync RIP: 0010:rdevaddable+0x4d/0xf0 ... Call Trace: <TASK> mdstartsync+0x329/0x480 processonework+0x226/0x6d0 workerthread+0x19e/0x340 kthread+0x10f/0x250 retfromfork+0x14d/0x180 retfromforkasm+0x1a/0x30 </TASK> Modules linked in: raid10 CR2: 00000000000000e0 ---[ end trace 0000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0
mdsparesneedchange in mdstartsync will call rdevaddable which protected by rcureadlock/rcureadunlock. This rcu context will help protect rdev won't be released, but rdev->mddev will be set to NULL before we call synchronizercu in mdkickrdevfromarray. Fix this by using READONCE and check does rdev->mddev still alive.
- References