gsd-2021-46970
Vulnerability from gsd
Modified
2024-02-28 06:03
Details
In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue
A recent change created a dedicated workqueue for the state-change work
with WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags,
but the state-change work (mhi_pm_st_worker) does not guarantee forward
progress under memory pressure, and will even wait on various memory
allocations when e.g. creating devices, loading firmware, etc... The
work is then not part of a memory reclaim path...
Moreover, this causes a warning in check_flush_dependency() since we end
up in code that flushes a non-reclaim workqueue:
[ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog
[ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140
[ 40.969733] Call Trace:
[ 40.969740] __flush_work+0x97/0x1d0
[ 40.969745] ? wake_up_process+0x15/0x20
[ 40.969749] ? insert_work+0x70/0x80
[ 40.969750] ? __queue_work+0x14a/0x3e0
[ 40.969753] flush_work+0x10/0x20
[ 40.969756] rollback_registered_many+0x1c9/0x510
[ 40.969759] unregister_netdevice_queue+0x94/0x120
[ 40.969761] unregister_netdev+0x1d/0x30
[ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net]
[ 40.969770] mhi_driver_remove+0x124/0x250 [mhi]
[ 40.969776] device_release_driver_internal+0xf0/0x1d0
[ 40.969778] device_release_driver+0x12/0x20
[ 40.969782] bus_remove_device+0xe1/0x150
[ 40.969786] device_del+0x17b/0x3e0
[ 40.969791] mhi_destroy_device+0x9a/0x100 [mhi]
[ 40.969796] ? mhi_unmap_single_use_bb+0x50/0x50 [mhi]
[ 40.969799] device_for_each_child+0x5e/0xa0
[ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi]
Aliases
{ "gsd": { "metadata": { "exploitCode": "unknown", "remediation": "unknown", "reportConfidence": "confirmed", "type": "vulnerability" }, "osvSchema": { "aliases": [ "CVE-2021-46970" ], "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue\n\nA recent change created a dedicated workqueue for the state-change work\nwith WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags,\nbut the state-change work (mhi_pm_st_worker) does not guarantee forward\nprogress under memory pressure, and will even wait on various memory\nallocations when e.g. creating devices, loading firmware, etc... The\nwork is then not part of a memory reclaim path...\n\nMoreover, this causes a warning in check_flush_dependency() since we end\nup in code that flushes a non-reclaim workqueue:\n\n[ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog\n[ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140\n[ 40.969733] Call Trace:\n[ 40.969740] __flush_work+0x97/0x1d0\n[ 40.969745] ? wake_up_process+0x15/0x20\n[ 40.969749] ? insert_work+0x70/0x80\n[ 40.969750] ? __queue_work+0x14a/0x3e0\n[ 40.969753] flush_work+0x10/0x20\n[ 40.969756] rollback_registered_many+0x1c9/0x510\n[ 40.969759] unregister_netdevice_queue+0x94/0x120\n[ 40.969761] unregister_netdev+0x1d/0x30\n[ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net]\n[ 40.969770] mhi_driver_remove+0x124/0x250 [mhi]\n[ 40.969776] device_release_driver_internal+0xf0/0x1d0\n[ 40.969778] device_release_driver+0x12/0x20\n[ 40.969782] bus_remove_device+0xe1/0x150\n[ 40.969786] device_del+0x17b/0x3e0\n[ 40.969791] mhi_destroy_device+0x9a/0x100 [mhi]\n[ 40.969796] ? mhi_unmap_single_use_bb+0x50/0x50 [mhi]\n[ 40.969799] device_for_each_child+0x5e/0xa0\n[ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi]", "id": "GSD-2021-46970", "modified": "2024-02-28T06:03:57.627158Z", "schema_version": "1.4.0" } }, "namespaces": { "cve.org": { "CVE_data_meta": { "ASSIGNER": "cve@kernel.org", "ID": "CVE-2021-46970", "STATE": "PUBLIC" }, "affects": { "vendor": { "vendor_data": [ { "product": { "product_data": [ { "product_name": "Linux", "version": { "version_data": [ { "version_affected": "\u003c", "version_name": "8f7039787687", "version_value": "abd1510c08a1" }, { "version_value": "not down converted", "x_cve_json_5_version_data": { "defaultStatus": "affected", "versions": [ { "status": "affected", "version": "5.11" }, { "lessThan": "5.11", "status": "unaffected", "version": "0", "versionType": "custom" }, { "lessThanOrEqual": "5.11.*", "status": "unaffected", "version": "5.11.20", "versionType": "custom" }, { "lessThanOrEqual": "5.12.*", "status": "unaffected", "version": "5.12.3", "versionType": "custom" }, { "lessThanOrEqual": "*", "status": "unaffected", "version": "5.13", "versionType": "original_commit_for_fix" } ] } } ] } } ] }, "vendor_name": "Linux" } ] } }, "data_format": "MITRE", "data_type": "CVE", "data_version": "4.0", "description": { "description_data": [ { "lang": "eng", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue\n\nA recent change created a dedicated workqueue for the state-change work\nwith WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags,\nbut the state-change work (mhi_pm_st_worker) does not guarantee forward\nprogress under memory pressure, and will even wait on various memory\nallocations when e.g. creating devices, loading firmware, etc... The\nwork is then not part of a memory reclaim path...\n\nMoreover, this causes a warning in check_flush_dependency() since we end\nup in code that flushes a non-reclaim workqueue:\n\n[ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog\n[ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140\n[ 40.969733] Call Trace:\n[ 40.969740] __flush_work+0x97/0x1d0\n[ 40.969745] ? wake_up_process+0x15/0x20\n[ 40.969749] ? insert_work+0x70/0x80\n[ 40.969750] ? __queue_work+0x14a/0x3e0\n[ 40.969753] flush_work+0x10/0x20\n[ 40.969756] rollback_registered_many+0x1c9/0x510\n[ 40.969759] unregister_netdevice_queue+0x94/0x120\n[ 40.969761] unregister_netdev+0x1d/0x30\n[ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net]\n[ 40.969770] mhi_driver_remove+0x124/0x250 [mhi]\n[ 40.969776] device_release_driver_internal+0xf0/0x1d0\n[ 40.969778] device_release_driver+0x12/0x20\n[ 40.969782] bus_remove_device+0xe1/0x150\n[ 40.969786] device_del+0x17b/0x3e0\n[ 40.969791] mhi_destroy_device+0x9a/0x100 [mhi]\n[ 40.969796] ? mhi_unmap_single_use_bb+0x50/0x50 [mhi]\n[ 40.969799] device_for_each_child+0x5e/0xa0\n[ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi]" } ] }, "generator": { "engine": "bippy-b01c2a820106" }, "problemtype": { "problemtype_data": [ { "description": [ { "lang": "eng", "value": "n/a" } ] } ] }, "references": { "reference_data": [ { "name": "https://git.kernel.org/stable/c/abd1510c08a13c88d24b622a83c82e87ff1d3135", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/abd1510c08a13c88d24b622a83c82e87ff1d3135" }, { "name": "https://git.kernel.org/stable/c/ed541cff35cbdb695f0c98ef506dd7218883fc07", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/ed541cff35cbdb695f0c98ef506dd7218883fc07" }, { "name": "https://git.kernel.org/stable/c/0fccbf0a3b690b162f53b13ed8bc442ea33437dc", "refsource": "MISC", "url": "https://git.kernel.org/stable/c/0fccbf0a3b690b162f53b13ed8bc442ea33437dc" } ] } }, "nvd.nist.gov": { "cve": { "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue\n\nA recent change created a dedicated workqueue for the state-change work\nwith WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags,\nbut the state-change work (mhi_pm_st_worker) does not guarantee forward\nprogress under memory pressure, and will even wait on various memory\nallocations when e.g. creating devices, loading firmware, etc... The\nwork is then not part of a memory reclaim path...\n\nMoreover, this causes a warning in check_flush_dependency() since we end\nup in code that flushes a non-reclaim workqueue:\n\n[ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog\n[ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140\n[ 40.969733] Call Trace:\n[ 40.969740] __flush_work+0x97/0x1d0\n[ 40.969745] ? wake_up_process+0x15/0x20\n[ 40.969749] ? insert_work+0x70/0x80\n[ 40.969750] ? __queue_work+0x14a/0x3e0\n[ 40.969753] flush_work+0x10/0x20\n[ 40.969756] rollback_registered_many+0x1c9/0x510\n[ 40.969759] unregister_netdevice_queue+0x94/0x120\n[ 40.969761] unregister_netdev+0x1d/0x30\n[ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net]\n[ 40.969770] mhi_driver_remove+0x124/0x250 [mhi]\n[ 40.969776] device_release_driver_internal+0xf0/0x1d0\n[ 40.969778] device_release_driver+0x12/0x20\n[ 40.969782] bus_remove_device+0xe1/0x150\n[ 40.969786] device_del+0x17b/0x3e0\n[ 40.969791] mhi_destroy_device+0x9a/0x100 [mhi]\n[ 40.969796] ? mhi_unmap_single_use_bb+0x50/0x50 [mhi]\n[ 40.969799] device_for_each_child+0x5e/0xa0\n[ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi]" }, { "lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: pci_generic: Eliminar el indicador WQ_MEM_RECLAIM de la cola de trabajo de estado Un cambio reciente cre\u00f3 una cola de trabajo dedicada para el trabajo de cambio de estado con los indicadores WQ_HIGHPRI (sin ninguna raz\u00f3n importante para ello) y WQ_MEM_RECLAIM. pero el trabajo de cambio de estado (mhi_pm_st_worker) no garantiza el progreso hacia adelante bajo presi\u00f3n de la memoria, e incluso esperar\u00e1 varias asignaciones de memoria cuando, por ejemplo, se crean dispositivos, se carga firmware, etc... El trabajo entonces no forma parte de una ruta de recuperaci\u00f3n de memoria. .. Adem\u00e1s, esto provoca una advertencia en check_flush_dependency() ya que terminamos en un c\u00f3digo que vac\u00eda una cola de trabajo que no es de recuperaci\u00f3n: [ 40.969601] cola de trabajo: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] est\u00e1 descargando !WQ_MEM_RECLAIM events_highpri:flush_backlog [ 40.969612] ADVERTENCIA : CPU: 4 PID: 158 en kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140 [40.969733] Seguimiento de llamadas: [40.969740] __flush_work+0x97/0x1d0 [40.969745]? proceso_despertador+0x15/0x20 [40.969749]? insertar_trabajo+0x70/0x80 [40.969750]? __queue_work+0x14a/0x3e0 [ 40.969753] Flush_work+0x10/0x20 [ 40.969756] rollback_registered_many+0x1c9/0x510 [ 40.969759] unregister_netdevice_queue+0x94/0x120 [ 40.969761] anular el registro _netdev+0x1d/0x30 [ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net] [ 40.969770 ] mhi_driver_remove+0x124/0x250 [mhi] [ 40.969776] dispositivo_release_driver_internal+0xf0/0x1d0 [ 40.969778] dispositivo_release_driver+0x12/0x20 [ 40.969782] bus_remove_device+0xe1/0x150 [ 40.9 69786] dispositivo_del+0x17b/0x3e0 [ 40.969791] mhi_destroy_device+0x9a/0x100 [ mhi] [40.969796]? mhi_unmap_single_use_bb+0x50/0x50 [mhi] [ 40.969799] dispositivo_para_cada_ni\u00f1o+0x5e/0xa0 [ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi]" } ], "id": "CVE-2021-46970", "lastModified": "2024-02-28T14:06:45.783", "metrics": {}, "published": "2024-02-27T19:04:07.303", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/0fccbf0a3b690b162f53b13ed8bc442ea33437dc" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/abd1510c08a13c88d24b622a83c82e87ff1d3135" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/ed541cff35cbdb695f0c98ef506dd7218883fc07" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis" } } } }
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.