GSD-2024-26912

Vulnerability from gsd - Updated: 2024-02-20 06:02
Details
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix several DMA buffer leaks Nouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of these buffers are never dealloced. Some of them can be deallocated right after GSP-RM is initialized, but the rest need to stay until the driver unloads. Also futher bullet-proof these objects by poisoning the buffer and clearing the nvkm_gsp_mem object when it is deallocated. Poisoning the buffer should trigger an error (or crash) from GSP-RM if it tries to access the buffer after we've deallocated it, because we were wrong about when it is safe to deallocate. Finally, change the mem->size field to a size_t because that's the same type that dma_alloc_coherent expects.
Aliases

{
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "aliases": [
        "CVE-2024-26912"
      ],
      "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix several DMA buffer leaks\n\nNouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects.  Several of\nthese buffers are never dealloced.  Some of them can be deallocated\nright after GSP-RM is initialized, but the rest need to stay until the\ndriver unloads.\n\nAlso futher bullet-proof these objects by poisoning the buffer and\nclearing the nvkm_gsp_mem object when it is deallocated.  Poisoning\nthe buffer should trigger an error (or crash) from GSP-RM if it tries\nto access the buffer after we\u0027ve deallocated it, because we were wrong\nabout when it is safe to deallocate.\n\nFinally, change the mem-\u003esize field to a size_t because that\u0027s the same\ntype that dma_alloc_coherent expects.",
      "id": "GSD-2024-26912",
      "modified": "2024-02-20T06:02:29.111630Z",
      "schema_version": "1.4.0"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "cve@kernel.org",
        "ID": "CVE-2024-26912",
        "STATE": "PUBLIC"
      },
      "affects": {
        "vendor": {
          "vendor_data": [
            {
              "product": {
                "product_data": [
                  {
                    "product_name": "Linux",
                    "version": {
                      "version_data": [
                        {
                          "version_affected": "\u003c",
                          "version_name": "176fdcbddfd2",
                          "version_value": "6190d4c08897"
                        },
                        {
                          "version_value": "not down converted",
                          "x_cve_json_5_version_data": {
                            "defaultStatus": "affected",
                            "versions": [
                              {
                                "status": "affected",
                                "version": "6.7"
                              },
                              {
                                "lessThan": "6.7",
                                "status": "unaffected",
                                "version": "0",
                                "versionType": "custom"
                              },
                              {
                                "lessThanOrEqual": "6.7.*",
                                "status": "unaffected",
                                "version": "6.7.6",
                                "versionType": "custom"
                              },
                              {
                                "lessThanOrEqual": "*",
                                "status": "unaffected",
                                "version": "6.8",
                                "versionType": "original_commit_for_fix"
                              }
                            ]
                          }
                        }
                      ]
                    }
                  }
                ]
              },
              "vendor_name": "Linux"
            }
          ]
        }
      },
      "data_format": "MITRE",
      "data_type": "CVE",
      "data_version": "4.0",
      "description": {
        "description_data": [
          {
            "lang": "eng",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix several DMA buffer leaks\n\nNouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects.  Several of\nthese buffers are never dealloced.  Some of them can be deallocated\nright after GSP-RM is initialized, but the rest need to stay until the\ndriver unloads.\n\nAlso futher bullet-proof these objects by poisoning the buffer and\nclearing the nvkm_gsp_mem object when it is deallocated.  Poisoning\nthe buffer should trigger an error (or crash) from GSP-RM if it tries\nto access the buffer after we\u0027ve deallocated it, because we were wrong\nabout when it is safe to deallocate.\n\nFinally, change the mem-\u003esize field to a size_t because that\u0027s the same\ntype that dma_alloc_coherent expects."
          }
        ]
      },
      "generator": {
        "engine": "bippy-d175d3acf727"
      },
      "problemtype": {
        "problemtype_data": [
          {
            "description": [
              {
                "lang": "eng",
                "value": "n/a"
              }
            ]
          }
        ]
      },
      "references": {
        "reference_data": [
          {
            "name": "https://git.kernel.org/stable/c/6190d4c08897d748dd25f0b78267a90aa1694e15",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/6190d4c08897d748dd25f0b78267a90aa1694e15"
          },
          {
            "name": "https://git.kernel.org/stable/c/042b5f83841fbf7ce39474412db3b5e4765a7ea7",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/042b5f83841fbf7ce39474412db3b5e4765a7ea7"
          }
        ]
      }
    },
    "nvd.nist.gov": {
      "cve": {
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix several DMA buffer leaks\n\nNouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects.  Several of\nthese buffers are never dealloced.  Some of them can be deallocated\nright after GSP-RM is initialized, but the rest need to stay until the\ndriver unloads.\n\nAlso futher bullet-proof these objects by poisoning the buffer and\nclearing the nvkm_gsp_mem object when it is deallocated.  Poisoning\nthe buffer should trigger an error (or crash) from GSP-RM if it tries\nto access the buffer after we\u0027ve deallocated it, because we were wrong\nabout when it is safe to deallocate.\n\nFinally, change the mem-\u003esize field to a size_t because that\u0027s the same\ntype that dma_alloc_coherent expects."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: corrige varias fugas del b\u00fafer DMA Nouveau administra los buffers DMA GSP-RM con objetos nvkm_gsp_mem. Varios de estos b\u00faferes nunca se desasignan. Algunos de ellos se pueden desasignar inmediatamente despu\u00e9s de que se inicializa GSP-RM, pero el resto debe permanecer hasta que se descargue el controlador. Tambi\u00e9n proteja a\u00fan m\u00e1s estos objetos envenenando el b\u00fafer y limpiando el objeto nvkm_gsp_mem cuando se desasigna. El envenenamiento del b\u00fafer deber\u00eda provocar un error (o bloqueo) de GSP-RM si intenta acceder al b\u00fafer despu\u00e9s de haberlo desasignado, porque nos equivocamos acerca de cu\u00e1ndo es seguro desasignarlo. Finalmente, cambie el campo mem-\u0026gt;size a size_t porque es el mismo tipo que espera dma_alloc_coherent."
          }
        ],
        "id": "CVE-2024-26912",
        "lastModified": "2024-04-17T16:51:07.347",
        "metrics": {},
        "published": "2024-04-17T16:15:07.990",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/042b5f83841fbf7ce39474412db3b5e4765a7ea7"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/6190d4c08897d748dd25f0b78267a90aa1694e15"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Awaiting Analysis"
      }
    }
  }
}



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…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…