ghsa-f344-cfpj-cvmx
Vulnerability from github
Published
2025-01-19 12:31
Modified
2025-01-23 18:31
Details

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

fs: relax assertions on failure to encode file handles

Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons.

The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.

There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those assertions because they are wrong.

The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate.

The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.

Triggering this assertion was always possible with other filesystems and other reasons of ->encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlayfs that is mounted with options index=on,nfs_export=on also on kernels < v6.6. Therefore, I am not listing the aforementioned commit as a Fixes commit.

Backport hint: this patch will have a trivial conflict applying to v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-57924"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-19T12:15:26Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: relax assertions on failure to encode file handles\n\nEncoding file handles is usually performed by a filesystem \u003eencode_fh()\nmethod that may fail for various reasons.\n\nThe legacy users of exportfs_encode_fh(), namely, nfsd and\nname_to_handle_at(2) syscall are ready to cope with the possibility\nof failure to encode a file handle.\n\nThere are a few other users of exportfs_encode_{fh,fid}() that\ncurrently have a WARN_ON() assertion when -\u003eencode_fh() fails.\nRelax those assertions because they are wrong.\n\nThe second linked bug report states commit 16aac5ad1fa9 (\"ovl: support\nencoding non-decodable file handles\") in v6.6 as the regressing commit,\nbut this is not accurate.\n\nThe aforementioned commit only increases the chances of the assertion\nand allows triggering the assertion with the reproducer using overlayfs,\ninotify and drop_caches.\n\nTriggering this assertion was always possible with other filesystems and\nother reasons of -\u003eencode_fh() failures and more particularly, it was\nalso possible with the exact same reproducer using overlayfs that is\nmounted with options index=on,nfs_export=on also on kernels \u003c v6.6.\nTherefore, I am not listing the aforementioned commit as a Fixes commit.\n\nBackport hint: this patch will have a trivial conflict applying to\nv6.6.y, and other trivial conflicts applying to stable kernels \u003c v6.6.",
  "id": "GHSA-f344-cfpj-cvmx",
  "modified": "2025-01-23T18:31:18Z",
  "published": "2025-01-19T12:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57924"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/974e3fe0ac61de85015bbe5a4990cf4127b304b2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/adcde2872f8fc399b249758ae1990dcd53b694ea"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f47c834a9131ae64bee3c462f4e610c67b0a000f"
    }
  ],
  "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.