GHSA-98FC-82JH-J626

Vulnerability from github – Published: 2024-02-28 09:30 – Updated: 2025-01-08 18:30
VLAI?
Details

In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to avoid touching checkpointed data in get_victim()

In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR mode to select victim:

  1. LFS is set to find source section during GC, the victim should have no checkpointed data, since after GC, section could not be set free for reuse.

Previously, we only check valid chpt blocks in current segment rather than section, fix it.

  1. SSR | AT_SSR are set to find target segment for writes which can be fully filled by checkpointed and newly written blocks, we should never select such segment, otherwise it can cause panic or data corruption during allocation, potential case is described as below:

a) target segment has 'n' (n < 512) ckpt valid blocks b) GC migrates 'n' valid blocks to other segment (segment is still in dirty list) c) GC migrates '512 - n' blocks to target segment (segment has 'n' cp_vblocks and '512 - n' vblocks) d) If GC selects target segment via {AT,}SSR allocator, however there is no free space in targe segment.

Severity ?
7.1 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-47004"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-28T09:15:38Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid touching checkpointed data in get_victim()\n\nIn CP disabling mode, there are two issues when using LFS or SSR | AT_SSR\nmode to select victim:\n\n1. LFS is set to find source section during GC, the victim should have\nno checkpointed data, since after GC, section could not be set free for\nreuse.\n\nPreviously, we only check valid chpt blocks in current segment rather\nthan section, fix it.\n\n2. SSR | AT_SSR are set to find target segment for writes which can be\nfully filled by checkpointed and newly written blocks, we should never\nselect such segment, otherwise it can cause panic or data corruption\nduring allocation, potential case is described as below:\n\n a) target segment has \u0027n\u0027 (n \u003c 512) ckpt valid blocks\n b) GC migrates \u0027n\u0027 valid blocks to other segment (segment is still\n    in dirty list)\n c) GC migrates \u0027512 - n\u0027 blocks to target segment (segment has \u0027n\u0027\n    cp_vblocks and \u0027512 - n\u0027 vblocks)\n d) If GC selects target segment via {AT,}SSR allocator, however there\n    is no free space in targe segment.",
  "id": "GHSA-98fc-82jh-j626",
  "modified": "2025-01-08T18:30:41Z",
  "published": "2024-02-28T09:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47004"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/105155a8146ddb54c119d8318964eef3859d109d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1e116f87825f01a6380286472196882746b16f63"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/211372b2571520e394b56b431a0705586013b3ff"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/61461fc921b756ae16e64243f72af2bfc2e620db"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.