FKIE_CVE-2025-71079

Vulnerability from fkie_nvd - Published: 2026-01-13 16:16 - Updated: 2026-01-14 16:26
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write A deadlock can occur between nfc_unregister_device() and rfkill_fop_write() due to lock ordering inversion between device_lock and rfkill_global_mutex. The problematic lock order is: Thread A (rfkill_fop_write): rfkill_fop_write() mutex_lock(&rfkill_global_mutex) rfkill_set_block() nfc_rfkill_set_block() nfc_dev_down() device_lock(&dev->dev) <- waits for device_lock Thread B (nfc_unregister_device): nfc_unregister_device() device_lock(&dev->dev) rfkill_unregister() mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutex This creates a classic ABBA deadlock scenario. Fix this by moving rfkill_unregister() and rfkill_destroy() outside the device_lock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkill_unregister() after releasing device_lock. This change is safe because rfkill_fop_write() holds rfkill_global_mutex while calling the rfkill callbacks, and rfkill_unregister() also acquires rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will wait for any ongoing callback to complete before proceeding, and device_del() is only called after rfkill_unregister() returns, preventing any use-after-free. The similar lock ordering in nfc_register_device() (device_lock -> rfkill_global_mutex via rfkill_register) is safe because during registration the device is not yet in rfkill_list, so no concurrent rfkill operations can occur on this device.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/6b93c8ab6f6cda8818983a4ae3fcf84b023037b4
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/8fc4632fb508432895430cd02b38086bdd649083
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/ee41f4f3ccf8cd6ba3732e867abbec7e6d8d12e5
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/f3a8a7c1aa278f2378b2f3a10500c6674dffdfda
Impacted products
Vendor Product Version
To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write\n\nA deadlock can occur between nfc_unregister_device() and rfkill_fop_write()\ndue to lock ordering inversion between device_lock and rfkill_global_mutex.\n\nThe problematic lock order is:\n\nThread A (rfkill_fop_write):\n  rfkill_fop_write()\n    mutex_lock(\u0026rfkill_global_mutex)\n      rfkill_set_block()\n        nfc_rfkill_set_block()\n          nfc_dev_down()\n            device_lock(\u0026dev-\u003edev)    \u003c- waits for device_lock\n\nThread B (nfc_unregister_device):\n  nfc_unregister_device()\n    device_lock(\u0026dev-\u003edev)\n      rfkill_unregister()\n        mutex_lock(\u0026rfkill_global_mutex)  \u003c- waits for rfkill_global_mutex\n\nThis creates a classic ABBA deadlock scenario.\n\nFix this by moving rfkill_unregister() and rfkill_destroy() outside the\ndevice_lock critical section. Store the rfkill pointer in a local variable\nbefore releasing the lock, then call rfkill_unregister() after releasing\ndevice_lock.\n\nThis change is safe because rfkill_fop_write() holds rfkill_global_mutex\nwhile calling the rfkill callbacks, and rfkill_unregister() also acquires\nrfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will\nwait for any ongoing callback to complete before proceeding, and\ndevice_del() is only called after rfkill_unregister() returns, preventing\nany use-after-free.\n\nThe similar lock ordering in nfc_register_device() (device_lock -\u003e\nrfkill_global_mutex via rfkill_register) is safe because during\nregistration the device is not yet in rfkill_list, so no concurrent\nrfkill operations can occur on this device."
    }
  ],
  "id": "CVE-2025-71079",
  "lastModified": "2026-01-14T16:26:00.933",
  "metrics": {},
  "published": "2026-01-13T16:16:07.433",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/6b93c8ab6f6cda8818983a4ae3fcf84b023037b4"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/8fc4632fb508432895430cd02b38086bdd649083"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/ee41f4f3ccf8cd6ba3732e867abbec7e6d8d12e5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f3a8a7c1aa278f2378b2f3a10500c6674dffdfda"
    }
  ],
  "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 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.



Detection rules are retrieved from Rulezet.