ghsa-r47r-3q5h-27v7
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
HID: hyperv: streamline driver probe to avoid devres issues
It was found that unloading 'hid_hyperv' module results in a devres complaint:
... hv_vmbus: unregistering driver hid_hyperv ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0 ... Call Trace: ? devres_release_group+0x1f2/0x2c0 ? __warn+0xd1/0x1c0 ? devres_release_group+0x1f2/0x2c0 ? report_bug+0x32a/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? devres_release_group+0x1f2/0x2c0 ? devres_release_group+0x90/0x2c0 ? rcu_is_watching+0x15/0xb0 ? __pfx_devres_release_group+0x10/0x10 hid_device_remove+0xf5/0x220 device_release_driver_internal+0x371/0x540 ? klist_put+0xf3/0x170 bus_remove_device+0x1f1/0x3f0 device_del+0x33f/0x8c0 ? __pfx_device_del+0x10/0x10 ? cleanup_srcu_struct+0x337/0x500 hid_destroy_device+0xc8/0x130 mousevsc_remove+0xd2/0x1d0 [hid_hyperv] device_release_driver_internal+0x371/0x540 driver_detach+0xc5/0x180 bus_remove_driver+0x11e/0x2a0 ? __mutex_unlock_slowpath+0x160/0x5e0 vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus] ...
And the issue seems to be that the corresponding devres group is not allocated. Normally, devres_open_group() is called from __hid_device_probe() but Hyper-V HID driver overrides 'hid_dev->driver' with 'mousevsc_hid_driver' stub and basically re-implements __hid_device_probe() by calling hid_parse() and hid_hw_start() but not devres_open_group(). hid_device_probe() does not call __hid_device_probe() for it. Later, when the driver is removed, hid_device_remove() calls devres_release_group() as it doesn't check whether hdev->driver was initially overridden or not.
The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure timely release of driver-allocated resources") but the commit itself seems to be correct.
Fix the issue by dropping the 'hid_dev->driver' override and using hid_register_driver()/hid_unregister_driver() instead. Alternatively, it would have been possible to rely on the default handling but HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn't seem to work for mousevsc as-is.
{
"affected": [],
"aliases": [
"CVE-2024-56545"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:34Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: hyperv: streamline driver probe to avoid devres issues\n\nIt was found that unloading \u0027hid_hyperv\u0027 module results in a devres\ncomplaint:\n\n ...\n hv_vmbus: unregistering driver hid_hyperv\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0\n ...\n Call Trace:\n \u003cTASK\u003e\n ? devres_release_group+0x1f2/0x2c0\n ? __warn+0xd1/0x1c0\n ? devres_release_group+0x1f2/0x2c0\n ? report_bug+0x32a/0x3c0\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x18/0x50\n ? asm_exc_invalid_op+0x1a/0x20\n ? devres_release_group+0x1f2/0x2c0\n ? devres_release_group+0x90/0x2c0\n ? rcu_is_watching+0x15/0xb0\n ? __pfx_devres_release_group+0x10/0x10\n hid_device_remove+0xf5/0x220\n device_release_driver_internal+0x371/0x540\n ? klist_put+0xf3/0x170\n bus_remove_device+0x1f1/0x3f0\n device_del+0x33f/0x8c0\n ? __pfx_device_del+0x10/0x10\n ? cleanup_srcu_struct+0x337/0x500\n hid_destroy_device+0xc8/0x130\n mousevsc_remove+0xd2/0x1d0 [hid_hyperv]\n device_release_driver_internal+0x371/0x540\n driver_detach+0xc5/0x180\n bus_remove_driver+0x11e/0x2a0\n ? __mutex_unlock_slowpath+0x160/0x5e0\n vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus]\n ...\n\nAnd the issue seems to be that the corresponding devres group is not\nallocated. Normally, devres_open_group() is called from\n__hid_device_probe() but Hyper-V HID driver overrides \u0027hid_dev-\u003edriver\u0027\nwith \u0027mousevsc_hid_driver\u0027 stub and basically re-implements\n__hid_device_probe() by calling hid_parse() and hid_hw_start() but not\ndevres_open_group(). hid_device_probe() does not call __hid_device_probe()\nfor it. Later, when the driver is removed, hid_device_remove() calls\ndevres_release_group() as it doesn\u0027t check whether hdev-\u003edriver was\ninitially overridden or not.\n\nThe issue seems to be related to the commit 62c68e7cee33 (\"HID: ensure\ntimely release of driver-allocated resources\") but the commit itself seems\nto be correct.\n\nFix the issue by dropping the \u0027hid_dev-\u003edriver\u0027 override and using\nhid_register_driver()/hid_unregister_driver() instead. Alternatively, it\nwould have been possible to rely on the default handling but\nHID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn\u0027t seem to work\nfor mousevsc as-is.",
"id": "GHSA-r47r-3q5h-27v7",
"modified": "2024-12-27T15:31:53Z",
"published": "2024-12-27T15:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56545"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19a9457e5e210e408c1f8865b5d93c5a2c90409d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d48d0fbaaa74a04fb9092780a3f83dc4f3f8160"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66ef47faa90d838cda131fe1f7776456cc3b59f2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b03e713a400aeb5f969bab4daf47a7402d0df814"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.