CVE-2024-44956

In the Linux kernel, the following vulnerability has been resolved: drm/xe/preempt_fence: enlarge the fence critical section It is really easy to introduce subtle deadlocks in preempt_fence_work_func() since we operate on single global ordered-wq for signalling our preempt fences behind the scenes, so even though we signal a particular fence, everything in the callback should be in the fence critical section, since blocking in the callback will prevent other published fences from signalling. If we enlarge the fence critical section to cover the entire callback, then lockdep should be able to understand this better, and complain if we grab a sensitive lock like vm->lock, which is also held when waiting on preempt fences.

CVSS v3 5.5 MEDIUM

5.5^/10

CVSS v3 : MEDIUM

Vector :

Exploitability : 1.8 / Impact : 3.6

Attack Vector LOCAL

Attack Complexity LOW

Privileges Required LOW

User Interaction NONE

Confidentiality Impact NONE

Integrity Impact NONE

Availability Impact HIGH

Scope UNCHANGED

References

Link	Resource
https://git.kernel.org/stable/c/3cd1585e57908b6efcd967465ef7685f40b2a294	Patch
https://git.kernel.org/stable/c/458bb83119dfee5d14c677f7846dd9363817006f	Patch

Configurations

Configuration 1 (hide)

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

History

No history.

Information

Published : 2024-09-04 19:15

Updated : 2024-09-06 16:37

NVD link : CVE-2024-44956

Mitre link : CVE-2024-44956

CVE.ORG link : CVE-2024-44956

JSON object : View

Products Affected

linux

linux_kernel

CWE

CWE-667

Improper Locking

{"id": "CVE-2024-44956", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2024-09-04T19:15:30.480", "references": [{"url": "https://git.kernel.org/stable/c/3cd1585e57908b6efcd967465ef7685f40b2a294", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/458bb83119dfee5d14c677f7846dd9363817006f", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-667"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/preempt_fence: enlarge the fence critical section\n\nIt is really easy to introduce subtle deadlocks in\npreempt_fence_work_func() since we operate on single global ordered-wq\nfor signalling our preempt fences behind the scenes, so even though we\nsignal a particular fence, everything in the callback should be in the\nfence critical section, since blocking in the callback will prevent\nother published fences from signalling. If we enlarge the fence critical\nsection to cover the entire callback, then lockdep should be able to\nunderstand this better, and complain if we grab a sensitive lock like\nvm->lock, which is also held when waiting on preempt fences."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/preempt_fence: agrandar la secci\u00f3n cr\u00edtica de la cerca Es realmente f\u00e1cil introducir bloqueos sutiles en preempt_fence_work_func() ya que operamos en un solo wq ordenado global para se\u00f1alar nuestras cercas de preempci\u00f3n detr\u00e1s de escena, por lo que incluso aunque se\u00f1alemos una cerca en particular, todo en la devoluci\u00f3n de llamada debe estar en la secci\u00f3n cr\u00edtica de la cerca, ya que el bloqueo en la devoluci\u00f3n de llamada evitar\u00e1 que otras cercas publicadas se\u00f1alicen. Si agrandamos la secci\u00f3n cr\u00edtica de la cerca para cubrir toda la devoluci\u00f3n de llamada, entonces lockdep deber\u00eda poder entender esto mejor y quejarse si tomamos un bloqueo sensible como vm->lock, que tambi\u00e9n se mantiene cuando se espera en cercas de preempci\u00f3n."}], "lastModified": "2024-09-06T16:37:11.777", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "E4CB0927-C720-465B-99F2-3E47215515F2", "versionEndExcluding": "6.10.5"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}