CVE-2024-53130
Vulnerability from cvelistv5
Published
2024-12-04 14:20
Modified
2024-12-05 11:30
Severity ?
Summary
nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint
Impacted products
Vendor Product Version
Linux Linux Version: 3.9
Show details on NVD website


{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/nilfs2/btnode.c",
            "fs/nilfs2/gcinode.c",
            "fs/nilfs2/mdt.c",
            "fs/nilfs2/page.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "7af3309c7a2e",
              "status": "affected",
              "version": "5305cb830834",
              "versionType": "git"
            },
            {
              "lessThan": "86b19031dbc7",
              "status": "affected",
              "version": "5305cb830834",
              "versionType": "git"
            },
            {
              "lessThan": "b0e476574004",
              "status": "affected",
              "version": "5305cb830834",
              "versionType": "git"
            },
            {
              "lessThan": "ffc440a76a0f",
              "status": "affected",
              "version": "5305cb830834",
              "versionType": "git"
            },
            {
              "lessThan": "2026559a6c4c",
              "status": "affected",
              "version": "5305cb830834",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/nilfs2/btnode.c",
            "fs/nilfs2/gcinode.c",
            "fs/nilfs2/mdt.c",
            "fs/nilfs2/page.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "3.9"
            },
            {
              "lessThan": "3.9",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.325",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.119",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.63",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.11.*",
              "status": "unaffected",
              "version": "6.11.10",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.12",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint\n\nWhen using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty()\nmay cause a NULL pointer dereference, or a general protection fault when\nKASAN is enabled.\n\nThis happens because, since the tracepoint was added in\nmark_buffer_dirty(), it references the dev_t member bh-\u003eb_bdev-\u003ebd_dev\nregardless of whether the buffer head has a pointer to a block_device\nstructure.\n\nIn the current implementation, nilfs_grab_buffer(), which grabs a buffer\nto read (or create) a block of metadata, including b-tree node blocks,\ndoes not set the block device, but instead does so only if the buffer is\nnot in the \"uptodate\" state for each of its caller block reading\nfunctions.  However, if the uptodate flag is set on a folio/page, and the\nbuffer heads are detached from it by try_to_free_buffers(), and new buffer\nheads are then attached by create_empty_buffers(), the uptodate flag may\nbe restored to each buffer without the block device being set to\nbh-\u003eb_bdev, and mark_buffer_dirty() may be called later in that state,\nresulting in the bug mentioned above.\n\nFix this issue by making nilfs_grab_buffer() always set the block device\nof the super block structure to the buffer head, regardless of the state\nof the buffer\u0027s uptodate flag."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-12-05T11:30:04.464Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/7af3309c7a2ef26831a67125b11c34a7e01c1b2a"
        },
        {
          "url": "https://git.kernel.org/stable/c/86b19031dbc79abc378dfae357f6ea33ebeb0c95"
        },
        {
          "url": "https://git.kernel.org/stable/c/b0e4765740040c44039282057ecacd7435d1d2ba"
        },
        {
          "url": "https://git.kernel.org/stable/c/ffc440a76a0f476a7e6ea838ec0dc8e9979944d1"
        },
        {
          "url": "https://git.kernel.org/stable/c/2026559a6c4ce34db117d2db8f710fe2a9420d5a"
        }
      ],
      "title": "nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint",
      "x_generator": {
        "engine": "bippy-8e903de6a542"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-53130",
    "datePublished": "2024-12-04T14:20:36.741Z",
    "dateReserved": "2024-11-19T17:17:24.995Z",
    "dateUpdated": "2024-12-05T11:30:04.464Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-53130\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-12-04T15:15:12.927\",\"lastModified\":\"2024-12-11T15:01:08.660\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nnilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint\\n\\nWhen using the \\\"block:block_dirty_buffer\\\" tracepoint, mark_buffer_dirty()\\nmay cause a NULL pointer dereference, or a general protection fault when\\nKASAN is enabled.\\n\\nThis happens because, since the tracepoint was added in\\nmark_buffer_dirty(), it references the dev_t member bh-\u003eb_bdev-\u003ebd_dev\\nregardless of whether the buffer head has a pointer to a block_device\\nstructure.\\n\\nIn the current implementation, nilfs_grab_buffer(), which grabs a buffer\\nto read (or create) a block of metadata, including b-tree node blocks,\\ndoes not set the block device, but instead does so only if the buffer is\\nnot in the \\\"uptodate\\\" state for each of its caller block reading\\nfunctions.  However, if the uptodate flag is set on a folio/page, and the\\nbuffer heads are detached from it by try_to_free_buffers(), and new buffer\\nheads are then attached by create_empty_buffers(), the uptodate flag may\\nbe restored to each buffer without the block device being set to\\nbh-\u003eb_bdev, and mark_buffer_dirty() may be called later in that state,\\nresulting in the bug mentioned above.\\n\\nFix this issue by making nilfs_grab_buffer() always set the block device\\nof the super block structure to the buffer head, regardless of the state\\nof the buffer\u0027s uptodate flag.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: correcci\u00f3n de null-ptr-deref en el punto de seguimiento block_dirty_buffer Al utilizar el punto de seguimiento \\\"block:block_dirty_buffer\\\", mark_buffer_dirty() puede provocar una desreferencia de puntero NULL o un fallo de protecci\u00f3n general cuando KASAN est\u00e1 habilitado. Esto sucede porque, dado que el punto de seguimiento se agreg\u00f3 en mark_buffer_dirty(), hace referencia al miembro dev_t bh-\u0026gt;b_bdev-\u0026gt;bd_dev independientemente de si el cabezal del b\u00fafer tiene un puntero a una estructura block_device. En la implementaci\u00f3n actual, nilfs_grab_buffer(), que toma un b\u00fafer para leer (o crear) un bloque de metadatos, incluidos los bloques de nodos de \u00e1rbol b, no establece el dispositivo de bloque, sino que lo hace solo si el b\u00fafer no est\u00e1 en el estado \\\"uptodate\\\" para cada una de sus funciones de lectura de bloque de llamada. Sin embargo, si el indicador uptodate est\u00e1 configurado en un folio/p\u00e1gina, y los cabezales de b\u00fafer se separan de \u00e9l mediante try_to_free_buffers(), y luego se adjuntan nuevos cabezales de b\u00fafer mediante create_empty_buffers(), el indicador uptodate puede restaurarse en cada b\u00fafer sin que el dispositivo de bloque se configure en bh-\u0026gt;b_bdev, y mark_buffer_dirty() puede llamarse m\u00e1s tarde en ese estado, lo que da como resultado el error mencionado anteriormente. Solucione este problema haciendo que nilfs_grab_buffer() siempre configure el dispositivo de bloque de la estructura de superbloque en el cabezal de b\u00fafer, independientemente del estado del indicador uptodate del b\u00fafer.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-476\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"3.9\",\"versionEndExcluding\":\"6.1.119\",\"matchCriteriaId\":\"B9F07E74-2989-4705-AED1-FEACA2FEF716\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.6.0\",\"versionEndExcluding\":\"6.6.63\",\"matchCriteriaId\":\"DC8AE946-6593-4D8D-863A-0BC137CF667F\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.11.0\",\"versionEndExcluding\":\"6.11.10\",\"matchCriteriaId\":\"5D7D3F96-FD78-48BB-9935-3CD41775FEAA\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/2026559a6c4ce34db117d2db8f710fe2a9420d5a\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/7af3309c7a2ef26831a67125b11c34a7e01c1b2a\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/86b19031dbc79abc378dfae357f6ea33ebeb0c95\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b0e4765740040c44039282057ecacd7435d1d2ba\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/ffc440a76a0f476a7e6ea838ec0dc8e9979944d1\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}"
  }
}


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.