ghsa-875j-57vx-426c
Vulnerability from github
Published
2024-07-30 09:31
Modified
2024-07-30 09:31
Details

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

nilfs2: fix inode number range checks

Patch series "nilfs2: fix potential issues related to reserved inodes".

This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value.

This patch (of 3):

In the current implementation of nilfs2, "nilfs->ns_first_ino", which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked.

As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFS_MDT_INODE and NILFS_VALID_INODE) will not function properly.

In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if "ns_first_ino" is set to a large value other than the default value NILFS_USER_INO (=11), the macros may potentially malfunction depending on the environment.

Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and by preventing bit shifts equal to or greater than the NILFS_USER_INO constant in the inode number test macros.

Also, change the type of "ns_first_ino" from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-42105"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-30T08:15:03Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix inode number range checks\n\nPatch series \"nilfs2: fix potential issues related to reserved inodes\".\n\nThis series fixes one use-after-free issue reported by syzbot, caused by\nnilfs2\u0027s internal inode being exposed in the namespace on a corrupted\nfilesystem, and a couple of flaws that cause problems if the starting\nnumber of non-reserved inodes written in the on-disk super block is\nintentionally (or corruptly) changed from its default value.  \n\n\nThis patch (of 3):\n\nIn the current implementation of nilfs2, \"nilfs-\u003ens_first_ino\", which\ngives the first non-reserved inode number, is read from the superblock,\nbut its lower limit is not checked.\n\nAs a result, if a number that overlaps with the inode number range of\nreserved inodes such as the root directory or metadata files is set in the\nsuper block parameter, the inode number test macros (NILFS_MDT_INODE and\nNILFS_VALID_INODE) will not function properly.\n\nIn addition, these test macros use left bit-shift calculations using with\nthe inode number as the shift count via the BIT macro, but the result of a\nshift calculation that exceeds the bit width of an integer is undefined in\nthe C specification, so if \"ns_first_ino\" is set to a large value other\nthan the default value NILFS_USER_INO (=11), the macros may potentially\nmalfunction depending on the environment.\n\nFix these issues by checking the lower bound of \"nilfs-\u003ens_first_ino\" and\nby preventing bit shifts equal to or greater than the NILFS_USER_INO\nconstant in the inode number test macros.\n\nAlso, change the type of \"ns_first_ino\" from signed integer to unsigned\ninteger to avoid the need for type casting in comparisons such as the\nlower bound check introduced this time.",
  "id": "GHSA-875j-57vx-426c",
  "modified": "2024-07-30T09:31:51Z",
  "published": "2024-07-30T09:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42105"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/08cab183a624ba71603f3754643ae11cab34dbc4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1c91058425a01131ea30dda6cf43c67b17884d6a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3be4dcc8d7bea52ea41f87aa4bbf959efe7a5987"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/57235c3c88bb430043728d0d02f44a4efe386476"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/731011ac6c37cbe97ece229fc6daa486276052c5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9194f8ca57527958bee207919458e372d638d783"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e2fec219a36e0993642844be0f345513507031f4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fae1959d6ab2c52677b113935e36ab4e25df37ea"
    }
  ],
  "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.