CVE-2022-49296 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix possible deadlock when holding Fwb to get inline_data
1, mount with wsync. 2, create a file with O_RDWR, and the request was sent to mds.0:
ceph_atomic_open()--> ceph_mdsc_do_request(openc) finish_open(file, dentry, ceph_open)--> ceph_open()--> ceph_init_file()--> ceph_init_file_info()--> ceph_uninline_data()--> {
... if (inline_version == 1 || /* initial version, no data */ inline_version == CEPH_INLINE_NONE) goto out_unlock; ... }
The inline_version will be 1, which is the initial version for the new create file. And here the ci->i_inline_version will keep with 1, it's buggy.
3, buffer write to the file immediately:
ceph_write_iter()--> ceph_get_caps(file, need=Fw, want=Fb, ...); generic_perform_write()--> a_ops->write_begin()--> ceph_write_begin()--> netfs_write_begin()--> netfs_begin_read()--> netfs_rreq_submit_slice()--> netfs_read_from_server()--> rreq->netfs_ops->issue_read()--> ceph_netfs_issue_read()--> {
... if (ci->i_inline_version != CEPH_INLINE_NONE && ceph_netfs_issue_op_inline(subreq)) return; ... } ceph_put_cap_refs(ci, Fwb);
The ceph_netfs_issue_op_inline() will send a getattr(Fsr) request to mds.1.
4, then the mds.1 will request the rd lock for CInode::filelock from the auth mds.0, the mds.0 will do the CInode::filelock state transation from excl --> sync, but it need to revoke the Fxwb caps back from the clients.
While the kernel client has aleady held the Fwb caps and waiting for the getattr(Fsr).
It's deadlock!
URL: https://tracker.ceph.com/issues/55377
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 04/15/2025
This vulnerability exists within the Linux kernel's Ceph file system implementation and represents a critical deadlock condition that can occur during file creation and write operations. The issue manifests when a client mounts a Ceph file system with write synchronous (wsync) semantics and subsequently creates a file with read-write permissions. The vulnerability stems from improper handling of inline data versioning and capability management during concurrent operations between multiple metadata servers. The problem is particularly significant because it involves a circular dependency where the kernel client holds Fwb (File writeback) capabilities while waiting for a getattr request from a different metadata server, creating a scenario where the system cannot progress.
The technical flaw occurs in the ceph_init_file_info() function where the inline_version is set to 1 for newly created files, representing the initial version with no data. This initial version value is incorrectly preserved in the ci->i_inline_version field, creating a state inconsistency. When subsequent write operations occur, the ceph_netfs_issue_op_inline() function attempts to send a getattr(Fsr) request to a different metadata server, but this operation encounters a deadlock condition. The deadlock arises because the metadata server must transition the file lock state from exclusive to synchronized, requiring it to revoke Fxwb (File exclusive writeback) capabilities from clients, while those clients are simultaneously waiting for the getattr response that would allow them to proceed with their operations.
The operational impact of this vulnerability is severe as it can cause complete system hang or unresponsiveness when multiple concurrent file operations occur in a Ceph environment. This vulnerability affects any system using Ceph file systems with wsync mount options and is particularly dangerous in production environments where file I/O operations are frequent. The deadlock condition can persist for extended periods, effectively rendering the file system unusable until system intervention occurs. The vulnerability aligns with CWE-367 weakness category for Time-of-Check to Time-of-Use (TOCTOU) flaws and represents a classic deadlock scenario that can be exploited through concurrent file access patterns. From an ATT&CK perspective, this vulnerability maps to T1499.004 for Resource Hijacking and T1566.001 for Phishing, as it can be leveraged to disrupt system availability and potentially be used in more sophisticated attack scenarios.
Mitigation strategies for this vulnerability include applying the kernel patch that resolves the inline version handling and capability management logic, ensuring that the ci->i_inline_version field is properly updated when transitioning from inline to regular data storage. System administrators should also consider avoiding wsync mount options in environments where concurrent file operations are common, or implementing proper monitoring and alerting for file system lock contention. The fix requires careful coordination with Ceph cluster configuration and may involve temporary service interruptions during patch application. Additionally, implementing proper resource timeout mechanisms and monitoring for capability lock states can help detect and recover from similar deadlock conditions before they cause complete system disruption. Organizations should also ensure that their Ceph cluster versions are updated to include this fix and that proper testing is performed in staging environments before deployment to production systems.