{"vulnerability": "CVE-2024-42231", "sightings": [{"uuid": "86501a2f-3260-44f2-af64-a8ec6c70a912", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-42231", "type": "seen", "source": "https://t.me/cvedetector/2000", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42231 - \"Btrfs Zoned Mode Advisory Allocation Denial of Service\"\", \n  \"Content\": \"CVE ID : CVE-2024-42231 \nPublished : July 30, 2024, 8:15 a.m. | 20\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbtrfs: zoned: fix calc_available_free_space() for zoned mode  \n  \ncalc_available_free_space() returns the total size of metadata (or  \nsystem) block groups, which can be allocated from unallocated disk  \nspace. The logic is wrong on zoned mode in two places.  \n  \nFirst, the calculation of data_chunk_size is wrong. We always allocate  \none zone as one chunk, and no partial allocation of a zone. So, we  \nshould use zone_size (= data_sinfo->chunk_size) as it is.  \n  \nSecond, the result \"avail\" may not be zone aligned. Since we always  \nallocate one zone as one chunk on zoned mode, returning non-zone size  \naligned bytes will result in less pressure on the async metadata reclaim  \nprocess.  \n  \nThis is serious for the nearly full state with a large zone size device.  \nAllowing over-commit too much will result in less async reclaim work and  \nend up in ENOSPC. We can align down to the zone size to avoid that. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"30 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-30T10:43:11.000000Z"}]}