ghsa-cpc3-2882-hfpf
Vulnerability from github
Published
2024-10-21 15:32
Modified
2024-11-08 18:30
Details

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

f2fs: Require FMODE_WRITE for atomic write ioctls

The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true.

There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways:

  • F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0
  • F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file

Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-47740"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T13:15:04Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: Require FMODE_WRITE for atomic write ioctls\n\nThe F2FS ioctls for starting and committing atomic writes check for\ninode_owner_or_capable(), but this does not give LSMs like SELinux or\nLandlock an opportunity to deny the write access - if the caller\u0027s FSUID\nmatches the inode\u0027s UID, inode_owner_or_capable() immediately returns true.\n\nThere are scenarios where LSMs want to deny a process the ability to write\nparticular files, even files that the FSUID of the process owns; but this\ncan currently partially be bypassed using atomic write ioctls in two ways:\n\n - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can\n   truncate an inode to size 0\n - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert\n   changes another process concurrently made to a file\n\nFix it by requiring FMODE_WRITE for these operations, just like for\nF2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these\nioctls when intending to write into the file, that seems unlikely to break\nanything.",
  "id": "GHSA-cpc3-2882-hfpf",
  "modified": "2024-11-08T18:30:44Z",
  "published": "2024-10-21T15:32:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47740"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/000bab8753ae29a259feb339b99ee759795a48ac"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/32f348ecc149e9ca70a1c424ae8fa9b6919d2713"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4583290898c13c2c2e5eb8773886d153c2c5121d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4ce87674c3a6b4d3b3d45f85b584ab8618a3cece"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4f5a100f87f32cb65d4bb1ad282a08c92f6f591e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5e0de753bfe87768ebe6744d869caa92f35e5731"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/700f3a7c7fa5764c9f24bbf7c78e0b6e479fa653"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/88ff021e1fea2d9b40b2d5efd9013c89f7be04ac"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f3bfac2cabf5333506b263bc0c8497c95302f32d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

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…