{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-50099", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-10-21T19:36:19.945Z", "datePublished": "2024-11-05T17:07:37.336Z", "dateUpdated": "2024-12-19T09:33:04.453Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-12-19T09:33:04.453Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: probes: Remove broken LDR (literal) uprobe support\n\nThe simulate_ldr_literal() and simulate_ldrsw_literal() functions are\nunsafe to use for uprobes. Both functions were originally written for\nuse with kprobes, and access memory with plain C accesses. When uprobes\nwas added, these were reused unmodified even though they cannot safely\naccess user memory.\n\nThere are three key problems:\n\n1) The plain C accesses do not have corresponding extable entries, and\n thus if they encounter a fault the kernel will treat these as\n unintentional accesses to user memory, resulting in a BUG() which\n will kill the kernel thread, and likely lead to further issues (e.g.\n lockup or panic()).\n\n2) The plain C accesses are subject to HW PAN and SW PAN, and so when\n either is in use, any attempt to simulate an access to user memory\n will fault. Thus neither simulate_ldr_literal() nor\n simulate_ldrsw_literal() can do anything useful when simulating a\n user instruction on any system with HW PAN or SW PAN.\n\n3) The plain C accesses are privileged, as they run in kernel context,\n and in practice can access a small range of kernel virtual addresses.\n The instructions they simulate have a range of +/-1MiB, and since the\n simulated instructions must itself be a user instructions in the\n TTBR0 address range, these can address the final 1MiB of the TTBR1\n acddress range by wrapping downwards from an address in the first\n 1MiB of the TTBR0 address range.\n\n In contemporary kernels the last 8MiB of TTBR1 address range is\n reserved, and accesses to this will always fault, meaning this is no\n worse than (1).\n\n Historically, it was theoretically possible for the linear map or\n vmemmap to spill into the final 8MiB of the TTBR1 address range, but\n in practice this is extremely unlikely to occur as this would\n require either:\n\n * Having enough physical memory to fill the entire linear map all the\n way to the final 1MiB of the TTBR1 address range.\n\n * Getting unlucky with KASLR randomization of the linear map such\n that the populated region happens to overlap with the last 1MiB of\n the TTBR address range.\n\n ... and in either case if we were to spill into the final page there\n would be larger problems as the final page would alias with error\n pointers.\n\nPractically speaking, (1) and (2) are the big issues. Given there have\nbeen no reports of problems since the broken code was introduced, it\nappears that no-one is relying on probing these instructions with\nuprobes.\n\nAvoid these issues by not allowing uprobes on LDR (literal) and LDRSW\n(literal), limiting the use of simulate_ldr_literal() and\nsimulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR\n(literal) and LDRSW (literal) will be rejected as\narm_probe_decode_insn() will return INSN_REJECTED. In future we can\nconsider introducing working uprobes support for these instructions, but\nthis will require more significant work."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["arch/arm64/kernel/probes/decode-insn.c"], "versions": [{"version": "9842ceae9fa8deae141533d52a6ead7666962c09", "lessThan": "cc86f2e9876c8b5300238cec6bf0bd8c842078ee", "status": "affected", "versionType": "git"}, {"version": "9842ceae9fa8deae141533d52a6ead7666962c09", "lessThan": "ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9", "status": "affected", "versionType": "git"}, {"version": "9842ceae9fa8deae141533d52a6ead7666962c09", "lessThan": "3728b4eb27910ffedd173018279a970705f2e03a", "status": "affected", "versionType": "git"}, {"version": "9842ceae9fa8deae141533d52a6ead7666962c09", "lessThan": "ad4bc35a6d22e9ff9b67d0d0c38bce654232f195", "status": "affected", "versionType": "git"}, {"version": "9842ceae9fa8deae141533d52a6ead7666962c09", "lessThan": "bae792617a7e911477f67a3aff850ad4ddf51572", "status": "affected", "versionType": "git"}, {"version": "9842ceae9fa8deae141533d52a6ead7666962c09", "lessThan": "9f1e7735474e7457a4d919a517900e46868ae5f6", "status": "affected", "versionType": "git"}, {"version": "9842ceae9fa8deae141533d52a6ead7666962c09", "lessThan": "20cde998315a3d2df08e26079a3ea7501abce6db", "status": "affected", "versionType": "git"}, {"version": "9842ceae9fa8deae141533d52a6ead7666962c09", "lessThan": "acc450aa07099d071b18174c22a1119c57da8227", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["arch/arm64/kernel/probes/decode-insn.c"], "versions": [{"version": "4.10", "status": "affected"}, {"version": "0", "lessThan": "4.10", "status": "unaffected", "versionType": "semver"}, {"version": "4.19.323", "lessThanOrEqual": "4.19.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.4.285", "lessThanOrEqual": "5.4.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.10.228", "lessThanOrEqual": "5.10.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.15.169", "lessThanOrEqual": "5.15.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.1.114", "lessThanOrEqual": "6.1.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.6.58", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.11.5", "lessThanOrEqual": "6.11.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.12", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/cc86f2e9876c8b5300238cec6bf0bd8c842078ee"}, {"url": "https://git.kernel.org/stable/c/ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9"}, {"url": "https://git.kernel.org/stable/c/3728b4eb27910ffedd173018279a970705f2e03a"}, {"url": "https://git.kernel.org/stable/c/ad4bc35a6d22e9ff9b67d0d0c38bce654232f195"}, {"url": "https://git.kernel.org/stable/c/bae792617a7e911477f67a3aff850ad4ddf51572"}, {"url": "https://git.kernel.org/stable/c/9f1e7735474e7457a4d919a517900e46868ae5f6"}, {"url": "https://git.kernel.org/stable/c/20cde998315a3d2df08e26079a3ea7501abce6db"}, {"url": "https://git.kernel.org/stable/c/acc450aa07099d071b18174c22a1119c57da8227"}], "title": "arm64: probes: Remove broken LDR (literal) uprobe support", "x_generator": {"engine": "bippy-5f407fcff5a0"}}}}

{}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "56700326-E491-4B17-B143-B939C5EC1DBE", "versionEndExcluding": "4.19.323", "versionStartIncluding": "4.10", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "B5A89369-320F-47FC-8695-56F61F87E4C0", "versionEndExcluding": "5.4.285", "versionStartIncluding": "4.20", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "9062315F-AB89-4ABE-8C13-B75927689F66", "versionEndExcluding": "5.10.228", "versionStartIncluding": "5.5", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "18BEDAD6-86F8-457C-952F-C35698B3D07F", "versionEndExcluding": "5.15.169", "versionStartIncluding": "5.11", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "10FD2B3E-C7D9-4A9C-BD64-41877EDF88EB", "versionEndExcluding": "6.1.114", "versionStartIncluding": "5.16", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "6B9489BC-825E-4EEE-8D93-F93C801988C8", "versionEndExcluding": "6.6.58", "versionStartIncluding": "6.2", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "6E62D61A-F704-44DB-A311-17B7534DA7BC", "versionEndExcluding": "6.11.5", "versionStartIncluding": "6.7", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*", "matchCriteriaId": "7F361E1D-580F-4A2D-A509-7615F73167A1", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc2:*:*:*:*:*:*", "matchCriteriaId": "925478D0-3E3D-4E6F-ACD5-09F28D5DF82C", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc3:*:*:*:*:*:*", "matchCriteriaId": "3C95E234-D335-4B6C-96BF-E2CEBD8654ED", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: probes: Remove broken LDR (literal) uprobe support\n\nThe simulate_ldr_literal() and simulate_ldrsw_literal() functions are\nunsafe to use for uprobes. Both functions were originally written for\nuse with kprobes, and access memory with plain C accesses. When uprobes\nwas added, these were reused unmodified even though they cannot safely\naccess user memory.\n\nThere are three key problems:\n\n1) The plain C accesses do not have corresponding extable entries, and\n thus if they encounter a fault the kernel will treat these as\n unintentional accesses to user memory, resulting in a BUG() which\n will kill the kernel thread, and likely lead to further issues (e.g.\n lockup or panic()).\n\n2) The plain C accesses are subject to HW PAN and SW PAN, and so when\n either is in use, any attempt to simulate an access to user memory\n will fault. Thus neither simulate_ldr_literal() nor\n simulate_ldrsw_literal() can do anything useful when simulating a\n user instruction on any system with HW PAN or SW PAN.\n\n3) The plain C accesses are privileged, as they run in kernel context,\n and in practice can access a small range of kernel virtual addresses.\n The instructions they simulate have a range of +/-1MiB, and since the\n simulated instructions must itself be a user instructions in the\n TTBR0 address range, these can address the final 1MiB of the TTBR1\n acddress range by wrapping downwards from an address in the first\n 1MiB of the TTBR0 address range.\n\n In contemporary kernels the last 8MiB of TTBR1 address range is\n reserved, and accesses to this will always fault, meaning this is no\n worse than (1).\n\n Historically, it was theoretically possible for the linear map or\n vmemmap to spill into the final 8MiB of the TTBR1 address range, but\n in practice this is extremely unlikely to occur as this would\n require either:\n\n * Having enough physical memory to fill the entire linear map all the\n way to the final 1MiB of the TTBR1 address range.\n\n * Getting unlucky with KASLR randomization of the linear map such\n that the populated region happens to overlap with the last 1MiB of\n the TTBR address range.\n\n ... and in either case if we were to spill into the final page there\n would be larger problems as the final page would alias with error\n pointers.\n\nPractically speaking, (1) and (2) are the big issues. Given there have\nbeen no reports of problems since the broken code was introduced, it\nappears that no-one is relying on probing these instructions with\nuprobes.\n\nAvoid these issues by not allowing uprobes on LDR (literal) and LDRSW\n(literal), limiting the use of simulate_ldr_literal() and\nsimulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR\n(literal) and LDRSW (literal) will be rejected as\narm_probe_decode_insn() will return INSN_REJECTED. In future we can\nconsider introducing working uprobes support for these instructions, but\nthis will require more significant work."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: sondas: Eliminar el soporte roto de uprobe LDR (literal). Las funciones simulation_ldr_literal() y simulation_ldrsw_literal() no son seguras para usar con uprobes. Ambas funciones se escribieron originalmente para usar con kprobes y acceder a la memoria con accesos C simples. Cuando se agreg\u00f3 uprobes, se reutilizaron sin modificar a pesar de que no pueden acceder de manera segura a la memoria del usuario. Hay tres problemas clave: 1) Los accesos C simples no tienen entradas extable correspondientes y, por lo tanto, si encuentran un fallo, el kernel los tratar\u00e1 como accesos no intencionales a la memoria del usuario, lo que resultar\u00e1 en un BUG() que matar\u00e1 el hilo del kernel y probablemente conducir\u00e1 a m\u00e1s problemas (por ejemplo, bloqueo o panic()). 2) Los accesos C simples est\u00e1n sujetos a HW PAN y SW PAN, y por lo tanto, cuando cualquiera de ellos est\u00e1 en uso, cualquier intento de simular un acceso a la memoria del usuario fallar\u00e1. Por lo tanto, ni simulation_ldr_literal() ni simulation_ldrsw_literal() pueden hacer nada \u00fatil al simular una instrucci\u00f3n de usuario en cualquier sistema con HW PAN o SW PAN. 3) Los accesos C simples son privilegiados, ya que se ejecutan en el contexto del n\u00facleo y, en la pr\u00e1ctica, pueden acceder a un peque\u00f1o rango de direcciones virtuales del n\u00facleo. Las instrucciones que simulan tienen un rango de +/-1 MiB y, dado que las instrucciones simuladas deben ser instrucciones de usuario en el rango de direcciones TTBR0, estas pueden direccionar el \u00faltimo MiB del rango de direcciones de TTBR1 envolviendo hacia abajo desde una direcci\u00f3n en el primer MiB del rango de direcciones TTBR0. En los n\u00facleos contempor\u00e1neos, los \u00faltimos 8 MiB del rango de direcciones TTBR1 est\u00e1n reservados y los accesos a estos siempre fallar\u00e1n, lo que significa que esto no es peor que (1). Hist\u00f3ricamente, era te\u00f3ricamente posible que el mapa lineal o vmemmap se derramara en los \u00faltimos 8 MiB del rango de direcciones TTBR1, pero en la pr\u00e1ctica esto es extremadamente improbable que ocurra ya que esto requerir\u00eda: * Tener suficiente memoria f\u00edsica para llenar todo el mapa lineal hasta el \u00faltimo 1 MiB del rango de direcciones TTBR1. * Tener mala suerte con la aleatorizaci\u00f3n KASLR del mapa lineal de modo que la regi\u00f3n poblada se superponga con el \u00faltimo 1 MiB del rango de direcciones TTBR. ... y en cualquier caso, si nos desbord\u00e1ramos en la p\u00e1gina final, habr\u00eda problemas m\u00e1s grandes ya que la p\u00e1gina final tendr\u00eda alias con punteros de error. Pr\u00e1cticamente hablando, (1) y (2) son los grandes problemas. Dado que no ha habido informes de problemas desde que se introdujo el c\u00f3digo roto, parece que nadie conf\u00eda en sondear estas instrucciones con uprobes. Evite estos problemas al no permitir uprobes en LDR (literal) y LDRSW (literal), y al limitar el uso de simulation_ldr_literal() y simulation_ldrsw_literal() a kprobes. Los intentos de colocar uprobes en LDR (literal) y LDRSW (literal) ser\u00e1n rechazados ya que arm_probe_decode_insn() devolver\u00e1 INSN_REJECTED. En el futuro, podemos considerar la introducci\u00f3n de compatibilidad con uprobes funcionales para estas instrucciones, pero esto requerir\u00e1 un trabajo m\u00e1s significativo."}], "id": "CVE-2024-50099", "lastModified": "2024-11-12T16:28:30.633", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "[email protected]", "type": "Primary"}]}, "published": "2024-11-05T18:15:13.690", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/20cde998315a3d2df08e26079a3ea7501abce6db"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/3728b4eb27910ffedd173018279a970705f2e03a"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/9f1e7735474e7457a4d919a517900e46868ae5f6"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/acc450aa07099d071b18174c22a1119c57da8227"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/ad4bc35a6d22e9ff9b67d0d0c38bce654232f195"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/bae792617a7e911477f67a3aff850ad4ddf51572"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/cc86f2e9876c8b5300238cec6bf0bd8c842078ee"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "NVD-CWE-noinfo"}], "source": "[email protected]", "type": "Primary"}]}

{"affected_release": [{"advisory": "RHSA-2024:10944", "cpe": "cpe:/a:redhat:enterprise_linux:8::nfv", "package": "kernel-rt-0:4.18.0-553.32.1.rt7.373.el8_10", "product_name": "Red Hat Enterprise Linux 8", "release_date": "2024-12-11T00:00:00Z"}, {"advisory": "RHSA-2024:10943", "cpe": "cpe:/o:redhat:enterprise_linux:8", "package": "kernel-0:4.18.0-553.32.1.el8_10", "product_name": "Red Hat Enterprise Linux 8", "release_date": "2024-12-11T00:00:00Z"}, {"advisory": "RHSA-2024:11486", "cpe": "cpe:/a:redhat:enterprise_linux:9", "package": "kernel-0:5.14.0-503.19.1.el9_5", "product_name": "Red Hat Enterprise Linux 9", "release_date": "2024-12-19T00:00:00Z"}, {"advisory": "RHSA-2024:11486", "cpe": "cpe:/o:redhat:enterprise_linux:9", "package": "kernel-0:5.14.0-503.19.1.el9_5", "product_name": "Red Hat Enterprise Linux 9", "release_date": "2024-12-19T00:00:00Z"}], "bugzilla": {"description": "kernel: arm64: probes: Remove broken LDR (literal) uprobe support", "id": "2323904", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2323904"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "verified"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\narm64: probes: Remove broken LDR (literal) uprobe support\nThe simulate_ldr_literal() and simulate_ldrsw_literal() functions are\nunsafe to use for uprobes. Both functions were originally written for\nuse with kprobes, and access memory with plain C accesses. When uprobes\nwas added, these were reused unmodified even though they cannot safely\naccess user memory.\nThere are three key problems:\n1) The plain C accesses do not have corresponding extable entries, and\nthus if they encounter a fault the kernel will treat these as\nunintentional accesses to user memory, resulting in a BUG() which\nwill kill the kernel thread, and likely lead to further issues (e.g.\nlockup or panic()).\n2) The plain C accesses are subject to HW PAN and SW PAN, and so when\neither is in use, any attempt to simulate an access to user memory\nwill fault. Thus neither simulate_ldr_literal() nor\nsimulate_ldrsw_literal() can do anything useful when simulating a\nuser instruction on any system with HW PAN or SW PAN.\n3) The plain C accesses are privileged, as they run in kernel context,\nand in practice can access a small range of kernel virtual addresses.\nThe instructions they simulate have a range of +/-1MiB, and since the\nsimulated instructions must itself be a user instructions in the\nTTBR0 address range, these can address the final 1MiB of the TTBR1\nacddress range by wrapping downwards from an address in the first\n1MiB of the TTBR0 address range.\nIn contemporary kernels the last 8MiB of TTBR1 address range is\nreserved, and accesses to this will always fault, meaning this is no\nworse than (1).\nHistorically, it was theoretically possible for the linear map or\nvmemmap to spill into the final 8MiB of the TTBR1 address range, but\nin practice this is extremely unlikely to occur as this would\nrequire either:\n* Having enough physical memory to fill the entire linear map all the\nway to the final 1MiB of the TTBR1 address range.\n* Getting unlucky with KASLR randomization of the linear map such\nthat the populated region happens to overlap with the last 1MiB of\nthe TTBR address range.\n... and in either case if we were to spill into the final page there\nwould be larger problems as the final page would alias with error\npointers.\nPractically speaking, (1) and (2) are the big issues. Given there have\nbeen no reports of problems since the broken code was introduced, it\nappears that no-one is relying on probing these instructions with\nuprobes.\nAvoid these issues by not allowing uprobes on LDR (literal) and LDRSW\n(literal), limiting the use of simulate_ldr_literal() and\nsimulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR\n(literal) and LDRSW (literal) will be rejected as\narm_probe_decode_insn() will return INSN_REJECTED. In future we can\nconsider introducing working uprobes support for these instructions, but\nthis will require more significant work."], "name": "CVE-2024-50099", "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": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-11-05T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-50099\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-50099\nhttps://lore.kernel.org/linux-cve-announce/2024110526-CVE-2024-50099-1758@gregkh/T"], "threat_severity": "Moderate"}