fkie_cve-2022-49936
Vulnerability from fkie_nvd
Published
2025-06-18 11:15
Modified
2025-06-18 13:46
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: USB: core: Prevent nested device-reset calls Automatic kernel fuzzing revealed a recursive locking violation in usb-storage: ============================================ WARNING: possible recursive locking detected 5.18.0 #3 Not tainted -------------------------------------------- kworker/1:3/1205 is trying to acquire lock: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 but task is already holding lock: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 ... stack backtrace: CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2988 [inline] check_deadlock kernel/locking/lockdep.c:3031 [inline] validate_chain kernel/locking/lockdep.c:3816 [inline] __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053 lock_acquire kernel/locking/lockdep.c:5665 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630 __mutex_lock_common kernel/locking/mutex.c:603 [inline] __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747 usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109 r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622 usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458 device_remove drivers/base/dd.c:545 [inline] device_remove+0x11f/0x170 drivers/base/dd.c:537 __device_release_driver drivers/base/dd.c:1222 [inline] device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248 usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627 usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118 usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114 This turned out not to be an error in usb-storage but rather a nested device reset attempt. That is, as the rtl8712 driver was being unbound from a composite device in preparation for an unrelated USB reset (that driver does not have pre_reset or post_reset callbacks), its ->remove routine called usb_reset_device() -- thus nesting one reset call within another. Performing a reset as part of disconnect processing is a questionable practice at best. However, the bug report points out that the USB core does not have any protection against nested resets. Adding a reset_in_progress flag and testing it will prevent such errors in the future.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/1b29498669914c7f9afb619722421418a753d372
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9c6d778800b921bde3bff3cff5003d1650f942d1
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/abe3cfb7a7c8e907b312c7dbd7bf4d142b745aa8
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/c548b99e1c37db6f7df86ecfe9a1f895d6c5966e
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/cc9a12e12808af178c600cc485338bac2e37d2a8
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/d5eb850b3e8836197a38475840725260b9783e94
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/d90419b8b8322b6924f6da9da952647f2dadc21b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/df1875084898b15cbc42f712e93d7f113ae6271b
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Prevent nested device-reset calls\n\nAutomatic kernel fuzzing revealed a recursive locking violation in\nusb-storage:\n\n============================================\nWARNING: possible recursive locking detected\n5.18.0 #3 Not tainted\n--------------------------------------------\nkworker/1:3/1205 is trying to acquire lock:\nffff888018638db8 (\u0026us_interface_key[i]){+.+.}-{3:3}, at:\nusb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230\n\nbut task is already holding lock:\nffff888018638db8 (\u0026us_interface_key[i]){+.+.}-{3:3}, at:\nusb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230\n\n...\n\nstack backtrace:\nCPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.13.0-1ubuntu1.1 04/01/2014\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n\u003cTASK\u003e\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\nprint_deadlock_bug kernel/locking/lockdep.c:2988 [inline]\ncheck_deadlock kernel/locking/lockdep.c:3031 [inline]\nvalidate_chain kernel/locking/lockdep.c:3816 [inline]\n__lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053\nlock_acquire kernel/locking/lockdep.c:5665 [inline]\nlock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630\n__mutex_lock_common kernel/locking/mutex.c:603 [inline]\n__mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747\nusb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230\nusb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109\nr871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622\nusb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458\ndevice_remove drivers/base/dd.c:545 [inline]\ndevice_remove+0x11f/0x170 drivers/base/dd.c:537\n__device_release_driver drivers/base/dd.c:1222 [inline]\ndevice_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248\nusb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627\nusb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118\nusb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114\n\nThis turned out not to be an error in usb-storage but rather a nested\ndevice reset attempt.  That is, as the rtl8712 driver was being\nunbound from a composite device in preparation for an unrelated USB\nreset (that driver does not have pre_reset or post_reset callbacks),\nits -\u003eremove routine called usb_reset_device() -- thus nesting one\nreset call within another.\n\nPerforming a reset as part of disconnect processing is a questionable\npractice at best.  However, the bug report points out that the USB\ncore does not have any protection against nested resets.  Adding a\nreset_in_progress flag and testing it will prevent such errors in the\nfuture."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: n\u00facleo: evitar llamadas de reinicio de dispositivo anidadas. El fuzzing autom\u00e1tico del kernel revel\u00f3 una violaci\u00f3n de bloqueo recursivo en usb-storage: ============================================== ADVERTENCIA: posible bloqueo recursivo detectado 5.18.0 #3 No contaminado -------------------------------------------- kworker/1:3/1205 est\u00e1 intentando adquirir el bloqueo: ffff888018638db8 (\u0026amp;us_interface_key[i]){+.+.}-{3:3}, en: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 pero la tarea ya est\u00e1 manteniendo el bloqueo: ffff888018638db8 (\u0026amp;us_interface_key[i]){+.+.}-{3:3}, en: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 ... seguimiento de pila: CPU: 1 PID: 1205 Comm: kworker/1:3 No contaminado 5.18.0 #3 Nombre de hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Cola de trabajo: usb_hub_wq hub_event Seguimiento de llamadas:  __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2988 [inline] check_deadlock kernel/locking/lockdep.c:3031 [inline] validate_chain kernel/locking/lockdep.c:3816 [inline] __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053 lock_acquire kernel/locking/lockdep.c:5665 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630 __mutex_lock_common kernel/locking/mutex.c:603 [inline] __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747 usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109 r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622 usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458 device_remove drivers/base/dd.c:545 [inline] device_remove+0x11f/0x170 drivers/base/dd.c:537 __device_release_driver drivers/base/dd.c:1222 [inline] device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248 usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627 usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118 usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114 Result\u00f3 que esto no era un error en usb-storage sino m\u00e1s bien un intento de reinicio de dispositivo anidado. Es decir, como el controlador rtl8712 se estaba desvinculando de un dispositivo compuesto en preparaci\u00f3n para un reinicio USB no relacionado (ese controlador no tiene devoluciones de llamada pre_reset o post_reset), su rutina -\u0026gt;remove llam\u00f3 a usb_reset_device() - anidando as\u00ed una llamada de reinicio dentro de otra. Realizar un reinicio como parte del procesamiento de desconexi\u00f3n es una pr\u00e1ctica cuestionable en el mejor de los casos. Sin embargo, el informe de errores se\u00f1ala que el n\u00facleo USB no tiene ninguna protecci\u00f3n contra reinicios anidados. Agregar un indicador reset_in_progress y probarlo evitar\u00e1 tales errores en el futuro. "
    }
  ],
  "id": "CVE-2022-49936",
  "lastModified": "2025-06-18T13:46:52.973",
  "metrics": {},
  "published": "2025-06-18T11:15:20.450",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/1b29498669914c7f9afb619722421418a753d372"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/9c6d778800b921bde3bff3cff5003d1650f942d1"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/abe3cfb7a7c8e907b312c7dbd7bf4d142b745aa8"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c548b99e1c37db6f7df86ecfe9a1f895d6c5966e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/cc9a12e12808af178c600cc485338bac2e37d2a8"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/d5eb850b3e8836197a38475840725260b9783e94"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/d90419b8b8322b6924f6da9da952647f2dadc21b"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/df1875084898b15cbc42f712e93d7f113ae6271b"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


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.