CVE-2026-93073: dax: read holder_ops once in dax_holder_notify_failure()
dax: read holderops once in daxholdernotifyfailure()
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.157.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In dax_holder_notify_failure(), fetch dax_dev->holder_ops once into a local variable using READ_ONCE(), then use that same value for both the NULL check and the indirect notify_failure() call.
Event History
Frequently Asked Questions
What concurrent operation is required for this race to occur?
fs_put_dax() must clear dax_dev->holder_ops after dax_holder_notify_failure() has observed it as non-NULL but before the function performs the indirect notify_failure() call. Unlike kill_dax(), fs_put_dax() does not synchronize with readers before clearing the pointer.
What is the impact if the race is triggered?
dax_holder_notify_failure() can dereference a NULL holder_ops pointer when attempting the notify_failure() call.
Does clearing holder_ops through kill_dax() create the same race?
No. kill_dax() clears holder_ops only after synchronize_srcu(), so it cannot race with a reader that is inside dax_read_lock().