fkie_cve-2022-49296
Vulnerability from fkie_nvd
Published
2025-02-26 07:01
Modified
2025-04-14 20:08
Severity ?
Summary
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
References
Impacted products
Vendor | Product | Version | |
---|---|---|---|
linux | linux_kernel | * |
{ "configurations": [ { "nodes": [ { "cpeMatch": [ { "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "48912B8B-BDF1-422C-9CA5-2DDFDBAADC80", "versionEndExcluding": "5.18.4", "versionStartIncluding": "2.6.34", "vulnerable": true } ], "negate": false, "operator": "OR" } ] } ], "cveTags": [], "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix possible deadlock when holding Fwb to get inline_data\n\n1, mount with wsync.\n2, create a file with O_RDWR, and the request was sent to mds.0:\n\n ceph_atomic_open()--\u003e\n ceph_mdsc_do_request(openc)\n finish_open(file, dentry, ceph_open)--\u003e\n ceph_open()--\u003e\n ceph_init_file()--\u003e\n ceph_init_file_info()--\u003e\n ceph_uninline_data()--\u003e\n {\n ...\n if (inline_version == 1 || /* initial version, no data */\n inline_version == CEPH_INLINE_NONE)\n goto out_unlock;\n ...\n }\n\nThe inline_version will be 1, which is the initial version for the\nnew create file. And here the ci-\u003ei_inline_version will keep with 1,\nit\u0027s buggy.\n\n3, buffer write to the file immediately:\n\n ceph_write_iter()--\u003e\n ceph_get_caps(file, need=Fw, want=Fb, ...);\n generic_perform_write()--\u003e\n a_ops-\u003ewrite_begin()--\u003e\n ceph_write_begin()--\u003e\n netfs_write_begin()--\u003e\n netfs_begin_read()--\u003e\n netfs_rreq_submit_slice()--\u003e\n netfs_read_from_server()--\u003e\n rreq-\u003enetfs_ops-\u003eissue_read()--\u003e\n ceph_netfs_issue_read()--\u003e\n {\n ...\n if (ci-\u003ei_inline_version != CEPH_INLINE_NONE \u0026\u0026\n ceph_netfs_issue_op_inline(subreq))\n return;\n ...\n }\n ceph_put_cap_refs(ci, Fwb);\n\nThe ceph_netfs_issue_op_inline() will send a getattr(Fsr) request to\nmds.1.\n\n4, then the mds.1 will request the rd lock for CInode::filelock from\nthe auth mds.0, the mds.0 will do the CInode::filelock state transation\nfrom excl --\u003e sync, but it need to revoke the Fxwb caps back from the\nclients.\n\nWhile the kernel client has aleady held the Fwb caps and waiting for\nthe getattr(Fsr).\n\nIt\u0027s deadlock!\n\nURL: https://tracker.ceph.com/issues/55377" }, { "lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: se corrige un posible bloqueo al mantener presionado Fwb para obtener inline_data 1, montar con wsync. 2, crear un archivo con O_RDWR y la solicitud se envi\u00f3 a mds.0: ceph_atomic_open()--\u0026gt; ceph_mdsc_do_request(openc) finish_open(file, dentry, ceph_open)--\u0026gt; ceph_open()--\u0026gt; ceph_init_file()--\u0026gt; ceph_init_file_info()--\u0026gt; ceph_uninline_data()--\u0026gt; { ... if (inline_version == 1 || /* versi\u00f3n inicial, sin datos */ inline_version == CEPH_INLINE_NONE) goto out_unlock; ... } La inline_version ser\u00e1 1, que es la versi\u00f3n inicial para el nuevo archivo de creaci\u00f3n. Y aqu\u00ed, ci-\u0026gt;i_inline_version se mantendr\u00e1 con 1, es un error. 3, escribe en el b\u00fafer inmediatamente en el archivo: ceph_write_iter()--\u0026gt; ceph_get_caps(archivo, necesidad=Fw, deseo=Fb, ...); generic_perform_write()--\u0026gt; a_ops-\u0026gt;write_begin()--\u0026gt; ceph_write_begin()--\u0026gt; netfs_write_begin()--\u0026gt; netfs_begin_read()--\u0026gt; netfs_rreq_submit_slice()--\u0026gt; netfs_read_from_server()--\u0026gt; rreq-\u0026gt;netfs_ops-\u0026gt;issue_read()--\u0026gt; ceph_netfs_issue_read()--\u0026gt; { ... if (ci-\u0026gt;i_inline_version != CEPH_INLINE_NONE \u0026amp;\u0026amp; ceph_netfs_issue_op_inline(subreq)) return; ... } ceph_put_cap_refs(ci, Fwb); El ceph_netfs_issue_op_inline() enviar\u00e1 una solicitud getattr(Fsr) a mds.1.4, luego mds.1 solicitar\u00e1 el bloqueo de rd para CInode::filelock desde el mds.0 de autenticaci\u00f3n, el mds.0 realizar\u00e1 la transacci\u00f3n de estado de CInode::filelock desde excl --\u0026gt; sync, pero necesita revocar las capacidades Fxwb de los clientes. Mientras que el cliente del kernel ya ha retenido las capacidades Fwb y est\u00e1 esperando el getattr(Fsr). \u00a1Est\u00e1 en un punto muerto! URL: https://tracker.ceph.com/issues/55377" } ], "id": "CVE-2022-49296", "lastModified": "2025-04-14T20:08:21.310", "metrics": { "cvssMetricV31": [ { "cvssData": { "attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1" }, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary" } ] }, "published": "2025-02-26T07:01:06.433", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/292b7a7275ce535a1abfa4dd0b2e586162aaae1e" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/825978fd6a0defc3c29d8a38b6cea76a0938d21e" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [ { "description": [ { "lang": "en", "value": "CWE-667" } ], "source": "nvd@nist.gov", "type": "Primary" } ] }
Loading…
Loading…
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…