Executive Summary
| Informations | |||
|---|---|---|---|
| Name | CVE-2022-48901 | First vendor Publication | 2024-08-22 |
| Vendor | Cve | Last vendor Modification | 2024-09-12 |
Security-Database Scoring CVSS v3
| Cvss vector : CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H | |||
|---|---|---|---|
| Overall CVSS Score | 5.5 | ||
| Base Score | 5.5 | Environmental Score | 5.5 |
| impact SubScore | 3.6 | Temporal Score | 5.5 |
| Exploitabality Sub Score | 1.8 | ||
| Attack Vector | Local | Attack Complexity | Low |
| Privileges Required | Low | User Interaction | None |
| Scope | Unchanged | Confidentiality Impact | None |
| Integrity Impact | None | Availability Impact | High |
| Calculate full CVSS 3.0 Vectors scores | |||
Security-Database Scoring CVSS v2
| Cvss vector : | |||
|---|---|---|---|
| Cvss Base Score | N/A | Attack Range | N/A |
| Cvss Impact Score | N/A | Attack Complexity | N/A |
| Cvss Expoit Score | N/A | Authentication | N/A |
| Calculate full CVSS 2.0 Vectors scores | |||
Detail
| In the Linux kernel, the following vulnerability has been resolved: btrfs: do not start relocation until in progress drops are done We hit a bug with a recovering relocation on mount for one of our file systems in production. I reproduced this locally by injecting errors into snapshot delete with balance running at the same time. This presented as an error while looking up an extent item WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680 Normally snapshot deletion and relocation are excluded from running at the same time by the fs_info->cleaner_mutex. However if we had a pending balance waiting to get the ->cleaner_mutex, and a snapshot deletion was running, and then the box crashed, we would come up in a state where we have a half deleted snapshot. Again, in the normal case the snapshot deletion needs to complete before relocation can start, but in this case relocation could very well start before the snapshot deletion completes, as we simply add the root to the dead roots list and wait for the next time the cleaner runs to clean up the snapshot. Fix this by setting a bit on the fs_info if we have any DEAD_ROOT's that had a pending drop_progress key. If they do then we know we were in the middle of the drop operation and set a flag on the fs_info. Then balance can wait until this flag is cleared to start up again. If there are DEAD_ROOT's that don't have a drop_progress set then we're safe to start balance right away as we'll be properly protected by the cleaner_mutex. |
Original Source
| Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-48901 |
CPE : Common Platform Enumeration
Sources (Detail)
Alert History
| Date | Informations |
|---|---|
| 2025-01-08 02:47:27 |
|
| 2025-01-07 02:47:04 |
|
| 2024-12-25 02:45:50 |
|
| 2024-12-12 02:48:43 |
|
| 2024-11-22 02:46:09 |
|
| 2024-11-20 02:43:33 |
|
| 2024-11-14 02:43:25 |
|
| 2024-11-09 02:44:04 |
|
| 2024-10-26 02:41:49 |
|
| 2024-10-25 02:43:35 |
|
| 2024-10-23 02:42:59 |
|
| 2024-10-03 02:39:03 |
|
| 2024-10-02 02:37:26 |
|
| 2024-09-12 21:27:42 |
|
| 2024-08-23 02:48:13 |
|
| 2024-08-23 02:34:45 |
|
| 2024-08-22 17:27:25 |
|
| 2024-08-22 09:27:26 |
|
