GHSA-7MQ9-8547-CP53

Vulnerability from github – Published: 2026-07-19 12:30 – Updated: 2026-07-20 15:31
VLAI
Details

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

f2fs: bound i_inline_xattr_size for non-inline-xattr inodes

When the flexible_inline_xattr feature is enabled, do_read_inode() loads the on-disk i_inline_xattr_size unconditionally:

if (f2fs_sb_has_flexible_inline_xattr(sbi))
    fi->i_inline_xattr_size = le16_to_cpu(ri->i_inline_xattr_size);

but sanity_check_inode() only range-checks it when the inode also has the FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline data but not FI_INLINE_XATTR -- the normal layout for an inline directory -- therefore keeps a fully attacker-controlled i_inline_xattr_size from a crafted image.

get_inline_xattr_addrs() returns that value with no flag gating, so it feeds the inode geometry:

MAX_INLINE_DATA()  = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1)
NR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...)
addrs_per_page()   = CUR_ADDRS_PER_INODE - i_inline_xattr_size

A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY() negative, so make_dentry_ptr_inline() sets d->max (int) to a negative value. The inline directory walk then compares an unsigned long bit_pos against that negative d->max, which is promoted to a huge unsigned bound, and reads far past the inline area:

while (bit_pos < d->max)        /* fs/f2fs/dir.c */
    ... test_bit_le(bit_pos, d->bitmap) / d->dentry[bit_pos] ...

Mounting a crafted image and reading such a directory triggers an out-of-bounds read in f2fs_fill_dentries(); the same underflow also corrupts ADDRS_PER_INODE for regular files.

Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the flexible_inline_xattr feature is enabled -- i.e. whenever the value is loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE bound gated on inodes that actually carry an inline xattr, so legitimate inodes with i_inline_xattr_size == 0 are still accepted.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-63815"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T12:16:54Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: bound i_inline_xattr_size for non-inline-xattr inodes\n\nWhen the flexible_inline_xattr feature is enabled, do_read_inode() loads\nthe on-disk i_inline_xattr_size unconditionally:\n\n\tif (f2fs_sb_has_flexible_inline_xattr(sbi))\n\t\tfi-\u003ei_inline_xattr_size = le16_to_cpu(ri-\u003ei_inline_xattr_size);\n\nbut sanity_check_inode() only range-checks it when the inode also has the\nFI_INLINE_XATTR flag set.  An inode that carries an inline dentry or inline\ndata but not FI_INLINE_XATTR -- the normal layout for an inline\ndirectory -- therefore keeps a fully attacker-controlled\ni_inline_xattr_size from a crafted image.\n\nget_inline_xattr_addrs() returns that value with no flag gating, so it\nfeeds the inode geometry:\n\n\tMAX_INLINE_DATA()  = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1)\n\tNR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...)\n\taddrs_per_page()   = CUR_ADDRS_PER_INODE - i_inline_xattr_size\n\nA large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY()\nnegative, so make_dentry_ptr_inline() sets d-\u003emax (int) to a negative\nvalue.  The inline directory walk then compares an unsigned long bit_pos\nagainst that negative d-\u003emax, which is promoted to a huge unsigned bound,\nand reads far past the inline area:\n\n\twhile (bit_pos \u003c d-\u003emax)\t\t/* fs/f2fs/dir.c */\n\t\t... test_bit_le(bit_pos, d-\u003ebitmap) / d-\u003edentry[bit_pos] ...\n\nMounting a crafted image and reading such a directory triggers an\nout-of-bounds read in f2fs_fill_dentries(); the same underflow also\ncorrupts ADDRS_PER_INODE for regular files.\n\nValidate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the\nflexible_inline_xattr feature is enabled -- i.e. whenever the value is\nloaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE\nbound gated on inodes that actually carry an inline xattr, so legitimate\ninodes with i_inline_xattr_size == 0 are still accepted.",
  "id": "GHSA-7mq9-8547-cp53",
  "modified": "2026-07-20T15:31:47Z",
  "published": "2026-07-19T12:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63815"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/16bc237ce3c483b75575abea53cfb639745311ed"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a9f9791653ba5ed3fb45bbffa8d63a7cd5cf706"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/378acf3cf19b6af6cba55e8dd1154c4e1504bae8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4ce2d52f680c1d8bfdad7cce05b815ea7ca9790d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…