CVE-2025-21807 (GCVE-0-2025-21807)
Vulnerability from cvelistv5
Published
2025-02-27 20:00
Modified
2025-05-04 07:21
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: block: fix queue freeze vs limits lock order in sysfs store methods queue_attr_store() always freezes a device queue before calling the attribute store operation. For attributes that control queue limits, the store operation will also lock the queue limits with a call to queue_limits_start_update(). However, some drivers (e.g. SCSI sd) may need to issue commands to a device to obtain limit values from the hardware with the queue limits locked. This creates a potential ABBA deadlock situation if a user attempts to modify a limit (thus freezing the device queue) while the device driver starts a revalidation of the device queue limits. Avoid such deadlock by not freezing the queue before calling the ->store_limit() method in struct queue_sysfs_entry and instead use the queue_limits_commit_update_frozen helper to freeze the queue after taking the limits lock. This also removes taking the sysfs lock for the store_limit method as it doesn't protect anything here, but creates even more nesting. Hopefully it will go away from the actual sysfs methods entirely soon. (commit log adapted from a similar patch from Damien Le Moal)
References
Impacted products
Vendor Product Version
Linux Linux Version: 0327ca9d53bfbb0918867313049bba7046900f73
Version: 0327ca9d53bfbb0918867313049bba7046900f73
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "block/blk-sysfs.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "8985da5481562e96b95e94ed8e5cc9b6565eb82b",
              "status": "affected",
              "version": "0327ca9d53bfbb0918867313049bba7046900f73",
              "versionType": "git"
            },
            {
              "lessThan": "c99f66e4084a62a2cc401c4704a84328aeddc9ec",
              "status": "affected",
              "version": "0327ca9d53bfbb0918867313049bba7046900f73",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "block/blk-sysfs.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.9"
            },
            {
              "lessThan": "6.9",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.13.*",
              "status": "unaffected",
              "version": "6.13.2",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.14",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.13.2",
                  "versionStartIncluding": "6.9",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.14",
                  "versionStartIncluding": "6.9",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix queue freeze vs limits lock order in sysfs store methods\n\nqueue_attr_store() always freezes a device queue before calling the\nattribute store operation. For attributes that control queue limits, the\nstore operation will also lock the queue limits with a call to\nqueue_limits_start_update(). However, some drivers (e.g. SCSI sd) may\nneed to issue commands to a device to obtain limit values from the\nhardware with the queue limits locked. This creates a potential ABBA\ndeadlock situation if a user attempts to modify a limit (thus freezing\nthe device queue) while the device driver starts a revalidation of the\ndevice queue limits.\n\nAvoid such deadlock by not freezing the queue before calling the\n-\u003estore_limit() method in struct queue_sysfs_entry and instead use the\nqueue_limits_commit_update_frozen helper to freeze the queue after taking\nthe limits lock.\n\nThis also removes taking the sysfs lock for the store_limit method as\nit doesn\u0027t protect anything here, but creates even more nesting.\nHopefully it will go away from the actual sysfs methods entirely soon.\n\n(commit log adapted from a similar patch from  Damien Le Moal)"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-04T07:21:37.603Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/8985da5481562e96b95e94ed8e5cc9b6565eb82b"
        },
        {
          "url": "https://git.kernel.org/stable/c/c99f66e4084a62a2cc401c4704a84328aeddc9ec"
        }
      ],
      "title": "block: fix queue freeze vs limits lock order in sysfs store methods",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-21807",
    "datePublished": "2025-02-27T20:00:59.560Z",
    "dateReserved": "2024-12-29T08:45:45.772Z",
    "dateUpdated": "2025-05-04T07:21:37.603Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-21807\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-02-27T20:16:03.317\",\"lastModified\":\"2025-02-27T20:16:03.317\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nblock: fix queue freeze vs limits lock order in sysfs store methods\\n\\nqueue_attr_store() always freezes a device queue before calling the\\nattribute store operation. For attributes that control queue limits, the\\nstore operation will also lock the queue limits with a call to\\nqueue_limits_start_update(). However, some drivers (e.g. SCSI sd) may\\nneed to issue commands to a device to obtain limit values from the\\nhardware with the queue limits locked. This creates a potential ABBA\\ndeadlock situation if a user attempts to modify a limit (thus freezing\\nthe device queue) while the device driver starts a revalidation of the\\ndevice queue limits.\\n\\nAvoid such deadlock by not freezing the queue before calling the\\n-\u003estore_limit() method in struct queue_sysfs_entry and instead use the\\nqueue_limits_commit_update_frozen helper to freeze the queue after taking\\nthe limits lock.\\n\\nThis also removes taking the sysfs lock for the store_limit method as\\nit doesn\u0027t protect anything here, but creates even more nesting.\\nHopefully it will go away from the actual sysfs methods entirely soon.\\n\\n(commit log adapted from a similar patch from  Damien Le Moal)\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: fix queue freeze vs limits lock order in sysfs store methods queue_attr_store() siempre congela una cola de dispositivos antes de llamar a la operaci\u00f3n de almacenamiento de atributos. Para los atributos que controlan los l\u00edmites de la cola, la operaci\u00f3n de almacenamiento tambi\u00e9n bloquear\u00e1 los l\u00edmites de la cola con una llamada a queue_limits_start_update(). Sin embargo, algunos controladores (por ejemplo, SCSI sd) pueden necesitar emitir comandos a un dispositivo para obtener valores l\u00edmite del hardware con los l\u00edmites de la cola bloqueados. Esto crea una posible situaci\u00f3n de bloqueo ABBA si un usuario intenta modificar un l\u00edmite (congelando as\u00ed la cola del dispositivo) mientras el controlador del dispositivo inicia una revalidaci\u00f3n de los l\u00edmites de la cola del dispositivo. Evite dicho bloqueo al no congelar la cola antes de llamar al m\u00e9todo -\u0026gt;store_limit() en struct queue_sysfs_entry y, en su lugar, utilice el asistente queue_limits_commit_update_frozen para congelar la cola despu\u00e9s de tomar el bloqueo de los l\u00edmites. Esto tambi\u00e9n elimina la posibilidad de tomar el bloqueo de sysfs para el m\u00e9todo store_limit, ya que no protege nada aqu\u00ed, pero crea a\u00fan m\u00e1s anidamiento. Con suerte, desaparecer\u00e1 por completo de los m\u00e9todos sysfs reales pronto. (registro de confirmaci\u00f3n adaptado de un parche similar de Damien Le Moal)\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/8985da5481562e96b95e94ed8e5cc9b6565eb82b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/c99f66e4084a62a2cc401c4704a84328aeddc9ec\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


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.
  • 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.