{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2023-52738", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-05-21T15:19:24.233Z", "datePublished": "2024-05-21T15:23:01.903Z", "dateUpdated": "2024-11-06T20:21:18.445Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-04T14:51:45.135Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini\n\nCurrently amdgpu calls drm_sched_fini() from the fence driver sw fini\nroutine - such function is expected to be called only after the\nrespective init function - drm_sched_init() - was executed successfully.\n\nHappens that we faced a driver probe failure in the Steam Deck\nrecently, and the function drm_sched_fini() was called even without\nits counter-part had been previously called, causing the following oops:\n\namdgpu: probe of 0000:04:00.0 failed with error -110\nBUG: kernel NULL pointer dereference, address: 0000000000000090\nPGD 0 P4D 0\nOops: 0002 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338\nHardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022\nRIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched]\n[...]\nCall Trace:\n <TASK>\n amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]\n amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]\n amdgpu_driver_release_kms+0x16/0x30 [amdgpu]\n devm_drm_dev_init_release+0x49/0x70\n [...]\n\nTo prevent that, check if the drm_sched was properly initialized for a\ngiven ring before calling its fini counter-part.\n\nNotice ideally we'd use sched.ready for that; such field is set as the latest\nthing on drm_sched_init(). But amdgpu seems to \"override\" the meaning of such\nfield - in the above oops for example, it was a GFX ring causing the crash, and\nthe sched.ready field was set to true in the ring init routine, regardless of\nthe state of the DRM scheduler. Hence, we ended-up using sched.ops as per\nChristian's suggestion [0], and also removed the no_scheduler check [1].\n\n[0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/\n[1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/"}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c"], "versions": [{"version": "067f44c8b459", "lessThan": "2e557c8ca2c5", "status": "affected", "versionType": "git"}, {"version": "067f44c8b459", "lessThan": "2bcbbef9cace", "status": "affected", "versionType": "git"}, {"version": "067f44c8b459", "lessThan": "5ad7bbf3dba5", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c"], "versions": [{"version": "5.15", "status": "affected"}, {"version": "0", "lessThan": "5.15", "status": "unaffected", "versionType": "semver"}, {"version": "5.15.94", "lessThanOrEqual": "5.15.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.1.12", "lessThanOrEqual": "6.1.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.2", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd"}, {"url": "https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b"}, {"url": "https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535"}], "title": "drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini", "x_generator": {"engine": "bippy-9e1c9544281a"}}, "adp": [{"problemTypes": [{"descriptions": [{"type": "CWE", "lang": "en", "description": "CWE-noinfo Not enough information"}]}], "metrics": [{"cvssV3_1": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.3, "attackVector": "NETWORK", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "LOW", "privilegesRequired": "NONE", "confidentialityImpact": "NONE"}}, {"other": {"type": "ssvc", "content": {"timestamp": "2024-05-21T18:15:49.184533Z", "id": "CVE-2023-52738", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-11-06T20:21:18.445Z"}}, {"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T23:11:36.070Z"}, "title": "CVE Program Container", "references": [{"url": "https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535", "tags": ["x_transferred"]}]}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CVE Program Container", "references": [{"url": "https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535", "tags": ["x_transferred"]}], "providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T23:11:36.070Z"}}, {"title": "CISA ADP Vulnrichment", "metrics": [{"cvssV3_1": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.3, "attackVector": "NETWORK", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "LOW", "privilegesRequired": "NONE", "confidentialityImpact": "NONE"}}, {"other": {"type": "ssvc", "content": {"id": "CVE-2023-52738", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-05-21T18:15:49.184533Z"}}}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "description": "CWE-noinfo Not enough information"}]}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-05-23T19:01:25.387Z"}}], "cna": {"title": "drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini", "affected": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "067f44c8b459", "lessThan": "2e557c8ca2c5", "versionType": "git"}, {"status": "affected", "version": "067f44c8b459", "lessThan": "2bcbbef9cace", "versionType": "git"}, {"status": "affected", "version": "067f44c8b459", "lessThan": "5ad7bbf3dba5", "versionType": "git"}], "programFiles": ["drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "5.15"}, {"status": "unaffected", "version": "0", "lessThan": "5.15", "versionType": "semver"}, {"status": "unaffected", "version": "5.15.94", "versionType": "semver", "lessThanOrEqual": "5.15.*"}, {"status": "unaffected", "version": "6.1.12", "versionType": "semver", "lessThanOrEqual": "6.1.*"}, {"status": "unaffected", "version": "6.2", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c"], "defaultStatus": "affected"}], "references": [{"url": "https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd"}, {"url": "https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b"}, {"url": "https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535"}], "x_generator": {"engine": "bippy-9e1c9544281a"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini\n\nCurrently amdgpu calls drm_sched_fini() from the fence driver sw fini\nroutine - such function is expected to be called only after the\nrespective init function - drm_sched_init() - was executed successfully.\n\nHappens that we faced a driver probe failure in the Steam Deck\nrecently, and the function drm_sched_fini() was called even without\nits counter-part had been previously called, causing the following oops:\n\namdgpu: probe of 0000:04:00.0 failed with error -110\nBUG: kernel NULL pointer dereference, address: 0000000000000090\nPGD 0 P4D 0\nOops: 0002 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338\nHardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022\nRIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched]\n[...]\nCall Trace:\n <TASK>\n amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]\n amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]\n amdgpu_driver_release_kms+0x16/0x30 [amdgpu]\n devm_drm_dev_init_release+0x49/0x70\n [...]\n\nTo prevent that, check if the drm_sched was properly initialized for a\ngiven ring before calling its fini counter-part.\n\nNotice ideally we'd use sched.ready for that; such field is set as the latest\nthing on drm_sched_init(). But amdgpu seems to \"override\" the meaning of such\nfield - in the above oops for example, it was a GFX ring causing the crash, and\nthe sched.ready field was set to true in the ring init routine, regardless of\nthe state of the DRM scheduler. Hence, we ended-up using sched.ops as per\nChristian's suggestion [0], and also removed the no_scheduler check [1].\n\n[0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/\n[1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/"}], "providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-04T14:51:45.135Z"}}}, "cveMetadata": {"cveId": "CVE-2023-52738", "state": "PUBLISHED", "dateUpdated": "2024-11-06T20:21:18.445Z", "dateReserved": "2024-05-21T15:19:24.233Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-05-21T15:23:01.903Z", "assignerShortName": "Linux"}, "dataVersion": "5.1"}

{"descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini\n\nCurrently amdgpu calls drm_sched_fini() from the fence driver sw fini\nroutine - such function is expected to be called only after the\nrespective init function - drm_sched_init() - was executed successfully.\n\nHappens that we faced a driver probe failure in the Steam Deck\nrecently, and the function drm_sched_fini() was called even without\nits counter-part had been previously called, causing the following oops:\n\namdgpu: probe of 0000:04:00.0 failed with error -110\nBUG: kernel NULL pointer dereference, address: 0000000000000090\nPGD 0 P4D 0\nOops: 0002 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338\nHardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022\nRIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched]\n[...]\nCall Trace:\n <TASK>\n amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]\n amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]\n amdgpu_driver_release_kms+0x16/0x30 [amdgpu]\n devm_drm_dev_init_release+0x49/0x70\n [...]\n\nTo prevent that, check if the drm_sched was properly initialized for a\ngiven ring before calling its fini counter-part.\n\nNotice ideally we'd use sched.ready for that; such field is set as the latest\nthing on drm_sched_init(). But amdgpu seems to \"override\" the meaning of such\nfield - in the above oops for example, it was a GFX ring causing the crash, and\nthe sched.ready field was set to true in the ring init routine, regardless of\nthe state of the DRM scheduler. Hence, we ended-up using sched.ops as per\nChristian's suggestion [0], and also removed the no_scheduler check [1].\n\n[0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/\n[1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu/fence: se solucion\u00f3 el error debido a que drm_sched init/fini no coincide. Actualmente, amdgpu llama a drm_sched_fini() desde la rutina SW fini del controlador de valla; se espera que se llame a dicha funci\u00f3n. s\u00f3lo despu\u00e9s de que la funci\u00f3n de inicio respectiva, drm_sched_init(), se haya ejecutado correctamente. Sucede que recientemente nos enfrentamos a una falla en la sonda del controlador en Steam Deck, y se llam\u00f3 a la funci\u00f3n drm_sched_fini() incluso sin que su contraparte se hubiera llamado previamente, lo que provoc\u00f3 el siguiente error: amdgpu: la sonda de 0000:04:00.0 fall\u00f3 con error -110 ERROR: desreferencia del puntero NULL del kernel, direcci\u00f3n: 0000000000000090 PGD 0 P4D 0 Ups: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 609 Comm: systemd-udevd No contaminado 6.2.0-rc3-gpiccoli #338 Nombre del hardware : Valve Jupiter/Jupiter, BIOS F7A0113 04/11/2022 RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Seguimiento de llamadas: amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu] amdgpu_device_fini_sw+0x2b/0x3b0 [ amdgpu] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] devm_drm_dev_init_release+0x49/0x70 [...] Para evitar eso, verifique si drm_sched se inicializ\u00f3 correctamente para un anillo determinado antes de llamar a su contraparte fini. Observe que idealmente usar\u00edamos sched.ready para eso; dicho campo se establece como lo \u00faltimo en drm_sched_init(). Pero amdgpu parece \"sobreescribir\" el significado de dicho campo; en el ejemplo anterior, por ejemplo, fue un anillo GFX el que provoc\u00f3 el bloqueo y el campo sched.ready se configur\u00f3 en verdadero en la rutina de inicio del anillo, independientemente del estado de el programador DRM. Por lo tanto, terminamos usando sched.ops seg\u00fan la sugerencia de Christian [0] y tambi\u00e9n eliminamos la verificaci\u00f3n no_scheduler [1]. [0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/ [1] https://lore.kernel.org/amd-gfx/cd0e2994- f85f-d837-609f-7056d5fb7231@amd.com/"}], "id": "CVE-2023-52738", "lastModified": "2024-11-21T08:40:28.837", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "LOW", "baseScore": 5.3, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L", "version": "3.1"}, "exploitabilityScore": 3.9, "impactScore": 1.4, "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "type": "Secondary"}]}, "published": "2024-05-21T16:15:13.740", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis"}

{"bugzilla": {"description": "kernel: drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini", "id": "2282684", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2282684"}, "csaw": false, "cvss3": {"cvss3_base_score": "4.4", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-476", "details": ["In the Linux kernel, the following vulnerability has been resolved:\ndrm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini\nCurrently amdgpu calls drm_sched_fini() from the fence driver sw fini\nroutine - such function is expected to be called only after the\nrespective init function - drm_sched_init() - was executed successfully.\nHappens that we faced a driver probe failure in the Steam Deck\nrecently, and the function drm_sched_fini() was called even without\nits counter-part had been previously called, causing the following oops:\namdgpu: probe of 0000:04:00.0 failed with error -110\nBUG: kernel NULL pointer dereference, address: 0000000000000090\nPGD 0 P4D 0\nOops: 0002 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338\nHardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022\nRIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched]\n[...]\nCall Trace:\n<TASK>\namdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]\namdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]\namdgpu_driver_release_kms+0x16/0x30 [amdgpu]\ndevm_drm_dev_init_release+0x49/0x70\n[...]\nTo prevent that, check if the drm_sched was properly initialized for a\ngiven ring before calling its fini counter-part.\nNotice ideally we'd use sched.ready for that; such field is set as the latest\nthing on drm_sched_init(). But amdgpu seems to \"override\" the meaning of such\nfield - in the above oops for example, it was a GFX ring causing the crash, and\nthe sched.ready field was set to true in the ring init routine, regardless of\nthe state of the DRM scheduler. Hence, we ended-up using sched.ops as per\nChristian's suggestion [0], and also removed the no_scheduler check [1].\n[0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/\n[1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/"], "name": "CVE-2023-52738", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-05-21T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2023-52738\nhttps://nvd.nist.gov/vuln/detail/CVE-2023-52738\nhttps://lore.kernel.org/linux-cve-announce/2024052101-CVE-2023-52738-f1bb@gregkh/T"], "threat_severity": "Low", "upstream_fix": "kernel 5.15.94, kernel 6.1.12, kernel 6.2"}