CVE-2022-50202 (GCVE-0-2022-50202)
Vulnerability from cvelistv5
Published
2025-06-18 11:03
Modified
2025-06-18 11:03
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: PM: hibernate: defer device probing when resuming from hibernation syzbot is reporting hung task at misc_open() [1], for there is a race window of AB-BA deadlock which involves probe_count variable. Currently wait_for_device_probe() from snapshot_open() from misc_open() can sleep forever with misc_mtx held if probe_count cannot become 0. When a device is probed by hub_event() work function, probe_count is incremented before the probe function starts, and probe_count is decremented after the probe function completed. There are three cases that can prevent probe_count from dropping to 0. (a) A device being probed stopped responding (i.e. broken/malicious hardware). (b) A process emulating a USB device using /dev/raw-gadget interface stopped responding for some reason. (c) New device probe requests keeps coming in before existing device probe requests complete. The phenomenon syzbot is reporting is (b). A process which is holding system_transition_mutex and misc_mtx is waiting for probe_count to become 0 inside wait_for_device_probe(), but the probe function which is called from hub_event() work function is waiting for the processes which are blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface. This patch mitigates (b) by deferring wait_for_device_probe() from snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that the possibility of (b) remains as long as any thread which is emulating a USB device via /dev/raw-gadget interface can be blocked by uninterruptible blocking operations (e.g. mutex_lock()). Please also note that (a) and (c) are not addressed. Regarding (c), we should change the code to wait for only one device which contains the image for resuming from hibernation. I don't know how to address (a), for use of timeout for wait_for_device_probe() might result in loss of user data in the image. Maybe we should require the userland to wait for the image device before opening /dev/snapshot interface.
Impacted products
Vendor Product Version
Linux Linux Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Create a notification for this product.
Show details on NVD website


{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/power/user.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "8c90947e5f1801e6c7120021c6ea0f3ad6a4eb91",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "5a283b59bce72c05c60e9f0fa92a28b5b850d8bb",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "3c48d3067eaf878642276f053575a5c642600a50",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "003a456ae6f70bb97e436e02fc5105be577c1570",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "2f0e18e0db42f4f8bc87d3d98333680065ceeff8",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "b8e1ae9433d7bd95f2dcc044a7a6f20a4c40d258",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "f7042cf9dd40733f387b7cac021e626c74b8856f",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "8386c414e27caba8501119948e9551e52b527f59",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/power/user.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThanOrEqual": "4.14.*",
              "status": "unaffected",
              "version": "4.14.291",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.256",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.211",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.137",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.61",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.18.*",
              "status": "unaffected",
              "version": "5.18.18",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.19.*",
              "status": "unaffected",
              "version": "5.19.2",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.0",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.14.291",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.19.256",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.4.211",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.137",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.61",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.18.18",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.19.2",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nPM: hibernate: defer device probing when resuming from hibernation\n\nsyzbot is reporting hung task at misc_open() [1], for there is a race\nwindow of AB-BA deadlock which involves probe_count variable. Currently\nwait_for_device_probe() from snapshot_open() from misc_open() can sleep\nforever with misc_mtx held if probe_count cannot become 0.\n\nWhen a device is probed by hub_event() work function, probe_count is\nincremented before the probe function starts, and probe_count is\ndecremented after the probe function completed.\n\nThere are three cases that can prevent probe_count from dropping to 0.\n\n  (a) A device being probed stopped responding (i.e. broken/malicious\n      hardware).\n\n  (b) A process emulating a USB device using /dev/raw-gadget interface\n      stopped responding for some reason.\n\n  (c) New device probe requests keeps coming in before existing device\n      probe requests complete.\n\nThe phenomenon syzbot is reporting is (b). A process which is holding\nsystem_transition_mutex and misc_mtx is waiting for probe_count to become\n0 inside wait_for_device_probe(), but the probe function which is called\n from hub_event() work function is waiting for the processes which are\nblocked at mutex_lock(\u0026misc_mtx) to respond via /dev/raw-gadget interface.\n\nThis patch mitigates (b) by deferring wait_for_device_probe() from\nsnapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that\nthe possibility of (b) remains as long as any thread which is emulating a\nUSB device via /dev/raw-gadget interface can be blocked by uninterruptible\nblocking operations (e.g. mutex_lock()).\n\nPlease also note that (a) and (c) are not addressed. Regarding (c), we\nshould change the code to wait for only one device which contains the\nimage for resuming from hibernation. I don\u0027t know how to address (a), for\nuse of timeout for wait_for_device_probe() might result in loss of user\ndata in the image. Maybe we should require the userland to wait for the\nimage device before opening /dev/snapshot interface."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-06-18T11:03:43.874Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/8c90947e5f1801e6c7120021c6ea0f3ad6a4eb91"
        },
        {
          "url": "https://git.kernel.org/stable/c/5a283b59bce72c05c60e9f0fa92a28b5b850d8bb"
        },
        {
          "url": "https://git.kernel.org/stable/c/3c48d3067eaf878642276f053575a5c642600a50"
        },
        {
          "url": "https://git.kernel.org/stable/c/003a456ae6f70bb97e436e02fc5105be577c1570"
        },
        {
          "url": "https://git.kernel.org/stable/c/2f0e18e0db42f4f8bc87d3d98333680065ceeff8"
        },
        {
          "url": "https://git.kernel.org/stable/c/b8e1ae9433d7bd95f2dcc044a7a6f20a4c40d258"
        },
        {
          "url": "https://git.kernel.org/stable/c/f7042cf9dd40733f387b7cac021e626c74b8856f"
        },
        {
          "url": "https://git.kernel.org/stable/c/8386c414e27caba8501119948e9551e52b527f59"
        }
      ],
      "title": "PM: hibernate: defer device probing when resuming from hibernation",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2022-50202",
    "datePublished": "2025-06-18T11:03:43.874Z",
    "dateReserved": "2025-06-18T10:57:27.428Z",
    "dateUpdated": "2025-06-18T11:03:43.874Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2022-50202\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-06-18T11:15:50.923\",\"lastModified\":\"2025-06-18T13:47:40.833\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nPM: hibernate: defer device probing when resuming from hibernation\\n\\nsyzbot is reporting hung task at misc_open() [1], for there is a race\\nwindow of AB-BA deadlock which involves probe_count variable. Currently\\nwait_for_device_probe() from snapshot_open() from misc_open() can sleep\\nforever with misc_mtx held if probe_count cannot become 0.\\n\\nWhen a device is probed by hub_event() work function, probe_count is\\nincremented before the probe function starts, and probe_count is\\ndecremented after the probe function completed.\\n\\nThere are three cases that can prevent probe_count from dropping to 0.\\n\\n  (a) A device being probed stopped responding (i.e. broken/malicious\\n      hardware).\\n\\n  (b) A process emulating a USB device using /dev/raw-gadget interface\\n      stopped responding for some reason.\\n\\n  (c) New device probe requests keeps coming in before existing device\\n      probe requests complete.\\n\\nThe phenomenon syzbot is reporting is (b). A process which is holding\\nsystem_transition_mutex and misc_mtx is waiting for probe_count to become\\n0 inside wait_for_device_probe(), but the probe function which is called\\n from hub_event() work function is waiting for the processes which are\\nblocked at mutex_lock(\u0026misc_mtx) to respond via /dev/raw-gadget interface.\\n\\nThis patch mitigates (b) by deferring wait_for_device_probe() from\\nsnapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that\\nthe possibility of (b) remains as long as any thread which is emulating a\\nUSB device via /dev/raw-gadget interface can be blocked by uninterruptible\\nblocking operations (e.g. mutex_lock()).\\n\\nPlease also note that (a) and (c) are not addressed. Regarding (c), we\\nshould change the code to wait for only one device which contains the\\nimage for resuming from hibernation. I don\u0027t know how to address (a), for\\nuse of timeout for wait_for_device_probe() might result in loss of user\\ndata in the image. Maybe we should require the userland to wait for the\\nimage device before opening /dev/snapshot interface.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: hibernar: aplazar el sondeo del dispositivo al reanudar desde la hibernaci\u00f3n syzbot informa una tarea colgada en misc_open() [1], ya que hay una ventana de ejecuci\u00f3n de punto muerto AB-BA que involucra a la variable probe_count. Actualmente, wait_for_device_probe() de snapshot_open() de misc_open() puede dormir para siempre con misc_mtx retenido si probe_count no puede llegar a 0. Cuando un dispositivo es sondeado por la funci\u00f3n de trabajo hub_event(), probe_count se incrementa antes de que comience la funci\u00f3n de sondeo y probe_count se decrementa despu\u00e9s de que la funci\u00f3n de sondeo se complete. Hay tres casos que pueden evitar que probe_count caiga a 0. (a) Un dispositivo que se est\u00e1 sondeando dej\u00f3 de responder (es decir, hardware roto/malicioso). (b) Un proceso que emula un dispositivo USB usando la interfaz /dev/raw-gadget dej\u00f3 de responder por alguna raz\u00f3n. (c) Siguen llegando nuevas solicitudes de sondeo de dispositivo antes de que se completen las solicitudes de sondeo de dispositivo existentes. El fen\u00f3meno que syzbot reporta es (b). Un proceso que contiene system_transition_mutex y misc_mtx espera a que probe_count sea 0 dentro de wait_for_device_probe(), pero la funci\u00f3n de sonda, llamada desde la funci\u00f3n de trabajo hub_event(), espera a que los procesos bloqueados en mutex_lock(\u0026amp;misc_mtx) respondan mediante la interfaz /dev/raw-gadget. Este parche mitiga (b) al posponer wait_for_device_probe() de snapshot_open() a snapshot_write() y snapshot_ioctl(). Tenga en cuenta que la posibilidad de (b) persiste mientras cualquier hilo que emule un dispositivo USB mediante la interfaz /dev/raw-gadget pueda ser bloqueado por operaciones de bloqueo ininterrumpido (p. ej., mutex_lock()). Tenga en cuenta tambi\u00e9n que (a) y (c) no se abordan. Respecto a (c), debemos modificar el c\u00f3digo para que espere solo a un dispositivo que contenga la imagen para reanudar la hibernaci\u00f3n. No s\u00e9 c\u00f3mo abordar (a), ya que el uso del tiempo de espera para wait_for_device_probe() podr\u00eda provocar la p\u00e9rdida de datos de usuario en la imagen. Quiz\u00e1s deber\u00edamos exigir que el espacio de usuario espere al dispositivo de imagen antes de abrir la interfaz /dev/snapshot.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/003a456ae6f70bb97e436e02fc5105be577c1570\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/2f0e18e0db42f4f8bc87d3d98333680065ceeff8\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/3c48d3067eaf878642276f053575a5c642600a50\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/5a283b59bce72c05c60e9f0fa92a28b5b850d8bb\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/8386c414e27caba8501119948e9551e52b527f59\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/8c90947e5f1801e6c7120021c6ea0f3ad6a4eb91\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/b8e1ae9433d7bd95f2dcc044a7a6f20a4c40d258\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/f7042cf9dd40733f387b7cac021e626c74b8856f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


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.


Loading…

Loading…