fkie_cve-2024-47679
Vulnerability from fkie_nvd
Published
2024-10-21 12:15
Modified
2025-11-03 23:16
Severity ?
4.7 (Medium) - CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bbPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153bPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/489faddb1ae75b0e1a741fe5ca2542a2b5e794a5
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/6c857fb12b9137fee574443385d53914356bbe11Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/6cc13a80a26e6b48f78c725c01b91987d61563ef
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/88b1afbf0f6b221f6c5bb66cc80cd3b38d696687Patch
af854a3a-2127-422b-91ae-364da2661108https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
af854a3a-2127-422b-91ae-364da2661108https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Impacted products
Vendor Product Version
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *


To clipboard 

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "205A6F87-4258-4528-8078-AC66AD2A7B07",
              "versionEndExcluding": "5.10.227",
              "versionStartIncluding": "2.6.37",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "4D51C05D-455B-4D8D-89E7-A58E140B864C",
              "versionEndExcluding": "5.15.168",
              "versionStartIncluding": "5.11",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "D01BD22E-ACD1-4618-9D01-6116570BE1EE",
              "versionEndExcluding": "6.1.113",
              "versionStartIncluding": "5.16",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "D448821D-C085-4CAF-88FA-2DDE7BE21976",
              "versionEndExcluding": "6.6.54",
              "versionStartIncluding": "6.2",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "CE94BB8D-B0AB-4563-9ED7-A12122B56EBE",
              "versionEndExcluding": "6.10.13",
              "versionStartIncluding": "6.7",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "AB755D26-97F4-43B6-8604-CD076811E181",
              "versionEndExcluding": "6.11.2",
              "versionStartIncluding": "6.11",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvfs: fix race between evice_inodes() and find_inode()\u0026iput()\n\nHi, all\n\nRecently I noticed a bug[1] in btrfs, after digged it into\nand I believe it\u0027a race in vfs.\n\nLet\u0027s assume there\u0027s a inode (ie ino 261) with i_count 1 is\ncalled by iput(), and there\u0027s a concurrent thread calling\ngeneric_shutdown_super().\n\ncpu0:                              cpu1:\niput() // i_count is 1\n  -\u003espin_lock(inode)\n  -\u003edec i_count to 0\n  -\u003eiput_final()                    generic_shutdown_super()\n    -\u003e__inode_add_lru()               -\u003eevict_inodes()\n      // cause some reason[2]           -\u003eif (atomic_read(inode-\u003ei_count)) continue;\n      // return before                  // inode 261 passed the above check\n      // list_lru_add_obj()             // and then schedule out\n   -\u003espin_unlock()\n// note here: the inode 261\n// was still at sb list and hash list,\n// and I_FREEING|I_WILL_FREE was not been set\n\nbtrfs_iget()\n  // after some function calls\n  -\u003efind_inode()\n    // found the above inode 261\n    -\u003espin_lock(inode)\n   // check I_FREEING|I_WILL_FREE\n   // and passed\n      -\u003e__iget()\n    -\u003espin_unlock(inode)                // schedule back\n                                        -\u003espin_lock(inode)\n                                        // check (I_NEW|I_FREEING|I_WILL_FREE) flags,\n                                        // passed and set I_FREEING\niput()                                  -\u003espin_unlock(inode)\n  -\u003espin_lock(inode)\t\t\t  -\u003eevict()\n  // dec i_count to 0\n  -\u003eiput_final()\n    -\u003espin_unlock()\n    -\u003eevict()\n\nNow, we have two threads simultaneously evicting\nthe same inode, which may trigger the BUG(inode-\u003ei_state \u0026 I_CLEAR)\nstatement both within clear_inode() and iput().\n\nTo fix the bug, recheck the inode-\u003ei_count after holding i_lock.\nBecause in the most scenarios, the first check is valid, and\nthe overhead of spin_lock() can be reduced.\n\nIf there is any misunderstanding, please let me know, thanks.\n\n[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/\n[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()\nreturn false when I reproduced the bug."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfs: arregla la ejecuci\u00f3n entre evice_inodes() y find_inode()\u0026amp;iput() Hola a todos Recientemente not\u00e9 un error[1] en btrfs, despu\u00e9s de investigarlo y creo que es una ejecuci\u00f3n en vfs. Supongamos que hay un inodo (es decir, ino 261) con i_count 1 que es llamado por iput(), y hay un hilo concurrente que llama a generic_shutdown_super(). cpu0: cpu1: iput() // i_count es 1 -\u0026gt;spin_lock(inode) -\u0026gt;dec i_count a 0 -\u0026gt;iput_final() generic_shutdown_super() -\u0026gt;__inode_add_lru() -\u0026gt;evict_inodes() // por alguna raz\u00f3n[2] -\u0026gt;if (atomic_read(inode-\u0026gt;i_count)) continue; // regresar antes // el inodo 261 pas\u00f3 la verificaci\u00f3n anterior // list_lru_add_obj() // y luego programar la salida -\u0026gt;spin_unlock() // nota aqu\u00ed: el inodo 261 // todav\u00eda estaba en la lista sb y la lista hash, // y I_FREEING|I_WILL_FREE no se hab\u00eda establecido btrfs_iget() // despu\u00e9s de algunas llamadas de funci\u00f3n -\u0026gt;find_inode() // encontr\u00f3 el inodo 261 anterior -\u0026gt;spin_lock(inode) // verific\u00f3 I_FREEING|I_WILL_FREE // y pas\u00f3 -\u0026gt;__iget() -\u0026gt;spin_unlock(inode) // program\u00f3 de regreso -\u0026gt;spin_lock(inode) // verific\u00f3 los indicadores (I_NEW|I_FREEING|I_WILL_FREE), // pas\u00f3 y estableci\u00f3 I_FREEING iput() -\u0026gt;spin_unlock(inode) -\u0026gt;spin_lock(inode) -\u0026gt;evict() // dec i_count a 0 -\u0026gt;iput_final() -\u0026gt;spin_unlock() -\u0026gt;evict() Ahora, tenemos dos subprocesos expulsando simult\u00e1neamente el mismo inodo, lo que puede activar la declaraci\u00f3n BUG(inode-\u0026gt;i_state \u0026amp; I_CLEAR) tanto dentro de clear_inode() como de iput(). Para corregir el error, vuelva a verificar inode-\u0026gt;i_count despu\u00e9s de mantener i_lock. Porque en la mayor\u00eda de los escenarios, la primera verificaci\u00f3n es v\u00e1lida y se puede reducir la sobrecarga de spin_lock(). Si hay alg\u00fan malentendido, h\u00e1gamelo saber, gracias. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: La raz\u00f3n podr\u00eda ser 1. SB_ACTIVE fue eliminado o 2. mapping_shrinkable() devolvi\u00f3 falso cuando reproduje el error."
    }
  ],
  "id": "CVE-2024-47679",
  "lastModified": "2025-11-03T23:16:15.737",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 4.7,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.0,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ]
  },
  "published": "2024-10-21T12:15:04.920",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/489faddb1ae75b0e1a741fe5ca2542a2b5e794a5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/6c857fb12b9137fee574443385d53914356bbe11"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/6cc13a80a26e6b48f78c725c01b91987d61563ef"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/88b1afbf0f6b221f6c5bb66cc80cd3b38d696687"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-362"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}


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 seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • 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.