Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-50099 (GCVE-0-2024-50099)
Vulnerability from cvelistv5 – Published: 2024-11-05 17:07 – Updated: 2026-08-05 11:41| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
9842ceae9fa8deae141533d52a6ead7666962c09 , < cc86f2e9876c8b5300238cec6bf0bd8c842078ee
(git)
Affected: 9842ceae9fa8deae141533d52a6ead7666962c09 , < ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9 (git) Affected: 9842ceae9fa8deae141533d52a6ead7666962c09 , < 3728b4eb27910ffedd173018279a970705f2e03a (git) Affected: 9842ceae9fa8deae141533d52a6ead7666962c09 , < ad4bc35a6d22e9ff9b67d0d0c38bce654232f195 (git) Affected: 9842ceae9fa8deae141533d52a6ead7666962c09 , < bae792617a7e911477f67a3aff850ad4ddf51572 (git) Affected: 9842ceae9fa8deae141533d52a6ead7666962c09 , < 9f1e7735474e7457a4d919a517900e46868ae5f6 (git) Affected: 9842ceae9fa8deae141533d52a6ead7666962c09 , < 20cde998315a3d2df08e26079a3ea7501abce6db (git) Affected: 9842ceae9fa8deae141533d52a6ead7666962c09 , < acc450aa07099d071b18174c22a1119c57da8227 (git) |
guessed | |
| Linux | Linux |
Affected:
4.10
Unaffected: 0 , < 4.10 (semver) Unaffected: 4.19.323 , ≤ 4.19.* (semver) Unaffected: 5.4.285 , ≤ 5.4.* (semver) Unaffected: 5.10.228 , ≤ 5.10.* (semver) Unaffected: 5.15.169 , ≤ 5.15.* (semver) Unaffected: 6.1.114 , ≤ 6.1.* (semver) Unaffected: 6.6.58 , ≤ 6.6.* (semver) Unaffected: 6.11.5 , ≤ 6.11.* (semver) Unaffected: 6.12 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2024-50099",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:22:38.960966Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"description": "CWE-noinfo Not enough information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T20:27:18.856Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-03T22:25:30.760Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/arm64/kernel/probes/decode-insn.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cc86f2e9876c8b5300238cec6bf0bd8c842078ee",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "3728b4eb27910ffedd173018279a970705f2e03a",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "ad4bc35a6d22e9ff9b67d0d0c38bce654232f195",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "bae792617a7e911477f67a3aff850ad4ddf51572",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "9f1e7735474e7457a4d919a517900e46868ae5f6",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "20cde998315a3d2df08e26079a3ea7501abce6db",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "acc450aa07099d071b18174c22a1119c57da8227",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/arm64/kernel/probes/decode-insn.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.10"
},
{
"lessThan": "4.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.323",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.285",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.228",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.169",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.114",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.58",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.323",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.285",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.228",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.169",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.114",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.58",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.5",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12",
"versionStartIncluding": "4.10",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"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."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.3,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - Exploitation requires local access \u2014 registering a uprobe via perf_event_open/tracefs/BPF and executing the probed instruction in a local process. There is no network-reachable path to arch_uprobe_skip_sstep().\nAC:L - With HW PAN (ARMv8.1, present on essentially all modern arm64 CPUs) or SW PAN, every execution of a uprobe placed on LDR/LDRSW (literal) faults deterministically \u2014 no race, no memory-layout luck, no dependence on conditions outside the attacker\u0027s control.\nPR:L - The trigger step (executing the probed instruction, and choosing the low mapping address that makes the load wrap into TTBR1) needs no privileges, and in common tracing/observability deployments an unprivileged user supplies the very binary a privileged agent probes. Only the uprobe registration itself needs CAP_PERFMON, so the lower-privileged actor is the one who deterministically brings the kernel down.\nUI:N - No victim action is needed \u2014 the oops happens automatically the first time the probed instruction is executed, and uprobe attachment by an instrumentation agent is automated policy rather than a human interaction.\nS:U - The fault, oops and disclosure are all confined to the kernel\u0027s own security authority; no VM, IOMMU or sandbox boundary is crossed.\nC:H - The commit documents that the privileged plain-C load can address the final 1MiB of the TTBR1 kernel range by wrapping from a low TTBR0 address, depositing kernel memory contents directly into a user register \u2014 an attacker-steerable out-of-bounds kernel read far larger than a few bytes, and on older affected trees (4.19/5.4/5.10) it could reach the linear map.\nI:L - The simulation writes the kernel-sourced value into the traced process\u0027s general-purpose register, altering that process\u0027s data and control flow with data the attacker does not choose; no kernel memory is written, so the modification is bounded.\nA:H - The faulting access reaches die_kernel_fault() \u2192 die(\"Oops\") \u2192 make_task_dead(SIGKILL), killing the thread from kernel context and triggering a full panic under panic_on_oops; the commit itself warns of resulting lockup or panic, and the condition is repeatable at will."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:41:40.246Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"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-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-50099",
"datePublished": "2024-11-05T17:07:37.336Z",
"dateReserved": "2024-10-21T19:36:19.945Z",
"dateUpdated": "2026-08-05T11:41:40.246Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-50099",
"date": "2026-10-11",
"epss": "0.00274",
"percentile": "0.18306"
},
"fkie_nvd": {
"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"
}
]
}
],
"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": "nvd@nist.gov",
"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": "nvd@nist.gov",
"type": "Primary"
}
]
},
"microsoft_vex": {
"current_release_date": "2026-02-21T01:55:20.000Z",
"cve": "CVE-2024-50099",
"id": "msrc_CVE-2024-50099",
"initial_release_date": "2024-11-02T00:00:00.000Z",
"product_status:fixed": "5",
"product_status:known_affected": "5",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "arm64: probes: Remove broken LDR (literal) uprobe support",
"url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-50099.json",
"version": "3"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/arm64/kernel/probes/decode-insn.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cc86f2e9876c8b5300238cec6bf0bd8c842078ee",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "3728b4eb27910ffedd173018279a970705f2e03a",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "ad4bc35a6d22e9ff9b67d0d0c38bce654232f195",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "bae792617a7e911477f67a3aff850ad4ddf51572",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "9f1e7735474e7457a4d919a517900e46868ae5f6",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "20cde998315a3d2df08e26079a3ea7501abce6db",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "acc450aa07099d071b18174c22a1119c57da8227",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/arm64/kernel/probes/decode-insn.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.10"
},
{
"lessThan": "4.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.323",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.285",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.228",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.169",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.114",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.58",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"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": "2026-08-04T11:21:19.560",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.3,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.5,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"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": "nvd@nist.gov",
"type": "Primary"
},
{
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-50099",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:22:38.960966Z",
"version": "2.0.3"
}
}
]
},
"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"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "None",
"current_release_date": "2026-06-28T11:00:43+00:00",
"cve": "CVE-2024-50099",
"id": "CVE-2024-50099",
"initial_release_date": "2024-11-05T00:00:00+00:00",
"product_status:fixed": "709",
"product_status:known_affected": "22",
"product_status:known_not_affected": "42",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: arm64: probes: Remove broken LDR (literal) uprobe support",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-50099.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-10-11T00:06:09Z",
"cve": "CVE-2024-50099",
"id": "CVE-2024-50099",
"initial_release_date": "2024-11-06T03:49:15Z",
"product_status:known_affected": "557",
"product_status:known_not_affected": "85",
"product_status:recommended": "601",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2024-50099",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-50099.json",
"version": "61"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T22:25:30.760Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2024-50099",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:22:38.960966Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"description": "CWE-noinfo Not enough information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T15:14:43.539Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/arm64/kernel/probes/decode-insn.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cc86f2e9876c8b5300238cec6bf0bd8c842078ee",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "3728b4eb27910ffedd173018279a970705f2e03a",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "ad4bc35a6d22e9ff9b67d0d0c38bce654232f195",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "bae792617a7e911477f67a3aff850ad4ddf51572",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "9f1e7735474e7457a4d919a517900e46868ae5f6",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "20cde998315a3d2df08e26079a3ea7501abce6db",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "acc450aa07099d071b18174c22a1119c57da8227",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/arm64/kernel/probes/decode-insn.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.10"
},
{
"lessThan": "4.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.323",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.285",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.228",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.169",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.114",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.58",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.323",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.285",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.228",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.169",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.114",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.58",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.5",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12",
"versionStartIncluding": "4.10",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"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."
}
],
"providerMetadata": {
"dateUpdated": "2025-05-04T09:45:57.675Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"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-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-50099",
"datePublished": "2024-11-05T17:07:37.336Z",
"dateReserved": "2024-10-21T19:36:19.945Z",
"dateUpdated": "2025-11-03T22:25:30.760Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2025-AVI-0677
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans les produits Siemens. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| Siemens | N/A | SIMATIC PCS neo V6.0 versions antérieures à V6.0 SP1 | ||
| Siemens | N/A | SIMATIC WinCC V17, v18 et V20 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | SIMATIC Control Function Library (CFL) toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIPROTEC 5 versions antérieures à 10.0 | ||
| Siemens | N/A | SIMATIC MTP Integrator toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC ProSave V17 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Unified Line Coordination toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC TeleControl toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC OA V3.19 versions antérieures à V3.19 P020 | ||
| Siemens | N/A | SIMATIC WinCC flexible ES toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM V17 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2024-54678. | ||
| Siemens | N/A | SIMATIC S7-Fail-safe Configuration Tool (S7-FCT) versions antérieures à 4.0.1 | ||
| Siemens | N/A | SIMATIC PCS neo V6.0 toutes versions pour la vulnérabilité CVE-2024-54678 | ||
| Siemens | N/A | SIMATIC eaSie Core Package (6DL5424-0AX00-0AV8) toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC MTP CREATOR V2.x et V3.x toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC WinCC OA V3.18 versions antérieures à V3.18 P032 | ||
| Siemens | N/A | TIA Portal Cloud V19 versions antérieures à 5.2.1.1 | ||
| Siemens | N/A | SIMATIC D7-SYS toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC BATCH V10.0 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC ODK 1500S toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Process Historian 2020 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour les vulnérabilités CVE-2025-30033 et CVE-2025-47809 | ||
| Siemens | N/A | SIMATIC S7-1500 Software Controller V2 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | TIA Portal Cloud Connector toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Unified Sequence toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM V17 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40759. | ||
| Siemens | N/A | SIMATIC WinCC Runtime Advanced toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Logon V2.0 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC ProSave V19 versions antérieures à V19 Update 4 | ||
| Siemens | N/A | SIMATIC PDM Maintenance Station V5.0 toutes versions pour les vulnérabilités CVE-2025-30033 et CVE-2025-47809 | ||
| Siemens | N/A | SIMATIC Safety Matrix toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Management Console toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SCALANCE XCM-/XRM-/XCH-/XRH-300 family versions antérieures à 3.2 | ||
| Siemens | N/A | SIMATIC BATCH V9.1 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC Process Function Library (PFL) V4.0 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC S7-1500 Software Controller V3 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC STEP 7 CFC V20 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC NET PC Software toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Route Control V9.1 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Process Historian 2022 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC OA V3.20 versions antérieures à V3.20 P008 | ||
| Siemens | N/A | SIMATIC RTLS Locating Manager versions antérieures à 3.3 | ||
| Siemens | N/A | Siprotec 4 7SA6, 7SD5 et 7SD610 versions antérieures à 4.78 | ||
| Siemens | N/A | SIMATIC Automation Tool toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | TIA Portal Cloud V18 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | SIMATIC PDM V9.2 et V9.3 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Runtime Professional toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Visualization Architect (SiVArc) toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC eaSie Workflow Skills toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC STEP 7 CFC V19 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC WinCC V19 versions antérieures à V19 Update 4 | ||
| Siemens | N/A | SIMATIC Management Agent toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC V7.5 et V8.0 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC STEP 7 V5.7 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Automation Tool SDK Windows toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Process Historian 2022 toutes versions pour la vulnérabilité CVE-2025-47809 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM V20 versions antérieures à V20 Update 1 | ||
| Siemens | N/A | TIA Portal Cloud V17 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | SIMATIC Energy Suite toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC PCS 7 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Process Historian 2024 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC STEP 7 V19 versions antérieures à V19 Update 4 | ||
| Siemens | N/A | TIA Portal Test Suite V17, v18, v19 et v20 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC S7-PCT toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Target toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC ProSave V18 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC Logon V1.6 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC STEP 7 V17 et V18 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | SIMATIC RTLS Locating Manager versions antérieures à 3.2 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM Advanced versions antérieures à V7.0 Update 1 | ||
| Siemens | N/A | SIMATIC PCS neo V5.0 toutes versions pour la vulnérabilité CVE-2024-54678 | ||
| Siemens | N/A | SIMATIC STEP 7 V20 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | TIA Portal Cloud V20 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | Siprotec 4 toutes versions et tous modèles exceptés 7SA6, 7SD5, 7SD610 pour la vulnérabilité CVE-2024-52504. | ||
| Siemens | N/A | SIMATIC eaSie PCS 7 Skill Package (6DL5424-0BX00-0AV8) toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 versions antérieures à 3.2 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM V17, V18 et V19 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Unified PC Runtime V18, V19 et V20 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC PCS 7 Advanced Process Faceplates V9.1 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC S7 F Systems V6.4 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Information Server toutes versions pour la vulnérabilité CVE-2025-47809 | ||
| Siemens | N/A | SIMATIC S7 F Systems V6.3 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC ProSave V20 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC PCS 7 Logic Matrix V9.1 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | WinCC Panel Image Setup toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC PCS neo V4.1 et V5.0 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2024-54678. | ||
| Siemens | N/A | SIMATIC Route Control V10.0 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC V8.1 versions antérieures à V8.1 Update 3 |
| Title | Publication Time | Tags | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SIMATIC PCS neo V6.0 versions ant\u00e9rieures \u00e0 V6.0 SP1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V17, v18 et V20 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Control Function Library (CFL) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPROTEC 5 versions ant\u00e9rieures \u00e0 10.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC MTP Integrator toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ProSave V17 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Unified Line Coordination toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC TeleControl toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC OA V3.19 versions ant\u00e9rieures \u00e0 V3.19 P020",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC flexible ES toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM V17 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2024-54678.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-Fail-safe Configuration Tool (S7-FCT) versions ant\u00e9rieures \u00e0 4.0.1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS neo V6.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2024-54678",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC eaSie Core Package (6DL5424-0AX00-0AV8) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC MTP CREATOR V2.x et V3.x toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC OA V3.18 versions ant\u00e9rieures \u00e0 V3.18 P032",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud V19 versions ant\u00e9rieures \u00e0 5.2.1.1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC D7-SYS toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC BATCH V10.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ODK 1500S toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Historian 2020 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour les vuln\u00e9rabilit\u00e9s CVE-2025-30033 et CVE-2025-47809",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 Software Controller V2 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud Connector toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Unified Sequence toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM V17 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40759.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Runtime Advanced toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Logon V2.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ProSave V19 versions ant\u00e9rieures \u00e0 V19 Update 4",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PDM Maintenance Station V5.0 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2025-30033 et CVE-2025-47809",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Safety Matrix toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Management Console toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XCM-/XRM-/XCH-/XRH-300 family versions ant\u00e9rieures \u00e0 3.2",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC BATCH V9.1 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Function Library (PFL) V4.0 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 Software Controller V3 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 CFC V20 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC NET PC Software toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Route Control V9.1 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Historian 2022 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC OA V3.20 versions ant\u00e9rieures \u00e0 V3.20 P008",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC RTLS Locating Manager versions ant\u00e9rieures \u00e0 3.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "Siprotec 4 7SA6, 7SD5 et 7SD610 versions ant\u00e9rieures \u00e0 4.78",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Automation Tool toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud V18 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PDM V9.2 et V9.3 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Runtime Professional toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Visualization Architect (SiVArc) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC eaSie Workflow Skills toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 CFC V19 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V19 versions ant\u00e9rieures \u00e0 V19 Update 4",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Management Agent toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V7.5 et V8.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 V5.7 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Automation Tool SDK Windows toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Historian 2022 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-47809",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM V20 versions ant\u00e9rieures \u00e0 V20 Update 1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud V17 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Energy Suite toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS 7 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Historian 2024 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 V19 versions ant\u00e9rieures \u00e0 V19 Update 4",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Test Suite V17, v18, v19 et v20 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PCT toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Target toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ProSave V18 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Logon V1.6 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 V17 et V18 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC RTLS Locating Manager versions ant\u00e9rieures \u00e0 3.2",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM Advanced versions ant\u00e9rieures \u00e0 V7.0 Update 1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS neo V5.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2024-54678",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 V20 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud V20 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "Siprotec 4 toutes versions et tous mod\u00e8les except\u00e9s 7SA6, 7SD5, 7SD610 pour la vuln\u00e9rabilit\u00e9 CVE-2024-52504. ",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC eaSie PCS 7 Skill Package (6DL5424-0BX00-0AV8) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 versions ant\u00e9rieures \u00e0 3.2",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM V17, V18 et V19 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Unified PC Runtime V18, V19 et V20 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS 7 Advanced Process Faceplates V9.1 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 F Systems V6.4 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Information Server toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-47809",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 F Systems V6.3 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ProSave V20 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS 7 Logic Matrix V9.1 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "WinCC Panel Image Setup toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS neo V4.1 et V5.0 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2024-54678.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Route Control V10.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V8.1 versions ant\u00e9rieures \u00e0 V8.1 Update 3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2023-35827",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35827"
},
{
"name": "CVE-2024-40931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40931"
},
{
"name": "CVE-2024-56596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56596"
},
{
"name": "CVE-2024-43907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43907"
},
{
"name": "CVE-2024-56645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56645"
},
{
"name": "CVE-2024-56659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56659"
},
{
"name": "CVE-2024-46755",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46755"
},
{
"name": "CVE-2024-47748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47748"
},
{
"name": "CVE-2024-26825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26825"
},
{
"name": "CVE-2024-49863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49863"
},
{
"name": "CVE-2024-41022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41022"
},
{
"name": "CVE-2024-49907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49907"
},
{
"name": "CVE-2024-53061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53061"
},
{
"name": "CVE-2024-53052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53052"
},
{
"name": "CVE-2023-52477",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52477"
},
{
"name": "CVE-2024-53097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53097"
},
{
"name": "CVE-2024-46713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46713"
},
{
"name": "CVE-2023-52622",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52622"
},
{
"name": "CVE-2024-9681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9681"
},
{
"name": "CVE-2024-46844",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46844"
},
{
"name": "CVE-2024-43914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43914"
},
{
"name": "CVE-2024-26696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26696"
},
{
"name": "CVE-2024-56670",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56670"
},
{
"name": "CVE-2024-41009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41009"
},
{
"name": "CVE-2024-47697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47697"
},
{
"name": "CVE-2024-46815",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46815"
},
{
"name": "CVE-2024-39503",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39503"
},
{
"name": "CVE-2025-40759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40759"
},
{
"name": "CVE-2022-48666",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48666"
},
{
"name": "CVE-2024-49890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49890"
},
{
"name": "CVE-2024-50262",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50262"
},
{
"name": "CVE-2024-40988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40988"
},
{
"name": "CVE-2024-50268",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50268"
},
{
"name": "CVE-2024-49903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49903"
},
{
"name": "CVE-2024-49969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49969"
},
{
"name": "CVE-2023-52804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52804"
},
{
"name": "CVE-2024-41004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41004"
},
{
"name": "CVE-2024-46676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46676"
},
{
"name": "CVE-2024-41070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41070"
},
{
"name": "CVE-2024-46740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46740"
},
{
"name": "CVE-2023-52845",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52845"
},
{
"name": "CVE-2021-44879",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44879"
},
{
"name": "CVE-2024-46798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46798"
},
{
"name": "CVE-2024-50195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50195"
},
{
"name": "CVE-2024-53172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53172"
},
{
"name": "CVE-2024-46707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46707"
},
{
"name": "CVE-2024-49967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49967"
},
{
"name": "CVE-2024-41000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41000"
},
{
"name": "CVE-2024-36974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36974"
},
{
"name": "CVE-2023-52818",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52818"
},
{
"name": "CVE-2024-56606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56606"
},
{
"name": "CVE-2023-52637",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52637"
},
{
"name": "CVE-2024-46747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46747"
},
{
"name": "CVE-2024-49858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49858"
},
{
"name": "CVE-2023-52873",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52873"
},
{
"name": "CVE-2024-49948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49948"
},
{
"name": "CVE-2024-56594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56594"
},
{
"name": "CVE-2024-26754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26754"
},
{
"name": "CVE-2023-52858",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52858"
},
{
"name": "CVE-2024-46738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46738"
},
{
"name": "CVE-2023-45863",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45863"
},
{
"name": "CVE-2024-56756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56756"
},
{
"name": "CVE-2024-52332",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52332"
},
{
"name": "CVE-2024-46679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46679"
},
{
"name": "CVE-2024-56724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56724"
},
{
"name": "CVE-2024-53194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53194"
},
{
"name": "CVE-2024-49878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49878"
},
{
"name": "CVE-2023-51782",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51782"
},
{
"name": "CVE-2024-46673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46673"
},
{
"name": "CVE-2024-41034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41034"
},
{
"name": "CVE-2024-56723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56723"
},
{
"name": "CVE-2024-53226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53226"
},
{
"name": "CVE-2024-49884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49884"
},
{
"name": "CVE-2024-46724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46724"
},
{
"name": "CVE-2024-56569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56569"
},
{
"name": "CVE-2024-50074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50074"
},
{
"name": "CVE-2024-26790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26790"
},
{
"name": "CVE-2024-46791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46791"
},
{
"name": "CVE-2024-50024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50024"
},
{
"name": "CVE-2024-47684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47684"
},
{
"name": "CVE-2024-49965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49965"
},
{
"name": "CVE-2024-44969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44969"
},
{
"name": "CVE-2024-56634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56634"
},
{
"name": "CVE-2024-43098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43098"
},
{
"name": "CVE-2024-42236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42236"
},
{
"name": "CVE-2024-56548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56548"
},
{
"name": "CVE-2024-39469",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39469"
},
{
"name": "CVE-2024-39509",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39509"
},
{
"name": "CVE-2024-50202",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50202"
},
{
"name": "CVE-2023-5178",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5178"
},
{
"name": "CVE-2024-26845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26845"
},
{
"name": "CVE-2024-26704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26704"
},
{
"name": "CVE-2024-26671",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26671"
},
{
"name": "CVE-2024-46800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46800"
},
{
"name": "CVE-2023-52810",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52810"
},
{
"name": "CVE-2024-46750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46750"
},
{
"name": "CVE-2024-39484",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39484"
},
{
"name": "CVE-2024-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53181"
},
{
"name": "CVE-2024-46722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46722"
},
{
"name": "CVE-2024-26600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26600"
},
{
"name": "CVE-2024-47701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47701"
},
{
"name": "CVE-2024-40971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40971"
},
{
"name": "CVE-2023-52847",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52847"
},
{
"name": "CVE-2024-39505",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39505"
},
{
"name": "CVE-2023-52864",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52864"
},
{
"name": "CVE-2024-0646",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0646"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2024-47713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47713"
},
{
"name": "CVE-2024-49936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49936"
},
{
"name": "CVE-2024-50267",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50267"
},
{
"name": "CVE-2024-56637",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56637"
},
{
"name": "CVE-2024-47663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47663"
},
{
"name": "CVE-2024-40932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40932"
},
{
"name": "CVE-2024-49881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49881"
},
{
"name": "CVE-2023-52478",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52478"
},
{
"name": "CVE-2024-41006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41006"
},
{
"name": "CVE-2023-46343",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46343"
},
{
"name": "CVE-2024-46745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46745"
},
{
"name": "CVE-2024-46819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46819"
},
{
"name": "CVE-2024-49896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49896"
},
{
"name": "CVE-2024-40904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40904"
},
{
"name": "CVE-2024-42084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42084"
},
{
"name": "CVE-2024-49959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49959"
},
{
"name": "CVE-2024-49913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49913"
},
{
"name": "CVE-2024-56691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56691"
},
{
"name": "CVE-2024-46721",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46721"
},
{
"name": "CVE-2024-50045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50045"
},
{
"name": "CVE-2024-26805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26805"
},
{
"name": "CVE-2024-42153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42153"
},
{
"name": "CVE-2024-46822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46822"
},
{
"name": "CVE-2024-40960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40960"
},
{
"name": "CVE-2024-49995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49995"
},
{
"name": "CVE-2024-56643",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56643"
},
{
"name": "CVE-2025-40570",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40570"
},
{
"name": "CVE-2024-56661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56661"
},
{
"name": "CVE-2024-49977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49977"
},
{
"name": "CVE-2024-42154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42154"
},
{
"name": "CVE-2024-49900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49900"
},
{
"name": "CVE-2024-46685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46685"
},
{
"name": "CVE-2024-47679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47679"
},
{
"name": "CVE-2024-36484",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36484"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-44998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44998"
},
{
"name": "CVE-2024-46723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46723"
},
{
"name": "CVE-2024-42229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42229"
},
{
"name": "CVE-2024-26839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26839"
},
{
"name": "CVE-2024-46828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46828"
},
{
"name": "CVE-2024-50269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50269"
},
{
"name": "CVE-2024-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53150"
},
{
"name": "CVE-2024-47735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47735"
},
{
"name": "CVE-2024-49952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49952"
},
{
"name": "CVE-2024-49981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49981"
},
{
"name": "CVE-2024-56595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56595"
},
{
"name": "CVE-2024-42086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42086"
},
{
"name": "CVE-2024-26581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26581"
},
{
"name": "CVE-2022-48935",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48935"
},
{
"name": "CVE-2023-52433",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52433"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2024-41095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41095"
},
{
"name": "CVE-2024-56601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56601"
},
{
"name": "CVE-2023-52600",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52600"
},
{
"name": "CVE-2024-53057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53057"
},
{
"name": "CVE-2024-26910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26910"
},
{
"name": "CVE-2024-50181",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50181"
},
{
"name": "CVE-2023-52507",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52507"
},
{
"name": "CVE-2024-56571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56571"
},
{
"name": "CVE-2023-52764",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52764"
},
{
"name": "CVE-2023-52587",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52587"
},
{
"name": "CVE-2023-52887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52887"
},
{
"name": "CVE-2024-46675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46675"
},
{
"name": "CVE-2024-26645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26645"
},
{
"name": "CVE-2024-26702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26702"
},
{
"name": "CVE-2024-46783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46783"
},
{
"name": "CVE-2023-51779",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51779"
},
{
"name": "CVE-2024-42076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42076"
},
{
"name": "CVE-2024-26673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26673"
},
{
"name": "CVE-2024-49997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49997"
},
{
"name": "CVE-2024-42092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42092"
},
{
"name": "CVE-2024-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26720"
},
{
"name": "CVE-2024-0584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0584"
},
{
"name": "CVE-2024-42093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42093"
},
{
"name": "CVE-2024-42247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42247"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2024-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53066"
},
{
"name": "CVE-2023-52784",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52784"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2024-27413",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27413"
},
{
"name": "CVE-2024-56629",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56629"
},
{
"name": "CVE-2024-50304",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50304"
},
{
"name": "CVE-2024-40959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40959"
},
{
"name": "CVE-2024-26615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26615"
},
{
"name": "CVE-2023-52853",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52853"
},
{
"name": "CVE-2024-46689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46689"
},
{
"name": "CVE-2024-50295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50295"
},
{
"name": "CVE-2024-26801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26801"
},
{
"name": "CVE-2024-50051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50051"
},
{
"name": "CVE-2024-41078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41078"
},
{
"name": "CVE-2024-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53063"
},
{
"name": "CVE-2024-53171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53171"
},
{
"name": "CVE-2024-56602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56602"
},
{
"name": "CVE-2024-46781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46781"
},
{
"name": "CVE-2024-56770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56770"
},
{
"name": "CVE-2024-53157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53157"
},
{
"name": "CVE-2025-30034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30034"
},
{
"name": "CVE-2024-46777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46777"
},
{
"name": "CVE-2023-52340",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52340"
},
{
"name": "CVE-2024-50199",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50199"
},
{
"name": "CVE-2024-26779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26779"
},
{
"name": "CVE-2024-40916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40916"
},
{
"name": "CVE-2024-0193",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0193"
},
{
"name": "CVE-2023-52604",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52604"
},
{
"name": "CVE-2024-50040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50040"
},
{
"name": "CVE-2024-38586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38586"
},
{
"name": "CVE-2024-56739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56739"
},
{
"name": "CVE-2024-50292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50292"
},
{
"name": "CVE-2024-53103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53103"
},
{
"name": "CVE-2024-46714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46714"
},
{
"name": "CVE-2024-40976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40976"
},
{
"name": "CVE-2024-41081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41081"
},
{
"name": "CVE-2025-40746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40746"
},
{
"name": "CVE-2024-49983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49983"
},
{
"name": "CVE-2023-52601",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52601"
},
{
"name": "CVE-2024-41072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41072"
},
{
"name": "CVE-2024-44960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44960"
},
{
"name": "CVE-2024-26773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26773"
},
{
"name": "CVE-2024-26722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26722"
},
{
"name": "CVE-2024-54678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54678"
},
{
"name": "CVE-2024-26598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26598"
},
{
"name": "CVE-2024-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53197"
},
{
"name": "CVE-2024-26679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26679"
},
{
"name": "CVE-2024-39468",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39468"
},
{
"name": "CVE-2024-26763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26763"
},
{
"name": "CVE-2024-49889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49889"
},
{
"name": "CVE-2023-52435",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52435"
},
{
"name": "CVE-2024-40980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40980"
},
{
"name": "CVE-2023-52654",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52654"
},
{
"name": "CVE-2024-36938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36938"
},
{
"name": "CVE-2024-40974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40974"
},
{
"name": "CVE-2023-52855",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52855"
},
{
"name": "CVE-2024-56779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56779"
},
{
"name": "CVE-2024-26749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26749"
},
{
"name": "CVE-2024-44971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44971"
},
{
"name": "CVE-2023-52603",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52603"
},
{
"name": "CVE-2024-43894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43894"
},
{
"name": "CVE-2023-52486",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52486"
},
{
"name": "CVE-2024-43867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43867"
},
{
"name": "CVE-2023-52868",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52868"
},
{
"name": "CVE-2023-52619",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52619"
},
{
"name": "CVE-2023-52796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52796"
},
{
"name": "CVE-2023-52475",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52475"
},
{
"name": "CVE-2024-50013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50013"
},
{
"name": "CVE-2024-50185",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50185"
},
{
"name": "CVE-2024-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53239"
},
{
"name": "CVE-2023-52617",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52617"
},
{
"name": "CVE-2024-49957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49957"
},
{
"name": "CVE-2024-49962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49962"
},
{
"name": "CVE-2024-46731",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46731"
},
{
"name": "CVE-2024-39502",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39502"
},
{
"name": "CVE-2024-46674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46674"
},
{
"name": "CVE-2023-52836",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52836"
},
{
"name": "CVE-2024-26804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26804"
},
{
"name": "CVE-2024-26593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26593"
},
{
"name": "CVE-2024-26751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26751"
},
{
"name": "CVE-2024-49958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49958"
},
{
"name": "CVE-2024-50082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50082"
},
{
"name": "CVE-2024-47723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47723"
},
{
"name": "CVE-2024-49955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49955"
},
{
"name": "CVE-2024-42087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42087"
},
{
"name": "CVE-2024-44944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44944"
},
{
"name": "CVE-2024-43893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43893"
},
{
"name": "CVE-2024-50095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50095"
},
{
"name": "CVE-2024-40983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40983"
},
{
"name": "CVE-2024-50296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50296"
},
{
"name": "CVE-2024-57874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57874"
},
{
"name": "CVE-2024-53145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53145"
},
{
"name": "CVE-2024-50006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50006"
},
{
"name": "CVE-2022-49034",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49034"
},
{
"name": "CVE-2024-50049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50049"
},
{
"name": "CVE-2024-27412",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27412"
},
{
"name": "CVE-2024-26636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26636"
},
{
"name": "CVE-2024-56642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56642"
},
{
"name": "CVE-2024-50007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50007"
},
{
"name": "CVE-2024-56586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56586"
},
{
"name": "CVE-2023-39198",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39198"
},
{
"name": "CVE-2024-40963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40963"
},
{
"name": "CVE-2025-40752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40752"
},
{
"name": "CVE-2024-41041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41041"
},
{
"name": "CVE-2024-50096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50096"
},
{
"name": "CVE-2023-52789",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52789"
},
{
"name": "CVE-2024-49868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49868"
},
{
"name": "CVE-2024-40947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40947"
},
{
"name": "CVE-2024-53173",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53173"
},
{
"name": "CVE-2024-50237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50237"
},
{
"name": "CVE-2023-52867",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52867"
},
{
"name": "CVE-2024-44995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44995"
},
{
"name": "CVE-2024-46757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46757"
},
{
"name": "CVE-2024-42232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42232"
},
{
"name": "CVE-2024-47699",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47699"
},
{
"name": "CVE-2024-56581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56581"
},
{
"name": "CVE-2024-46677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46677"
},
{
"name": "CVE-2024-50059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50059"
},
{
"name": "CVE-2024-50264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50264"
},
{
"name": "CVE-2024-26606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26606"
},
{
"name": "CVE-2024-35833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35833"
},
{
"name": "CVE-2024-41005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41005"
},
{
"name": "CVE-2024-43883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43883"
},
{
"name": "CVE-2024-56623",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56623"
},
{
"name": "CVE-2024-26625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26625"
},
{
"name": "CVE-2024-44935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44935"
},
{
"name": "CVE-2024-44999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44999"
},
{
"name": "CVE-2024-47712",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47712"
},
{
"name": "CVE-2024-56610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56610"
},
{
"name": "CVE-2024-26748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26748"
},
{
"name": "CVE-2023-52809",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52809"
},
{
"name": "CVE-2024-42223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42223"
},
{
"name": "CVE-2024-49963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49963"
},
{
"name": "CVE-2024-49971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49971"
},
{
"name": "CVE-2024-56562",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56562"
},
{
"name": "CVE-2024-26635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26635"
},
{
"name": "CVE-2023-52805",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52805"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2024-49875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49875"
},
{
"name": "CVE-2024-47739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47739"
},
{
"name": "CVE-2024-47705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47705"
},
{
"name": "CVE-2024-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53161"
},
{
"name": "CVE-2023-52919",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52919"
},
{
"name": "CVE-2024-50035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50035"
},
{
"name": "CVE-2024-56600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56600"
},
{
"name": "CVE-2024-36978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36978"
},
{
"name": "CVE-2024-44988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44988"
},
{
"name": "CVE-2024-47660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47660"
},
{
"name": "CVE-2024-56690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56690"
},
{
"name": "CVE-2024-56597",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56597"
},
{
"name": "CVE-2024-40905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40905"
},
{
"name": "CVE-2024-56574",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56574"
},
{
"name": "CVE-2024-47740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47740"
},
{
"name": "CVE-2024-41063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41063"
},
{
"name": "CVE-2024-41017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41017"
},
{
"name": "CVE-2024-26697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26697"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2024-49924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49924"
},
{
"name": "CVE-2024-46758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46758"
},
{
"name": "CVE-2024-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53217"
},
{
"name": "CVE-2024-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53183"
},
{
"name": "CVE-2024-49938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49938"
},
{
"name": "CVE-2024-41012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41012"
},
{
"name": "CVE-2024-40902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40902"
},
{
"name": "CVE-2024-47756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47756"
},
{
"name": "CVE-2024-40934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40934"
},
{
"name": "CVE-2024-47667",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47667"
},
{
"name": "CVE-2024-46756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46756"
},
{
"name": "CVE-2024-56615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56615"
},
{
"name": "CVE-2024-47737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47737"
},
{
"name": "CVE-2024-46739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46739"
},
{
"name": "CVE-2024-47669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47669"
},
{
"name": "CVE-2024-56705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56705"
},
{
"name": "CVE-2024-50290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50290"
},
{
"name": "CVE-2024-50008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50008"
},
{
"name": "CVE-2024-42082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42082"
},
{
"name": "CVE-2024-26685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26685"
},
{
"name": "CVE-2024-56704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56704"
},
{
"name": "CVE-2024-45006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45006"
},
{
"name": "CVE-2024-46725",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46725"
},
{
"name": "CVE-2024-46829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46829"
},
{
"name": "CVE-2024-40912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40912"
},
{
"name": "CVE-2023-52599",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52599"
},
{
"name": "CVE-2024-56589",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56589"
},
{
"name": "CVE-2024-50265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50265"
},
{
"name": "CVE-2024-56636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56636"
},
{
"name": "CVE-2024-41089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41089"
},
{
"name": "CVE-2024-39487",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39487"
},
{
"name": "CVE-2024-56567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56567"
},
{
"name": "CVE-2024-44954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44954"
},
{
"name": "CVE-2024-43908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43908"
},
{
"name": "CVE-2023-3567",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3567"
},
{
"name": "CVE-2024-50033",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50033"
},
{
"name": "CVE-2024-43890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43890"
},
{
"name": "CVE-2024-26688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26688"
},
{
"name": "CVE-2023-52865",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52865"
},
{
"name": "CVE-2024-49901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49901"
},
{
"name": "CVE-2024-36901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36901"
},
{
"name": "CVE-2024-56688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56688"
},
{
"name": "CVE-2024-41090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41090"
},
{
"name": "CVE-2024-50180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50180"
},
{
"name": "CVE-2024-26663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26663"
},
{
"name": "CVE-2024-50282",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50282"
},
{
"name": "CVE-2024-50273",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50273"
},
{
"name": "CVE-2024-26675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26675"
},
{
"name": "CVE-2024-56532",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56532"
},
{
"name": "CVE-2024-41077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41077"
},
{
"name": "CVE-2024-47143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47143"
},
{
"name": "CVE-2024-49949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49949"
},
{
"name": "CVE-2023-52509",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52509"
},
{
"name": "CVE-2024-44952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44952"
},
{
"name": "CVE-2023-52753",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52753"
},
{
"name": "CVE-2024-26840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26840"
},
{
"name": "CVE-2024-50046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50046"
},
{
"name": "CVE-2023-52583",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52583"
},
{
"name": "CVE-2024-50099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50099"
},
{
"name": "CVE-2024-50193",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50193"
},
{
"name": "CVE-2024-46743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46743"
},
{
"name": "CVE-2024-49944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49944"
},
{
"name": "CVE-2023-52602",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52602"
},
{
"name": "CVE-2024-50198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50198"
},
{
"name": "CVE-2023-52832",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52832"
},
{
"name": "CVE-2024-56746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56746"
},
{
"name": "CVE-2024-47749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47749"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2024-49966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49966"
},
{
"name": "CVE-2024-40995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40995"
},
{
"name": "CVE-2024-41087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41087"
},
{
"name": "CVE-2023-52819",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52819"
},
{
"name": "CVE-2023-52876",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52876"
},
{
"name": "CVE-2024-42095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42095"
},
{
"name": "CVE-2024-49902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49902"
},
{
"name": "CVE-2024-47757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47757"
},
{
"name": "CVE-2025-30033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30033"
},
{
"name": "CVE-2024-27417",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27417"
},
{
"name": "CVE-2024-48881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48881"
},
{
"name": "CVE-2024-47692",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47692"
},
{
"name": "CVE-2024-46744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46744"
},
{
"name": "CVE-2024-0841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0841"
},
{
"name": "CVE-2025-40753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40753"
},
{
"name": "CVE-2024-50184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50184"
},
{
"name": "CVE-2024-40929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40929"
},
{
"name": "CVE-2024-39501",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39501"
},
{
"name": "CVE-2024-52504",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52504"
},
{
"name": "CVE-2024-50287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50287"
},
{
"name": "CVE-2024-56747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56747"
},
{
"name": "CVE-2024-49851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49851"
},
{
"name": "CVE-2023-6040",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6040"
},
{
"name": "CVE-2023-52510",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52510"
},
{
"name": "CVE-2023-51781",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51781"
},
{
"name": "CVE-2024-56603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56603"
},
{
"name": "CVE-2024-53158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53158"
},
{
"name": "CVE-2024-43882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43882"
},
{
"name": "CVE-2024-41068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41068"
},
{
"name": "CVE-2024-56644",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56644"
},
{
"name": "CVE-2024-46780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46780"
},
{
"name": "CVE-2024-46817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46817"
},
{
"name": "CVE-2024-42101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42101"
},
{
"name": "CVE-2025-40751",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40751"
},
{
"name": "CVE-2024-50278",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50278"
},
{
"name": "CVE-2024-50201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50201"
},
{
"name": "CVE-2024-35835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35835"
},
{
"name": "CVE-2024-56701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56701"
},
{
"name": "CVE-2024-42077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42077"
},
{
"name": "CVE-2023-52670",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52670"
},
{
"name": "CVE-2024-40943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40943"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-49933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49933"
},
{
"name": "CVE-2024-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53184"
},
{
"name": "CVE-2024-47685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47685"
},
{
"name": "CVE-2024-40901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40901"
},
{
"name": "CVE-2022-48829",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48829"
},
{
"name": "CVE-2024-53174",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53174"
},
{
"name": "CVE-2024-49879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49879"
},
{
"name": "CVE-2024-39495",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39495"
},
{
"name": "CVE-2024-50044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50044"
},
{
"name": "CVE-2024-49894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49894"
},
{
"name": "CVE-2024-56700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56700"
},
{
"name": "CVE-2024-47718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47718"
},
{
"name": "CVE-2024-49867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49867"
},
{
"name": "CVE-2023-51780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51780"
},
{
"name": "CVE-2024-49985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49985"
},
{
"name": "CVE-2024-50001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50001"
},
{
"name": "CVE-2023-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52881"
},
{
"name": "CVE-2024-49993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49993"
},
{
"name": "CVE-2024-56728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56728"
},
{
"name": "CVE-2024-43861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43861"
},
{
"name": "CVE-2024-53241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53241"
},
{
"name": "CVE-2023-52838",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52838"
},
{
"name": "CVE-2024-47710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47710"
},
{
"name": "CVE-2024-46771",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46771"
},
{
"name": "CVE-2024-50083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50083"
},
{
"name": "CVE-2023-52774",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52774"
},
{
"name": "CVE-2024-56531",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56531"
},
{
"name": "CVE-2024-49892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49892"
},
{
"name": "CVE-2024-49930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49930"
},
{
"name": "CVE-2024-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53148"
},
{
"name": "CVE-2024-47698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47698"
},
{
"name": "CVE-2023-52879",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52879"
},
{
"name": "CVE-2024-56681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56681"
},
{
"name": "CVE-2024-26602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26602"
},
{
"name": "CVE-2023-52799",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52799"
},
{
"name": "CVE-2024-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38619"
},
{
"name": "CVE-2024-50039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50039"
},
{
"name": "CVE-2024-50251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50251"
},
{
"name": "CVE-2024-56754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56754"
},
{
"name": "CVE-2024-49973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49973"
},
{
"name": "CVE-2024-53214",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53214"
},
{
"name": "CVE-2024-39476",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39476"
},
{
"name": "CVE-2024-46804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46804"
},
{
"name": "CVE-2024-56619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56619"
},
{
"name": "CVE-2024-47668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47668"
},
{
"name": "CVE-2024-49883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49883"
},
{
"name": "CVE-2024-53165",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53165"
},
{
"name": "CVE-2024-50236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50236"
},
{
"name": "CVE-2024-46840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46840"
},
{
"name": "CVE-2022-48828",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48828"
},
{
"name": "CVE-2024-56568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56568"
},
{
"name": "CVE-2024-46763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46763"
},
{
"name": "CVE-2024-41059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41059"
},
{
"name": "CVE-2024-42094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42094"
},
{
"name": "CVE-2024-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53146"
},
{
"name": "CVE-2024-46759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46759"
},
{
"name": "CVE-2024-27416",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27416"
},
{
"name": "CVE-2023-52598",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52598"
},
{
"name": "CVE-2024-46737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46737"
},
{
"name": "CVE-2024-41040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41040"
},
{
"name": "CVE-2023-6606",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6606"
},
{
"name": "CVE-2024-40987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40987"
},
{
"name": "CVE-2024-56539",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56539"
},
{
"name": "CVE-2023-52806",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52806"
},
{
"name": "CVE-2024-56662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56662"
},
{
"name": "CVE-2024-46814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46814"
},
{
"name": "CVE-2024-56572",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56572"
},
{
"name": "CVE-2024-56570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56570"
},
{
"name": "CVE-2024-26793",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26793"
},
{
"name": "CVE-2024-40945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40945"
},
{
"name": "CVE-2024-46818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46818"
},
{
"name": "CVE-2023-6932",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6932"
},
{
"name": "CVE-2024-50602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50602"
},
{
"name": "CVE-2024-40941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40941"
},
{
"name": "CVE-2022-48827",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48827"
},
{
"name": "CVE-2023-52594",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52594"
},
{
"name": "CVE-2024-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53198"
},
{
"name": "CVE-2024-44965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44965"
},
{
"name": "CVE-2024-49860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49860"
},
{
"name": "CVE-2024-45003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45003"
},
{
"name": "CVE-2024-41055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41055"
},
{
"name": "CVE-2023-52595",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52595"
},
{
"name": "CVE-2025-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47809"
},
{
"name": "CVE-2024-50234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50234"
},
{
"name": "CVE-2024-56720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56720"
},
{
"name": "CVE-2024-26752",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26752"
},
{
"name": "CVE-2024-41015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41015"
},
{
"name": "CVE-2024-53155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53155"
},
{
"name": "CVE-2024-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40984"
},
{
"name": "CVE-2024-42224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42224"
},
{
"name": "CVE-2024-50194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50194"
},
{
"name": "CVE-2024-46832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46832"
},
{
"name": "CVE-2023-52871",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52871"
},
{
"name": "CVE-2024-49895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49895"
},
{
"name": "CVE-2024-56785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56785"
},
{
"name": "CVE-2023-52623",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52623"
},
{
"name": "CVE-2024-26736",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26736"
},
{
"name": "CVE-2024-56587",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56587"
},
{
"name": "CVE-2024-45021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45021"
},
{
"name": "CVE-2023-52655",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52655"
},
{
"name": "CVE-2024-49882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49882"
},
{
"name": "CVE-2024-47659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47659"
},
{
"name": "CVE-2024-42161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42161"
},
{
"name": "CVE-2023-52813",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52813"
},
{
"name": "CVE-2024-56741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56741"
},
{
"name": "CVE-2023-52504",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52504"
},
{
"name": "CVE-2024-39506",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39506"
},
{
"name": "CVE-2024-40990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40990"
},
{
"name": "CVE-2024-40978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40978"
},
{
"name": "CVE-2024-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53104"
},
{
"name": "CVE-2023-52615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52615"
},
{
"name": "CVE-2024-40968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40968"
},
{
"name": "CVE-2024-45025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45025"
},
{
"name": "CVE-2024-27414",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27414"
},
{
"name": "CVE-2024-56748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56748"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2024-56648",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56648"
},
{
"name": "CVE-2024-26777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26777"
},
{
"name": "CVE-2024-41049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41049"
},
{
"name": "CVE-2024-26764",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26764"
},
{
"name": "CVE-2024-42143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42143"
},
{
"name": "CVE-2021-47316",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47316"
},
{
"name": "CVE-2024-56558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56558"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2024-43879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43879"
},
{
"name": "CVE-2024-46761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46761"
},
{
"name": "CVE-2023-52606",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52606"
},
{
"name": "CVE-2024-50301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50301"
},
{
"name": "CVE-2024-26778",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26778"
},
{
"name": "CVE-2024-37078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37078"
},
{
"name": "CVE-2024-49975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49975"
},
{
"name": "CVE-2024-53240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53240"
},
{
"name": "CVE-2024-50179",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50179"
},
{
"name": "CVE-2024-53101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53101"
},
{
"name": "CVE-2024-47696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47696"
},
{
"name": "CVE-2023-52840",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52840"
},
{
"name": "CVE-2024-53156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53156"
},
{
"name": "CVE-2023-52502",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52502"
},
{
"name": "CVE-2024-41091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41091"
},
{
"name": "CVE-2024-42105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42105"
},
{
"name": "CVE-2024-50015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50015"
},
{
"name": "CVE-2023-52597",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52597"
},
{
"name": "CVE-2024-41044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41044"
},
{
"name": "CVE-2024-40958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40958"
},
{
"name": "CVE-2023-52581",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52581"
},
{
"name": "CVE-2024-45008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45008"
},
{
"name": "CVE-2024-50188",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50188"
},
{
"name": "CVE-2024-56533",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56533"
},
{
"name": "CVE-2024-40981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40981"
},
{
"name": "CVE-2023-52917",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52917"
},
{
"name": "CVE-2024-56598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56598"
},
{
"name": "CVE-2024-1086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1086"
},
{
"name": "CVE-2024-53060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53060"
},
{
"name": "CVE-2023-52875",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52875"
},
{
"name": "CVE-2024-44990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44990"
},
{
"name": "CVE-2024-44987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44987"
},
{
"name": "CVE-2024-56781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56781"
},
{
"name": "CVE-2024-41046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41046"
},
{
"name": "CVE-2024-50089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50089"
},
{
"name": "CVE-2024-56630",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56630"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2024-49982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49982"
},
{
"name": "CVE-2023-52835",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52835"
},
{
"name": "CVE-2024-53059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53059"
},
{
"name": "CVE-2024-50299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50299"
},
{
"name": "CVE-2024-50218",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50218"
},
{
"name": "CVE-2024-42148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42148"
},
{
"name": "CVE-2024-39482",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39482"
},
{
"name": "CVE-2024-39499",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39499"
},
{
"name": "CVE-2024-56633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56633"
},
{
"name": "CVE-2024-56593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56593"
},
{
"name": "CVE-2024-56605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56605"
},
{
"name": "CVE-2024-53680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53680"
},
{
"name": "CVE-2024-26835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26835"
},
{
"name": "CVE-2024-26791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26791"
},
{
"name": "CVE-2023-52843",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52843"
},
{
"name": "CVE-2024-50279",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50279"
},
{
"name": "CVE-2024-41064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41064"
},
{
"name": "CVE-2024-36894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36894"
},
{
"name": "CVE-2024-56698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56698"
},
{
"name": "CVE-2024-47742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47742"
},
{
"name": "CVE-2024-47709",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47709"
},
{
"name": "CVE-2024-41020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41020"
},
{
"name": "CVE-2024-26772",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26772"
},
{
"name": "CVE-2024-46782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46782"
},
{
"name": "CVE-2024-56780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56780"
},
{
"name": "CVE-2024-47706",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47706"
},
{
"name": "CVE-2024-27405",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27405"
},
{
"name": "CVE-2024-46702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46702"
},
{
"name": "CVE-2023-5717",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5717"
},
{
"name": "CVE-2024-47747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47747"
},
{
"name": "CVE-2024-40942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40942"
},
{
"name": "CVE-2024-26766",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26766"
},
{
"name": "CVE-2023-5678",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5678"
},
{
"name": "CVE-2024-26664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26664"
},
{
"name": "CVE-2024-46719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46719"
},
{
"name": "CVE-2024-49877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49877"
},
{
"name": "CVE-2023-52791",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52791"
},
{
"name": "CVE-2024-44949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44949"
},
{
"name": "CVE-2023-6121",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6121"
},
{
"name": "CVE-2023-52607",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52607"
},
{
"name": "CVE-2024-56650",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56650"
},
{
"name": "CVE-2024-44989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44989"
},
{
"name": "CVE-2024-26788",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26788"
},
{
"name": "CVE-2023-52817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52817"
},
{
"name": "CVE-2024-27410",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27410"
},
{
"name": "CVE-2024-26684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26684"
},
{
"name": "CVE-2024-53237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53237"
},
{
"name": "CVE-2023-6931",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6931"
},
{
"name": "CVE-2024-56576",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56576"
},
{
"name": "CVE-2024-42145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42145"
},
{
"name": "CVE-2024-40961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40961"
},
{
"name": "CVE-2024-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53227"
}
],
"links": [],
"reference": "CERTFR-2025-AVI-0677",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-08-12T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits Siemens. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits Siemens",
"vendor_advisories": [
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-707630",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-707630.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-331739",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-331739.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-693808",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-693808.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-613116",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-493396",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-493396.html"
},
{
"published_at": "2025-08-11",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens ssa-400089",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-400089.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-493787",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-493787.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-894058",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-894058.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-355557",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-529291",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-529291.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-282044",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-282044.html"
}
]
}
CERTFR-2026-AVI-1165
Vulnerability from certfr_avis - Published: 2026-09-11 - Updated: 2026-09-11
De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| IBM | Db2 | Db2 Common Container sans le correctif de sécurité 1159cn3 | ||
| IBM | Informix Dynamic Server | Informix Dynamic Server versions 15.0.x antérieures à 15.0.1.14 | ||
| IBM | QRadar Hub | QRadar Hub versions antérieures à 3.9.1 | ||
| IBM | WebSphere Application Server | WebSphere Application Server Liberty versions antérieures à 26.0.0.10 (disponibilité prévue pour le quatrième trimestre 2026) | ||
| IBM | Informix Dynamic Server | Informix Dynamic Server versions 12.10 antérieures à InformixHQ 3.3.1 | ||
| IBM | Informix Dynamic Server | Informix Dynamic Server versions 14.10.x antérieures à 14.10.xC14 | ||
| IBM | Db2 | Db2 versions V11.5.x sans le correctif de sécurité DT495924, DT474170, DT495462, DT470425 et DT501356 | ||
| IBM | Sterling Partner Engagement Manager Essentials Edition | Sterling Partner Engagement Manager Essentials Edition versions 6.2.4.x antérieures à 6.2.4.5 | ||
| IBM | Db2 | Db2 Bridge versions antérieures à 1.1.5.2 | ||
| IBM | Db2 | Db2 Warehouse on Cloud Pak for Data versions antérieures à v5.4 patch 6 | ||
| IBM | Sterling Partner Engagement Manager Standard Edition | Sterling Partner Engagement Manager Standard Edition versions 6.2.4.x antérieures à 6.2.4.5 | ||
| IBM | Db2 | Db2 Developer Extension versions 1.1.x antérieures à 1.1.2 | ||
| IBM | Sterling Partner Engagement Manager Essentials Edition | Sterling Partner Engagement Manager Essentials Edition versions 6.3.0.x antérieures à 6.3.0.3 | ||
| IBM | Db2 | Db2 on Cloud Pak for Data versions antérieures à v5.4 patch 6 | ||
| IBM | Db2 | Db2 versions V12.1 sans le correctif de sécurité DT495924, DT495462 et DT474170 |
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Db2 Common Container sans le correctif de s\u00e9curit\u00e9 1159cn3",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Informix Dynamic Server versions 15.0.x ant\u00e9rieures \u00e0 15.0.1.14",
"product": {
"name": "Informix Dynamic Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "QRadar Hub versions ant\u00e9rieures \u00e0 3.9.1",
"product": {
"name": "QRadar Hub",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "WebSphere Application Server Liberty versions ant\u00e9rieures \u00e0 26.0.0.10 (disponibilit\u00e9 pr\u00e9vue pour le quatri\u00e8me trimestre 2026)",
"product": {
"name": "WebSphere Application Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Informix Dynamic Server versions 12.10 ant\u00e9rieures \u00e0 InformixHQ 3.3.1",
"product": {
"name": "Informix Dynamic Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Informix Dynamic Server versions 14.10.x ant\u00e9rieures \u00e0 14.10.xC14",
"product": {
"name": "Informix Dynamic Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 versions V11.5.x sans le correctif de s\u00e9curit\u00e9 DT495924, DT474170, DT495462, DT470425 et DT501356",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Partner Engagement Manager Essentials Edition versions 6.2.4.x ant\u00e9rieures \u00e0 6.2.4.5",
"product": {
"name": "Sterling Partner Engagement Manager Essentials Edition",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 Bridge versions ant\u00e9rieures \u00e0 1.1.5.2",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 Warehouse on Cloud Pak for Data versions ant\u00e9rieures \u00e0 v5.4 patch 6",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Partner Engagement Manager Standard Edition versions 6.2.4.x ant\u00e9rieures \u00e0 6.2.4.5",
"product": {
"name": "Sterling Partner Engagement Manager Standard Edition",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 Developer Extension versions 1.1.x ant\u00e9rieures \u00e0 1.1.2",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Partner Engagement Manager Essentials Edition versions 6.3.0.x ant\u00e9rieures \u00e0 6.3.0.3",
"product": {
"name": "Sterling Partner Engagement Manager Essentials Edition",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 on Cloud Pak for Data versions ant\u00e9rieures \u00e0 v5.4 patch 6",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 versions V12.1 sans le correctif de s\u00e9curit\u00e9 DT495924, DT495462 et DT474170",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2026-75595",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75595"
},
{
"name": "CVE-2026-49978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49978"
},
{
"name": "CVE-2024-40931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40931"
},
{
"name": "CVE-2023-52471",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52471"
},
{
"name": "CVE-2026-5588",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5588"
},
{
"name": "CVE-2021-33036",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33036"
},
{
"name": "CVE-2021-44906",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44906"
},
{
"name": "CVE-2026-54264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54264"
},
{
"name": "CVE-2024-50142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50142"
},
{
"name": "CVE-2026-59651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59651"
},
{
"name": "CVE-2026-45819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45819"
},
{
"name": "CVE-2024-46826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46826"
},
{
"name": "CVE-2024-42070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42070"
},
{
"name": "CVE-2024-36889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36889"
},
{
"name": "CVE-2023-52675",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52675"
},
{
"name": "CVE-2024-35810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35810"
},
{
"name": "CVE-2026-50557",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50557"
},
{
"name": "CVE-2024-41093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41093"
},
{
"name": "CVE-2026-59295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59295"
},
{
"name": "CVE-2023-52834",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52834"
},
{
"name": "CVE-2024-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38627"
},
{
"name": "CVE-2023-43642",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-43642"
},
{
"name": "CVE-2021-21409",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-21409"
},
{
"name": "CVE-2023-52622",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52622"
},
{
"name": "CVE-2018-14042",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14042"
},
{
"name": "CVE-2024-35939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35939"
},
{
"name": "CVE-2025-2534",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2534"
},
{
"name": "CVE-2024-38555",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38555"
},
{
"name": "CVE-2024-41009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41009"
},
{
"name": "CVE-2026-41254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41254"
},
{
"name": "CVE-2024-36921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36921"
},
{
"name": "CVE-2024-36939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36939"
},
{
"name": "CVE-2024-39503",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39503"
},
{
"name": "CVE-2024-26656",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26656"
},
{
"name": "CVE-2024-42246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42246"
},
{
"name": "CVE-2024-26614",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26614"
},
{
"name": "CVE-2026-16480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16480"
},
{
"name": "CVE-2018-1334",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1334"
},
{
"name": "CVE-2023-52762",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52762"
},
{
"name": "CVE-2024-26974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26974"
},
{
"name": "CVE-2024-40988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40988"
},
{
"name": "CVE-2026-32990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32990"
},
{
"name": "CVE-2024-26595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26595"
},
{
"name": "CVE-2026-50645",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50645"
},
{
"name": "CVE-2026-22610",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22610"
},
{
"name": "CVE-2024-42292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42292"
},
{
"name": "CVE-2026-42041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42041"
},
{
"name": "CVE-2014-125087",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-125087"
},
{
"name": "CVE-2026-14686",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14686"
},
{
"name": "CVE-2026-68763",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68763"
},
{
"name": "CVE-2023-1370",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1370"
},
{
"name": "CVE-2026-45416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45416"
},
{
"name": "CVE-2024-36904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36904"
},
{
"name": "CVE-2023-52845",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52845"
},
{
"name": "CVE-2023-33201",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-33201"
},
{
"name": "CVE-2026-10050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10050"
},
{
"name": "CVE-2024-27010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27010"
},
{
"name": "CVE-2024-42284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42284"
},
{
"name": "CVE-2024-35912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35912"
},
{
"name": "CVE-2021-47432",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47432"
},
{
"name": "CVE-2026-53666",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53666"
},
{
"name": "CVE-2024-25739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25739"
},
{
"name": "CVE-2026-59648",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59648"
},
{
"name": "CVE-2026-69153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69153"
},
{
"name": "CVE-2026-3621",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3621"
},
{
"name": "CVE-2026-43515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43515"
},
{
"name": "CVE-2026-42402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42402"
},
{
"name": "CVE-2021-47304",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47304"
},
{
"name": "CVE-2024-35807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35807"
},
{
"name": "CVE-2022-48632",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48632"
},
{
"name": "CVE-2026-43868",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43868"
},
{
"name": "CVE-2026-50560",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50560"
},
{
"name": "CVE-2024-26586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26586"
},
{
"name": "CVE-2024-41060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41060"
},
{
"name": "CVE-2015-5237",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-5237"
},
{
"name": "CVE-2026-71290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-71290"
},
{
"name": "CVE-2019-10099",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-10099"
},
{
"name": "CVE-2024-26585",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26585"
},
{
"name": "CVE-2026-41716",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41716"
},
{
"name": "CVE-2018-11760",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11760"
},
{
"name": "CVE-2026-15328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15328"
},
{
"name": "CVE-2026-59645",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59645"
},
{
"name": "CVE-2022-45688",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45688"
},
{
"name": "CVE-2024-26961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26961"
},
{
"name": "CVE-2024-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38608"
},
{
"name": "CVE-2024-23944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23944"
},
{
"name": "CVE-2022-33891",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-33891"
},
{
"name": "CVE-2024-50275",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50275"
},
{
"name": "CVE-2026-13006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13006"
},
{
"name": "CVE-2024-26638",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26638"
},
{
"name": "CVE-2018-8024",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8024"
},
{
"name": "CVE-2021-47284",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47284"
},
{
"name": "CVE-2024-27397",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27397"
},
{
"name": "CVE-2024-49350",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49350"
},
{
"name": "CVE-2022-48619",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48619"
},
{
"name": "CVE-2024-46679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46679"
},
{
"name": "CVE-2025-66412",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66412"
},
{
"name": "CVE-2025-36131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36131"
},
{
"name": "CVE-2024-36945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36945"
},
{
"name": "CVE-2023-52653",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52653"
},
{
"name": "CVE-2026-54514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54514"
},
{
"name": "CVE-2023-52756",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52756"
},
{
"name": "CVE-2024-40924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40924"
},
{
"name": "CVE-2018-14040",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14040"
},
{
"name": "CVE-2024-35854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35854"
},
{
"name": "CVE-2024-28757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28757"
},
{
"name": "CVE-2026-77414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77414"
},
{
"name": "CVE-2020-11988",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11988"
},
{
"name": "CVE-2021-46939",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46939"
},
{
"name": "CVE-2025-56200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-56200"
},
{
"name": "CVE-2024-37071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37071"
},
{
"name": "CVE-2026-77413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77413"
},
{
"name": "CVE-2023-52878",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52878"
},
{
"name": "CVE-2026-54399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54399"
},
{
"name": "CVE-2026-53668",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53668"
},
{
"name": "CVE-2024-41038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41038"
},
{
"name": "CVE-2025-30065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30065"
},
{
"name": "CVE-2026-16243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16243"
},
{
"name": "CVE-2016-4055",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-4055"
},
{
"name": "CVE-2026-9171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9171"
},
{
"name": "CVE-2026-67214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67214"
},
{
"name": "CVE-2024-37356",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37356"
},
{
"name": "CVE-2022-48743",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48743"
},
{
"name": "CVE-2024-25638",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25638"
},
{
"name": "CVE-2026-12185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12185"
},
{
"name": "CVE-2026-59921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59921"
},
{
"name": "CVE-2024-47118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47118"
},
{
"name": "CVE-2024-35824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35824"
},
{
"name": "CVE-2026-47010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47010"
},
{
"name": "CVE-2023-45853",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45853"
},
{
"name": "CVE-2024-26704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26704"
},
{
"name": "CVE-2024-35925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35925"
},
{
"name": "CVE-2023-45288",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45288"
},
{
"name": "CVE-2024-36886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36886"
},
{
"name": "CVE-2024-26976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26976"
},
{
"name": "CVE-2026-14685",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14685"
},
{
"name": "CVE-2023-52803",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52803"
},
{
"name": "CVE-2023-45178",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45178"
},
{
"name": "CVE-2026-54171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54171"
},
{
"name": "CVE-2024-21823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21823"
},
{
"name": "CVE-2022-31160",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31160"
},
{
"name": "CVE-2021-47441",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47441"
},
{
"name": "CVE-2020-10683",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-10683"
},
{
"name": "CVE-2018-1273",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1273"
},
{
"name": "CVE-2026-41239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41239"
},
{
"name": "CVE-2024-26600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26600"
},
{
"name": "CVE-2026-33814",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33814"
},
{
"name": "CVE-2023-28746",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28746"
},
{
"name": "CVE-2026-47891",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47891"
},
{
"name": "CVE-2023-52847",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52847"
},
{
"name": "CVE-2024-42114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42114"
},
{
"name": "CVE-2020-26945",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26945"
},
{
"name": "CVE-2023-52864",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52864"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2026-68569",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68569"
},
{
"name": "CVE-2026-59084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59084"
},
{
"name": "CVE-2026-65183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65183"
},
{
"name": "CVE-2024-35897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35897"
},
{
"name": "CVE-2026-14257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14257"
},
{
"name": "CVE-2026-41901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41901"
},
{
"name": "CVE-2026-73088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73088"
},
{
"name": "CVE-2023-52478",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52478"
},
{
"name": "CVE-2024-23945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23945"
},
{
"name": "CVE-2021-41182",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41182"
},
{
"name": "CVE-2024-38596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38596"
},
{
"name": "CVE-2022-25647",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25647"
},
{
"name": "CVE-2026-9072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9072"
},
{
"name": "CVE-2022-26612",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26612"
},
{
"name": "CVE-2024-36929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36929"
},
{
"name": "CVE-2024-26802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26802"
},
{
"name": "CVE-2026-18097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18097"
},
{
"name": "CVE-2024-40904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40904"
},
{
"name": "CVE-2024-42084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42084"
},
{
"name": "CVE-2021-47455",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47455"
},
{
"name": "CVE-2023-52492",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52492"
},
{
"name": "CVE-2022-36364",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36364"
},
{
"name": "CVE-2026-73089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73089"
},
{
"name": "CVE-2023-34610",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34610"
},
{
"name": "CVE-2026-47057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47057"
},
{
"name": "CVE-2024-47561",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47561"
},
{
"name": "CVE-2023-52669",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52669"
},
{
"name": "CVE-2024-36883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36883"
},
{
"name": "CVE-2024-31881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31881"
},
{
"name": "CVE-2019-11358",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-11358"
},
{
"name": "CVE-2026-69152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69152"
},
{
"name": "CVE-2024-26665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26665"
},
{
"name": "CVE-2026-68525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68525"
},
{
"name": "CVE-2024-27062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27062"
},
{
"name": "CVE-2026-59901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59901"
},
{
"name": "CVE-2024-40960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40960"
},
{
"name": "CVE-2024-35839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35839"
},
{
"name": "CVE-2024-26852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26852"
},
{
"name": "CVE-2024-40997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40997"
},
{
"name": "CVE-2024-27395",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27395"
},
{
"name": "CVE-2026-14525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14525"
},
{
"name": "CVE-2026-67313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67313"
},
{
"name": "CVE-2020-13955",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-13955"
},
{
"name": "CVE-2024-42154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42154"
},
{
"name": "CVE-2024-42228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42228"
},
{
"name": "CVE-2026-8858",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8858"
},
{
"name": "CVE-2026-42580",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42580"
},
{
"name": "CVE-2021-47352",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47352"
},
{
"name": "CVE-2024-36004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36004"
},
{
"name": "CVE-2026-41691",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41691"
},
{
"name": "CVE-2024-26921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26921"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-35952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35952"
},
{
"name": "CVE-2024-26859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26859"
},
{
"name": "CVE-2026-65637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65637"
},
{
"name": "CVE-2018-8009",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8009"
},
{
"name": "CVE-2026-50163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50163"
},
{
"name": "CVE-2026-67315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67315"
},
{
"name": "CVE-2026-54516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54516"
},
{
"name": "CVE-2026-55223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55223"
},
{
"name": "CVE-2025-7962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7962"
},
{
"name": "CVE-2026-18499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18499"
},
{
"name": "CVE-2019-20444",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20444"
},
{
"name": "CVE-2026-54515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54515"
},
{
"name": "CVE-2026-5516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5516"
},
{
"name": "CVE-2023-34462",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34462"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2026-41721",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41721"
},
{
"name": "CVE-2018-1313",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1313"
},
{
"name": "CVE-2026-16221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16221"
},
{
"name": "CVE-2023-34454",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34454"
},
{
"name": "CVE-2024-35814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35814"
},
{
"name": "CVE-2022-46337",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-46337"
},
{
"name": "CVE-2026-6790",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6790"
},
{
"name": "CVE-2026-65911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65911"
},
{
"name": "CVE-2023-52764",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52764"
},
{
"name": "CVE-2026-18401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18401"
},
{
"name": "CVE-2021-35516",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35516"
},
{
"name": "CVE-2024-26698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26698"
},
{
"name": "CVE-2024-26686",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26686"
},
{
"name": "CVE-2024-35946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35946"
},
{
"name": "CVE-2023-44487",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-44487"
},
{
"name": "CVE-2024-29857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29857"
},
{
"name": "CVE-2024-35959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35959"
},
{
"name": "CVE-2024-26645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26645"
},
{
"name": "CVE-2026-66143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66143"
},
{
"name": "CVE-2024-36020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36020"
},
{
"name": "CVE-2024-42240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42240"
},
{
"name": "CVE-2026-66144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66144"
},
{
"name": "CVE-2024-35962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35962"
},
{
"name": "CVE-2026-44494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44494"
},
{
"name": "CVE-2023-26049",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26049"
},
{
"name": "CVE-2024-40972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40972"
},
{
"name": "CVE-2026-42585",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42585"
},
{
"name": "CVE-2024-50192",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50192"
},
{
"name": "CVE-2024-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26720"
},
{
"name": "CVE-2024-35855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35855"
},
{
"name": "CVE-2024-36917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36917"
},
{
"name": "CVE-2024-45018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45018"
},
{
"name": "CVE-2026-12860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12860"
},
{
"name": "CVE-2026-10571",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10571"
},
{
"name": "CVE-2024-34447",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34447"
},
{
"name": "CVE-2026-65901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65901"
},
{
"name": "CVE-2026-11541",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11541"
},
{
"name": "CVE-2014-3578",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-3578"
},
{
"name": "CVE-2026-41635",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41635"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2023-52784",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52784"
},
{
"name": "CVE-2022-40897",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40897"
},
{
"name": "CVE-2024-31880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31880"
},
{
"name": "CVE-2024-29025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29025"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2021-47461",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47461"
},
{
"name": "CVE-2026-11546",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11546"
},
{
"name": "CVE-2026-42036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42036"
},
{
"name": "CVE-2024-40959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40959"
},
{
"name": "CVE-2026-64607",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64607"
},
{
"name": "CVE-2026-59652",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59652"
},
{
"name": "CVE-2024-27042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27042"
},
{
"name": "CVE-2023-34453",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34453"
},
{
"name": "CVE-2024-26669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26669"
},
{
"name": "CVE-2024-26801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26801"
},
{
"name": "CVE-2024-27043",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27043"
},
{
"name": "CVE-2024-41761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41761"
},
{
"name": "CVE-2024-36007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36007"
},
{
"name": "CVE-2026-65903",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65903"
},
{
"name": "CVE-2021-47311",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47311"
},
{
"name": "CVE-2026-65900",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65900"
},
{
"name": "CVE-2026-66010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66010"
},
{
"name": "CVE-2026-52746",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52746"
},
{
"name": "CVE-2024-28762",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28762"
},
{
"name": "CVE-2023-3635",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3635"
},
{
"name": "CVE-2026-43827",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43827"
},
{
"name": "CVE-2026-50184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50184"
},
{
"name": "CVE-2026-47885",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47885"
},
{
"name": "CVE-2026-50169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50169"
},
{
"name": "CVE-2021-47287",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47287"
},
{
"name": "CVE-2021-47338",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47338"
},
{
"name": "CVE-2024-26940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26940"
},
{
"name": "CVE-2026-47065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47065"
},
{
"name": "CVE-2026-55831",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55831"
},
{
"name": "CVE-2024-35937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35937"
},
{
"name": "CVE-2023-5072",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5072"
},
{
"name": "CVE-2026-47841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47841"
},
{
"name": "CVE-2021-23337",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23337"
},
{
"name": "CVE-2024-36952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36952"
},
{
"name": "CVE-2024-38581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38581"
},
{
"name": "CVE-2026-41707",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41707"
},
{
"name": "CVE-2021-23369",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23369"
},
{
"name": "CVE-2026-77415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77415"
},
{
"name": "CVE-2026-42403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42403"
},
{
"name": "CVE-2024-41056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41056"
},
{
"name": "CVE-2024-38586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38586"
},
{
"name": "CVE-2024-26880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26880"
},
{
"name": "CVE-2022-31777",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31777"
},
{
"name": "CVE-2019-14893",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-14893"
},
{
"name": "CVE-2026-10534",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10534"
},
{
"name": "CVE-2024-36025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36025"
},
{
"name": "CVE-2026-59880",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59880"
},
{
"name": "CVE-2026-65432",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65432"
},
{
"name": "CVE-2026-59894",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59894"
},
{
"name": "CVE-2019-0231",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-0231"
},
{
"name": "CVE-2023-50298",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50298"
},
{
"name": "CVE-2026-15057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15057"
},
{
"name": "CVE-2026-41607",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41607"
},
{
"name": "CVE-2024-26308",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26308"
},
{
"name": "CVE-2025-1992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1992"
},
{
"name": "CVE-2026-44248",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44248"
},
{
"name": "CVE-2018-20676",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-20676"
},
{
"name": "CVE-2024-26773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26773"
},
{
"name": "CVE-2024-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53197"
},
{
"name": "CVE-2024-36017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36017"
},
{
"name": "CVE-2024-31141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31141"
},
{
"name": "CVE-2024-27434",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27434"
},
{
"name": "CVE-2025-13755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13755"
},
{
"name": "CVE-2025-62718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62718"
},
{
"name": "CVE-2025-36136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36136"
},
{
"name": "CVE-2024-35852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35852"
},
{
"name": "CVE-2024-26931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26931"
},
{
"name": "CVE-2021-47560",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47560"
},
{
"name": "CVE-2026-49458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49458"
},
{
"name": "CVE-2026-4800",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-4800"
},
{
"name": "CVE-2024-40974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40974"
},
{
"name": "CVE-2026-42584",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42584"
},
{
"name": "CVE-2024-35924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35924"
},
{
"name": "CVE-2026-4410",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-4410"
},
{
"name": "CVE-2024-36928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36928"
},
{
"name": "CVE-2024-38558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38558"
},
{
"name": "CVE-2026-44249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44249"
},
{
"name": "CVE-2023-52775",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52775"
},
{
"name": "CVE-2026-41284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41284"
},
{
"name": "CVE-2025-36008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36008"
},
{
"name": "CVE-2026-59647",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59647"
},
{
"name": "CVE-2024-42124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42124"
},
{
"name": "CVE-2024-36960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36960"
},
{
"name": "CVE-2021-35517",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35517"
},
{
"name": "CVE-2024-30172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30172"
},
{
"name": "CVE-2026-42577",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42577"
},
{
"name": "CVE-2026-58059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58059"
},
{
"name": "CVE-2026-48978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48978"
},
{
"name": "CVE-2021-47582",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47582"
},
{
"name": "CVE-2023-52781",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52781"
},
{
"name": "CVE-2021-47385",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47385"
},
{
"name": "CVE-2026-75596",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75596"
},
{
"name": "CVE-2026-8484",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8484"
},
{
"name": "CVE-2026-8763",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8763"
},
{
"name": "CVE-2026-6051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6051"
},
{
"name": "CVE-2026-44598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44598"
},
{
"name": "CVE-2023-52486",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52486"
},
{
"name": "CVE-2024-40989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40989"
},
{
"name": "CVE-2024-35845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35845"
},
{
"name": "CVE-2025-14917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14917"
},
{
"name": "CVE-2023-52619",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52619"
},
{
"name": "CVE-2023-52796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52796"
},
{
"name": "CVE-2024-36286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36286"
},
{
"name": "CVE-2026-15325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15325"
},
{
"name": "CVE-2021-47073",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47073"
},
{
"name": "CVE-2026-69247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69247"
},
{
"name": "CVE-2026-49268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49268"
},
{
"name": "CVE-2024-36124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36124"
},
{
"name": "CVE-2021-47579",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47579"
},
{
"name": "CVE-2026-33671",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33671"
},
{
"name": "CVE-2026-14976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14976"
},
{
"name": "CVE-2026-5598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5598"
},
{
"name": "CVE-2025-68470",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68470"
},
{
"name": "CVE-2024-27017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27017"
},
{
"name": "CVE-2026-65182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65182"
},
{
"name": "CVE-2018-11087",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11087"
},
{
"name": "CVE-2026-42033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42033"
},
{
"name": "CVE-2024-39502",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39502"
},
{
"name": "CVE-2026-42035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42035"
},
{
"name": "CVE-2024-26804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26804"
},
{
"name": "CVE-2026-18446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18446"
},
{
"name": "CVE-2026-44495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44495"
},
{
"name": "CVE-2024-27065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27065"
},
{
"name": "CVE-2026-41695",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41695"
},
{
"name": "CVE-2024-23454",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23454"
},
{
"name": "CVE-2024-27388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27388"
},
{
"name": "CVE-2024-50082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50082"
},
{
"name": "CVE-2026-22740",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22740"
},
{
"name": "CVE-2026-47890",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47890"
},
{
"name": "CVE-2023-52686",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52686"
},
{
"name": "CVE-2024-36005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36005"
},
{
"name": "CVE-2022-3510",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3510"
},
{
"name": "CVE-2026-59903",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59903"
},
{
"name": "CVE-2024-40977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40977"
},
{
"name": "CVE-2022-3509",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3509"
},
{
"name": "CVE-2026-14684",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14684"
},
{
"name": "CVE-2024-36905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36905"
},
{
"name": "CVE-2026-56746",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56746"
},
{
"name": "CVE-2024-35893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35893"
},
{
"name": "CVE-2024-40983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40983"
},
{
"name": "CVE-2021-37137",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37137"
},
{
"name": "CVE-2026-10842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10842"
},
{
"name": "CVE-2021-47236",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47236"
},
{
"name": "CVE-2023-51074",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51074"
},
{
"name": "CVE-2024-53122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53122"
},
{
"name": "CVE-2021-47373",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47373"
},
{
"name": "CVE-2026-9496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9496"
},
{
"name": "CVE-2026-34478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34478"
},
{
"name": "CVE-2026-42586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42586"
},
{
"name": "CVE-2026-35091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-35091"
},
{
"name": "CVE-2024-57807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57807"
},
{
"name": "CVE-2025-30474",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30474"
},
{
"name": "CVE-2024-41008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41008"
},
{
"name": "CVE-2026-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40984"
},
{
"name": "CVE-2021-41973",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41973"
},
{
"name": "CVE-2023-52683",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52683"
},
{
"name": "CVE-2023-52800",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52800"
},
{
"name": "CVE-2024-8184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8184"
},
{
"name": "CVE-2026-54428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54428"
},
{
"name": "CVE-2026-50162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50162"
},
{
"name": "CVE-2026-42043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42043"
},
{
"name": "CVE-2024-26935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26935"
},
{
"name": "CVE-2025-11143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11143"
},
{
"name": "CVE-2026-15055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15055"
},
{
"name": "CVE-2026-8646",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8646"
},
{
"name": "CVE-2026-45822",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45822"
},
{
"name": "CVE-2025-36006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36006"
},
{
"name": "CVE-2026-40477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40477"
},
{
"name": "CVE-2023-35701",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35701"
},
{
"name": "CVE-2024-26846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26846"
},
{
"name": "CVE-2026-47834",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47834"
},
{
"name": "CVE-2026-34480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34480"
},
{
"name": "CVE-2026-14682",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14682"
},
{
"name": "CVE-2024-35890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35890"
},
{
"name": "CVE-2024-41041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41041"
},
{
"name": "CVE-2018-20677",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-20677"
},
{
"name": "CVE-2024-42131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42131"
},
{
"name": "CVE-2026-84305",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84305"
},
{
"name": "CVE-2024-35944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35944"
},
{
"name": "CVE-2026-73180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73180"
},
{
"name": "CVE-2024-42079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42079"
},
{
"name": "CVE-2024-35898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35898"
},
{
"name": "CVE-2026-59869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59869"
},
{
"name": "CVE-2026-47887",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47887"
},
{
"name": "CVE-2024-27399",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27399"
},
{
"name": "CVE-2025-36186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36186"
},
{
"name": "CVE-2024-36270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36270"
},
{
"name": "CVE-2026-62243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-62243"
},
{
"name": "CVE-2023-22946",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22946"
},
{
"name": "CVE-2026-65904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65904"
},
{
"name": "CVE-2026-58061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58061"
},
{
"name": "CVE-2025-12758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12758"
},
{
"name": "CVE-2026-40175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40175"
},
{
"name": "CVE-2023-52469",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52469"
},
{
"name": "CVE-2024-26740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26740"
},
{
"name": "CVE-2026-69151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69151"
},
{
"name": "CVE-2024-35809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35809"
},
{
"name": "CVE-2024-43854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43854"
},
{
"name": "CVE-2024-50264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50264"
},
{
"name": "CVE-2024-41005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41005"
},
{
"name": "CVE-2024-44935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44935"
},
{
"name": "CVE-2026-27970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27970"
},
{
"name": "CVE-2021-47468",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47468"
},
{
"name": "CVE-2023-52877",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52877"
},
{
"name": "CVE-2026-9320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9320"
},
{
"name": "CVE-2026-49459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49459"
},
{
"name": "CVE-2023-52809",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52809"
},
{
"name": "CVE-2021-36090",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36090"
},
{
"name": "CVE-2021-27568",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-27568"
},
{
"name": "CVE-2026-6053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6053"
},
{
"name": "CVE-2024-41039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41039"
},
{
"name": "CVE-2024-23953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23953"
},
{
"name": "CVE-2026-54265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54265"
},
{
"name": "CVE-2025-68161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68161"
},
{
"name": "CVE-2023-52451",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52451"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2021-38296",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-38296"
},
{
"name": "CVE-2025-21785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21785"
},
{
"name": "CVE-2022-24823",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24823"
},
{
"name": "CVE-2024-39472",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39472"
},
{
"name": "CVE-2024-35790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35790"
},
{
"name": "CVE-2024-26649",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26649"
},
{
"name": "CVE-2026-56624",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56624"
},
{
"name": "CVE-2023-34455",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34455"
},
{
"name": "CVE-2021-41184",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41184"
},
{
"name": "CVE-2024-33621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33621"
},
{
"name": "CVE-2024-36978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36978"
},
{
"name": "CVE-2024-29131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29131"
},
{
"name": "CVE-2021-41183",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41183"
},
{
"name": "CVE-2024-42225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42225"
},
{
"name": "CVE-2024-29869",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29869"
},
{
"name": "CVE-2026-41240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41240"
},
{
"name": "CVE-2026-67317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67317"
},
{
"name": "CVE-2026-40478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40478"
},
{
"name": "CVE-2026-22748",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22748"
},
{
"name": "CVE-2025-33012",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-33012"
},
{
"name": "CVE-2024-41066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41066"
},
{
"name": "CVE-2026-34479",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34479"
},
{
"name": "CVE-2024-52804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52804"
},
{
"name": "CVE-2026-43828",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43828"
},
{
"name": "CVE-2026-42040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42040"
},
{
"name": "CVE-2023-36478",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-36478"
},
{
"name": "CVE-2021-37136",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37136"
},
{
"name": "CVE-2018-1330",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1330"
},
{
"name": "CVE-2026-47027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47027"
},
{
"name": "CVE-2024-35947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35947"
},
{
"name": "CVE-2026-47058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47058"
},
{
"name": "CVE-2024-36927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36927"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2022-48836",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48836"
},
{
"name": "CVE-2026-16441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16441"
},
{
"name": "CVE-2024-6763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6763"
},
{
"name": "CVE-2026-6052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6052"
},
{
"name": "CVE-2024-41012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41012"
},
{
"name": "CVE-2024-53088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53088"
},
{
"name": "CVE-2024-26826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26826"
},
{
"name": "CVE-2026-14981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14981"
},
{
"name": "CVE-2026-58060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58060"
},
{
"name": "CVE-2024-26583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26583"
},
{
"name": "CVE-2021-21295",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-21295"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2026-42778",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42778"
},
{
"name": "CVE-2026-14683",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14683"
},
{
"name": "CVE-2021-47527",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47527"
},
{
"name": "CVE-2024-35847",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35847"
},
{
"name": "CVE-2024-35896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35896"
},
{
"name": "CVE-2024-40912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40912"
},
{
"name": "CVE-2024-26733",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26733"
},
{
"name": "CVE-2026-14529",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14529"
},
{
"name": "CVE-2019-0204",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-0204"
},
{
"name": "CVE-2024-26851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26851"
},
{
"name": "CVE-2022-2047",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2047"
},
{
"name": "CVE-2024-39487",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39487"
},
{
"name": "CVE-2018-11793",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11793"
},
{
"name": "CVE-2026-22741",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22741"
},
{
"name": "CVE-2023-39410",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39410"
},
{
"name": "CVE-2024-35888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35888"
},
{
"name": "CVE-2024-25710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25710"
},
{
"name": "CVE-2026-12802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12802"
},
{
"name": "CVE-2024-26837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26837"
},
{
"name": "CVE-2024-7254",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7254"
},
{
"name": "CVE-2024-46695",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46695"
},
{
"name": "CVE-2022-48773",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48773"
},
{
"name": "CVE-2020-9492",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-9492"
},
{
"name": "CVE-2023-52798",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52798"
},
{
"name": "CVE-2024-31076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31076"
},
{
"name": "CVE-2026-40181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40181"
},
{
"name": "CVE-2023-52700",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52700"
},
{
"name": "CVE-2025-14923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14923"
},
{
"name": "CVE-2024-36901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36901"
},
{
"name": "CVE-2026-10649",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10649"
},
{
"name": "CVE-2026-50020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50020"
},
{
"name": "CVE-2024-40998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40998"
},
{
"name": "CVE-2024-27013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27013"
},
{
"name": "CVE-2024-29133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29133"
},
{
"name": "CVE-2024-41090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41090"
},
{
"name": "CVE-2026-54512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54512"
},
{
"name": "CVE-2026-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58063"
},
{
"name": "CVE-2026-57819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-57819"
},
{
"name": "CVE-2026-42578",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42578"
},
{
"name": "CVE-2021-47624",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47624"
},
{
"name": "CVE-2021-47495",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47495"
},
{
"name": "CVE-2024-35910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35910"
},
{
"name": "CVE-2024-26675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26675"
},
{
"name": "CVE-2022-48757",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48757"
},
{
"name": "CVE-2024-24857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24857"
},
{
"name": "CVE-2026-65899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65899"
},
{
"name": "CVE-2026-43514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43514"
},
{
"name": "CVE-2026-45773",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45773"
},
{
"name": "CVE-2026-67319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67319"
},
{
"name": "CVE-2024-49949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49949"
},
{
"name": "CVE-2026-10532",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10532"
},
{
"name": "CVE-2023-52470",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52470"
},
{
"name": "CVE-2024-26906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26906"
},
{
"name": "CVE-2022-24785",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24785"
},
{
"name": "CVE-2025-2518",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2518"
},
{
"name": "CVE-2024-36971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36971"
},
{
"name": "CVE-2024-26840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26840"
},
{
"name": "CVE-2023-46120",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46120"
},
{
"name": "CVE-2024-50099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50099"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2024-52046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52046"
},
{
"name": "CVE-2021-43797",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-43797"
},
{
"name": "CVE-2026-70907",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-70907"
},
{
"name": "CVE-2026-48589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48589"
},
{
"name": "CVE-2024-26584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26584"
},
{
"name": "CVE-2021-37404",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37404"
},
{
"name": "CVE-2021-47386",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47386"
},
{
"name": "CVE-2023-52832",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52832"
},
{
"name": "CVE-2026-42404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42404"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2022-45787",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45787"
},
{
"name": "CVE-2024-40995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40995"
},
{
"name": "CVE-2018-1199",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1199"
},
{
"name": "CVE-2024-14041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-14041"
},
{
"name": "CVE-2021-47412",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47412"
},
{
"name": "CVE-2022-48754",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48754"
},
{
"name": "CVE-2026-41586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41586"
},
{
"name": "CVE-2026-16192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16192"
},
{
"name": "CVE-2024-5569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5569"
},
{
"name": "CVE-2026-2950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2950"
},
{
"name": "CVE-2016-6811",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-6811"
},
{
"name": "CVE-2023-52662",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52662"
},
{
"name": "CVE-2026-68945",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68945"
},
{
"name": "CVE-2024-42238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42238"
},
{
"name": "CVE-2023-44981",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-44981"
},
{
"name": "CVE-2026-40895",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40895"
},
{
"name": "CVE-2026-47063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47063"
},
{
"name": "CVE-2025-1493",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1493"
},
{
"name": "CVE-2026-12816",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12816"
},
{
"name": "CVE-2021-47466",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47466"
},
{
"name": "CVE-2024-40929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40929"
},
{
"name": "CVE-2024-43830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43830"
},
{
"name": "CVE-2026-59083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59083"
},
{
"name": "CVE-2025-27553",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27553"
},
{
"name": "CVE-2024-47535",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47535"
},
{
"name": "CVE-2026-45772",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45772"
},
{
"name": "CVE-2023-52428",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52428"
},
{
"name": "CVE-2021-47289",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47289"
},
{
"name": "CVE-2023-52730",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52730"
},
{
"name": "CVE-2024-42090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42090"
},
{
"name": "CVE-2026-41606",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41606"
},
{
"name": "CVE-2024-36941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36941"
},
{
"name": "CVE-2026-59888",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59888"
},
{
"name": "CVE-2024-36896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36896"
},
{
"name": "CVE-2026-10543",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10543"
},
{
"name": "CVE-2023-6040",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6040"
},
{
"name": "CVE-2026-13149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13149"
},
{
"name": "CVE-2024-26958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26958"
},
{
"name": "CVE-2024-36902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36902"
},
{
"name": "CVE-2026-47021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47021"
},
{
"name": "CVE-2024-41042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41042"
},
{
"name": "CVE-2024-6485",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6485"
},
{
"name": "CVE-2026-47842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47842"
},
{
"name": "CVE-2025-3050",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3050"
},
{
"name": "CVE-2023-40167",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-40167"
},
{
"name": "CVE-2018-1274",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1274"
},
{
"name": "CVE-2021-47383",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47383"
},
{
"name": "CVE-2026-59898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59898"
},
{
"name": "CVE-2026-16440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16440"
},
{
"name": "CVE-2024-36924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36924"
},
{
"name": "CVE-2026-64958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64958"
},
{
"name": "CVE-2024-9823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9823"
},
{
"name": "CVE-2024-35835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35835"
},
{
"name": "CVE-2024-38570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38570"
},
{
"name": "CVE-2026-66422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66422"
},
{
"name": "CVE-2024-26939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26939"
},
{
"name": "CVE-2021-22569",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22569"
},
{
"name": "CVE-2024-26960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26960"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-36489",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36489"
},
{
"name": "CVE-2024-41762",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41762"
},
{
"name": "CVE-2024-40901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40901"
},
{
"name": "CVE-2023-6378",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6378"
},
{
"name": "CVE-2024-38575",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38575"
},
{
"name": "CVE-2021-47384",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47384"
},
{
"name": "CVE-2026-41006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41006"
},
{
"name": "CVE-2026-41711",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41711"
},
{
"name": "CVE-2021-47321",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47321"
},
{
"name": "CVE-2026-45205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45205"
},
{
"name": "CVE-2026-27830",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27830"
},
{
"name": "CVE-2023-52679",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52679"
},
{
"name": "CVE-2024-39471",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39471"
},
{
"name": "CVE-2021-47018",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47018"
},
{
"name": "CVE-2026-44487",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44487"
},
{
"name": "CVE-2026-13506",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13506"
},
{
"name": "CVE-2024-26640",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26640"
},
{
"name": "CVE-2024-35899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35899"
},
{
"name": "CVE-2023-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52881"
},
{
"name": "CVE-2026-2482",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2482"
},
{
"name": "CVE-2026-11897",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11897"
},
{
"name": "CVE-2026-35092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-35092"
},
{
"name": "CVE-2026-42038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42038"
},
{
"name": "CVE-2026-49844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49844"
},
{
"name": "CVE-2024-36919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36919"
},
{
"name": "CVE-2021-46972",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46972"
},
{
"name": "CVE-2026-18096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18096"
},
{
"name": "CVE-2024-35823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35823"
},
{
"name": "CVE-2022-34169",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-34169"
},
{
"name": "CVE-2026-2332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2332"
},
{
"name": "CVE-2026-1561",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1561"
},
{
"name": "CVE-2024-26923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26923"
},
{
"name": "CVE-2024-40954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40954"
},
{
"name": "CVE-2024-35989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35989"
},
{
"name": "CVE-2026-42039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42039"
},
{
"name": "CVE-2026-59879",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59879"
},
{
"name": "CVE-2024-35877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35877"
},
{
"name": "CVE-2026-46968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46968"
},
{
"name": "CVE-2026-40972",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40972"
},
{
"name": "CVE-2024-43892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43892"
},
{
"name": "CVE-2026-50010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50010"
},
{
"name": "CVE-2024-27020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27020"
},
{
"name": "CVE-2022-48760",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48760"
},
{
"name": "CVE-2024-42096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42096"
},
{
"name": "CVE-2023-52658",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52658"
},
{
"name": "CVE-2024-26769",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26769"
},
{
"name": "CVE-2023-36479",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-36479"
},
{
"name": "CVE-2024-50256",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50256"
},
{
"name": "CVE-2026-59296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59296"
},
{
"name": "CVE-2024-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38619"
},
{
"name": "CVE-2024-38573",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38573"
},
{
"name": "CVE-2026-33672",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33672"
},
{
"name": "CVE-2026-75838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75838"
},
{
"name": "CVE-2018-14041",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14041"
},
{
"name": "CVE-2022-48804",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48804"
},
{
"name": "CVE-2026-40983",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40983"
},
{
"name": "CVE-2024-24549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24549"
},
{
"name": "CVE-2026-42581",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42581"
},
{
"name": "CVE-2021-47408",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47408"
},
{
"name": "CVE-2024-39476",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39476"
},
{
"name": "CVE-2025-0915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0915"
},
{
"name": "CVE-2024-47668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47668"
},
{
"name": "CVE-2023-29267",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29267"
},
{
"name": "CVE-2024-35938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35938"
},
{
"name": "CVE-2026-42779",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42779"
},
{
"name": "CVE-2021-47097",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47097"
},
{
"name": "CVE-2024-42322",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42322"
},
{
"name": "CVE-2026-43513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43513"
},
{
"name": "CVE-2023-28370",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28370"
},
{
"name": "CVE-2024-42094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42094"
},
{
"name": "CVE-2026-54517",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54517"
},
{
"name": "CVE-2024-27019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27019"
},
{
"name": "CVE-2024-23848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23848"
},
{
"name": "CVE-2024-26843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26843"
},
{
"name": "CVE-2022-48747",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48747"
},
{
"name": "CVE-2026-25639",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25639"
},
{
"name": "CVE-2026-40973",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40973"
},
{
"name": "CVE-2024-41040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41040"
},
{
"name": "CVE-2020-11022",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11022"
},
{
"name": "CVE-2024-38564",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38564"
},
{
"name": "CVE-2026-15064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15064"
},
{
"name": "CVE-2026-42044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42044"
},
{
"name": "CVE-2024-36950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36950"
},
{
"name": "CVE-2024-40927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40927"
},
{
"name": "CVE-2021-31684",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-31684"
},
{
"name": "CVE-2025-25193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25193"
},
{
"name": "CVE-2023-52667",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52667"
},
{
"name": "CVE-2026-8620",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8620"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2026-65905",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65905"
},
{
"name": "CVE-2026-16439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16439"
},
{
"name": "CVE-2025-14915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14915"
},
{
"name": "CVE-2026-56745",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56745"
},
{
"name": "CVE-2018-16487",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-16487"
},
{
"name": "CVE-2026-8633",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8633"
},
{
"name": "CVE-2022-31159",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31159"
},
{
"name": "CVE-2026-11714",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11714"
},
{
"name": "CVE-2016-10735",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-10735"
},
{
"name": "CVE-2024-52903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52903"
},
{
"name": "CVE-2026-47838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47838"
},
{
"name": "CVE-2021-42550",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-42550"
},
{
"name": "CVE-2017-18214",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-18214"
},
{
"name": "CVE-2025-22870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22870"
},
{
"name": "CVE-2026-59642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59642"
},
{
"name": "CVE-2024-40941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40941"
},
{
"name": "CVE-2023-52703",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52703"
},
{
"name": "CVE-2024-40679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40679"
},
{
"name": "CVE-2026-42034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42034"
},
{
"name": "CVE-2026-47884",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47884"
},
{
"name": "CVE-2026-41417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41417"
},
{
"name": "CVE-2026-61308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-61308"
},
{
"name": "CVE-2025-23215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23215"
},
{
"name": "CVE-2026-48043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48043"
},
{
"name": "CVE-2026-9322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9322"
},
{
"name": "CVE-2024-41055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41055"
},
{
"name": "CVE-2026-87958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-87958"
},
{
"name": "CVE-2026-22745",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22745"
},
{
"name": "CVE-2024-30171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30171"
},
{
"name": "CVE-2026-42587",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42587"
},
{
"name": "CVE-2026-54513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54513"
},
{
"name": "CVE-2024-38541",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38541"
},
{
"name": "CVE-2021-47491",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47491"
},
{
"name": "CVE-2024-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40984"
},
{
"name": "CVE-2025-14914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14914"
},
{
"name": "CVE-2024-36016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36016"
},
{
"name": "CVE-2023-52922",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52922"
},
{
"name": "CVE-2026-65927",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65927"
},
{
"name": "CVE-2022-48866",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48866"
},
{
"name": "CVE-2026-9563",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9563"
},
{
"name": "CVE-2023-52623",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52623"
},
{
"name": "CVE-2026-54518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54518"
},
{
"name": "CVE-2020-9480",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-9480"
},
{
"name": "CVE-2024-36114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36114"
},
{
"name": "CVE-2026-47244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47244"
},
{
"name": "CVE-2024-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38540"
},
{
"name": "CVE-2026-13676",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13676"
},
{
"name": "CVE-2024-26759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26759"
},
{
"name": "CVE-2026-54297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54297"
},
{
"name": "CVE-2026-53434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53434"
},
{
"name": "CVE-2011-4969",
"url": "https://www.cve.org/CVERecord?id=CVE-2011-4969"
},
{
"name": "CVE-2026-60589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-60589"
},
{
"name": "CVE-2026-67312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67312"
},
{
"name": "CVE-2026-6938",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6938"
},
{
"name": "CVE-2025-8916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8916"
},
{
"name": "CVE-2024-35884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35884"
},
{
"name": "CVE-2024-41076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41076"
},
{
"name": "CVE-2026-66142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66142"
},
{
"name": "CVE-2025-8885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8885"
},
{
"name": "CVE-2023-52464",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52464"
},
{
"name": "CVE-2024-39276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39276"
},
{
"name": "CVE-2023-52813",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52813"
},
{
"name": "CVE-2026-10051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10051"
},
{
"name": "CVE-2026-53669",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53669"
},
{
"name": "CVE-2024-39506",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39506"
},
{
"name": "CVE-2026-41409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41409"
},
{
"name": "CVE-2018-1259",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1259"
},
{
"name": "CVE-2024-36940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36940"
},
{
"name": "CVE-2023-52811",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52811"
},
{
"name": "CVE-2026-6322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6322"
},
{
"name": "CVE-2024-35838",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35838"
},
{
"name": "CVE-2026-8400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8400"
},
{
"name": "CVE-2026-45623",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45623"
},
{
"name": "CVE-2026-14980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14980"
},
{
"name": "CVE-2024-40978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40978"
},
{
"name": "CVE-2023-24998",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24998"
},
{
"name": "CVE-2024-26894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26894"
},
{
"name": "CVE-2026-58062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58062"
},
{
"name": "CVE-2024-41023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41023"
},
{
"name": "CVE-2024-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53104"
},
{
"name": "CVE-2023-52615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52615"
},
{
"name": "CVE-2024-35801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35801"
},
{
"name": "CVE-2026-12143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12143"
},
{
"name": "CVE-2026-67318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67318"
},
{
"name": "CVE-2026-59893",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59893"
},
{
"name": "CVE-2024-35930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35930"
},
{
"name": "CVE-2024-26660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26660"
},
{
"name": "CVE-2024-36010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36010"
},
{
"name": "CVE-2021-21290",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-21290"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2023-52560",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52560"
},
{
"name": "CVE-2026-50151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50151"
},
{
"name": "CVE-2024-26878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26878"
},
{
"name": "CVE-2024-35900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35900"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2026-44486",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44486"
},
{
"name": "CVE-2024-38598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38598"
},
{
"name": "CVE-2026-42264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42264"
},
{
"name": "CVE-2026-12803",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12803"
},
{
"name": "CVE-2021-47069",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47069"
},
{
"name": "CVE-2026-8384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8384"
},
{
"name": "CVE-2024-35960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35960"
},
{
"name": "CVE-2023-2976",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2976"
},
{
"name": "CVE-2026-59650",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59650"
},
{
"name": "CVE-2025-1000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1000"
},
{
"name": "CVE-2023-52840",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52840"
},
{
"name": "CVE-2021-47548",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47548"
},
{
"name": "CVE-2026-44496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44496"
},
{
"name": "CVE-2018-8023",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8023"
},
{
"name": "CVE-2024-41091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41091"
},
{
"name": "CVE-2024-26853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26853"
},
{
"name": "CVE-2026-44492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44492"
},
{
"name": "CVE-2024-36920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36920"
},
{
"name": "CVE-2021-47393",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47393"
},
{
"name": "CVE-2026-54225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54225"
},
{
"name": "CVE-2026-39865",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-39865"
},
{
"name": "CVE-2026-41238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41238"
},
{
"name": "CVE-2026-47877",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47877"
},
{
"name": "CVE-2023-52522",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52522"
},
{
"name": "CVE-2026-43512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43512"
},
{
"name": "CVE-2024-41044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41044"
},
{
"name": "CVE-2024-40958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40958"
},
{
"name": "CVE-2020-26555",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26555"
},
{
"name": "CVE-2021-47497",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47497"
},
{
"name": "CVE-2024-26717",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26717"
},
{
"name": "CVE-2024-38559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38559"
},
{
"name": "CVE-2021-22570",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22570"
},
{
"name": "CVE-2026-47883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47883"
},
{
"name": "CVE-2021-35515",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35515"
},
{
"name": "CVE-2024-44990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44990"
},
{
"name": "CVE-2026-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41007"
},
{
"name": "CVE-2026-42037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42037"
},
{
"name": "CVE-2022-40898",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40898"
},
{
"name": "CVE-2024-42265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42265"
},
{
"name": "CVE-2021-46984",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46984"
},
{
"name": "CVE-2026-55760",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55760"
},
{
"name": "CVE-2024-2201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2201"
},
{
"name": "CVE-2023-26048",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26048"
},
{
"name": "CVE-2026-42498",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42498"
},
{
"name": "CVE-2026-42042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42042"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2026-9071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9071"
},
{
"name": "CVE-2017-7669",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7669"
},
{
"name": "CVE-2026-67213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67213"
},
{
"name": "CVE-2023-52777",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52777"
},
{
"name": "CVE-2024-41013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41013"
},
{
"name": "CVE-2026-55833",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55833"
},
{
"name": "CVE-2024-35789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35789"
},
{
"name": "CVE-2023-52835",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52835"
},
{
"name": "CVE-2024-45663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45663"
},
{
"name": "CVE-2026-13586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13586"
},
{
"name": "CVE-2025-33134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-33134"
},
{
"name": "CVE-2021-47101",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47101"
},
{
"name": "CVE-2024-26982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26982"
},
{
"name": "CVE-2023-26112",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26112"
},
{
"name": "CVE-2024-39499",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39499"
},
{
"name": "CVE-2026-9370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9370"
},
{
"name": "CVE-2021-47310",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47310"
},
{
"name": "CVE-2024-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38579"
},
{
"name": "CVE-2023-52626",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52626"
},
{
"name": "CVE-2024-36979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36979"
},
{
"name": "CVE-2024-36006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36006"
},
{
"name": "CVE-2026-11806",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11806"
},
{
"name": "CVE-2023-52476",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52476"
},
{
"name": "CVE-2024-42301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42301"
},
{
"name": "CVE-2026-12590",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12590"
},
{
"name": "CVE-2026-34477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34477"
},
{
"name": "CVE-2026-65902",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65902"
},
{
"name": "CVE-2023-52463",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52463"
},
{
"name": "CVE-2024-26925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26925"
},
{
"name": "CVE-2026-56819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56819"
},
{
"name": "CVE-2026-54284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54284"
},
{
"name": "CVE-2026-6321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6321"
},
{
"name": "CVE-2022-3171",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3171"
},
{
"name": "CVE-2024-26870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26870"
},
{
"name": "CVE-2024-35958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35958"
},
{
"name": "CVE-2024-36954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36954"
},
{
"name": "CVE-2021-47456",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47456"
},
{
"name": "CVE-2026-44490",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44490"
},
{
"name": "CVE-2016-7103",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-7103"
},
{
"name": "CVE-2015-9251",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-9251"
},
{
"name": "CVE-2026-59639",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59639"
},
{
"name": "CVE-2026-86093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86093"
},
{
"name": "CVE-2024-36933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36933"
},
{
"name": "CVE-2026-10852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10852"
},
{
"name": "CVE-2024-41064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41064"
},
{
"name": "CVE-2026-28338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28338"
},
{
"name": "CVE-2024-40911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40911"
},
{
"name": "CVE-2010-5312",
"url": "https://www.cve.org/CVERecord?id=CVE-2010-5312"
},
{
"name": "CVE-2026-68494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68494"
},
{
"name": "CVE-2024-26810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26810"
},
{
"name": "CVE-2023-52530",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52530"
},
{
"name": "CVE-2024-26772",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26772"
},
{
"name": "CVE-2012-6708",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-6708"
},
{
"name": "CVE-2024-36000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36000"
},
{
"name": "CVE-2024-50110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50110"
},
{
"name": "CVE-2021-47356",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47356"
},
{
"name": "CVE-2020-7656",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-7656"
},
{
"name": "CVE-2018-8013",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8013"
},
{
"name": "CVE-2021-47609",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47609"
},
{
"name": "CVE-2026-29063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-29063"
},
{
"name": "CVE-2026-60147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-60147"
},
{
"name": "CVE-2026-47889",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47889"
},
{
"name": "CVE-2024-26855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26855"
},
{
"name": "CVE-2019-16869",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-16869"
},
{
"name": "CVE-2023-52648",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52648"
},
{
"name": "CVE-2026-15280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15280"
},
{
"name": "CVE-2026-67316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67316"
},
{
"name": "CVE-2025-14813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14813"
},
{
"name": "CVE-2022-41881",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41881"
},
{
"name": "CVE-2025-13465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13465"
},
{
"name": "CVE-2023-52791",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52791"
},
{
"name": "CVE-2024-38538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38538"
},
{
"name": "CVE-2026-44488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44488"
},
{
"name": "CVE-2024-42237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42237"
},
{
"name": "CVE-2021-47353",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47353"
},
{
"name": "CVE-2023-52707",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52707"
},
{
"name": "CVE-2026-59899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59899"
},
{
"name": "CVE-2026-1718",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1718"
},
{
"name": "CVE-2026-71491",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-71491"
},
{
"name": "CVE-2026-34481",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34481"
},
{
"name": "CVE-2024-27025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27025"
},
{
"name": "CVE-2024-27011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27011"
},
{
"name": "CVE-2024-36953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36953"
},
{
"name": "CVE-2024-26924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26924"
},
{
"name": "CVE-2021-47257",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47257"
},
{
"name": "CVE-2026-38969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-38969"
},
{
"name": "CVE-2026-19880",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-19880"
},
{
"name": "CVE-2024-46858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46858"
},
{
"name": "CVE-2026-47059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47059"
},
{
"name": "CVE-2022-25168",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25168"
},
{
"name": "CVE-2026-41293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41293"
},
{
"name": "CVE-2024-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38615"
},
{
"name": "CVE-2024-44989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44989"
},
{
"name": "CVE-2024-6345",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6345"
},
{
"name": "CVE-2026-77310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77310"
},
{
"name": "CVE-2024-57699",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57699"
},
{
"name": "CVE-2023-52817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52817"
},
{
"name": "CVE-2026-65898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65898"
},
{
"name": "CVE-2020-11023",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11023"
},
{
"name": "CVE-2023-5090",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5090"
},
{
"name": "CVE-2024-27410",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27410"
},
{
"name": "CVE-2021-46909",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46909"
},
{
"name": "CVE-2019-8331",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8331"
},
{
"name": "CVE-2024-35853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35853"
},
{
"name": "CVE-2018-1000632",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000632"
},
{
"name": "CVE-2019-20445",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20445"
},
{
"name": "CVE-2024-26907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26907"
},
{
"name": "CVE-2024-40961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40961"
},
{
"name": "CVE-2026-59889",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59889"
},
{
"name": "CVE-2025-36185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36185"
},
{
"name": "CVE-2025-11226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11226"
}
],
"initial_release_date": "2026-09-11T00:00:00",
"last_revision_date": "2026-09-11T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1165",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-09-11T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Injection de code indirecte \u00e0 distance (XSS)"
},
{
"description": "Injection de requ\u00eates ill\u00e9gitimes par rebond (CSRF)"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Falsification de requ\u00eates c\u00f4t\u00e9 serveur (SSRF)"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits IBM. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits IBM",
"vendor_advisories": [
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286777",
"url": "https://www.ibm.com/support/pages/node/7286777"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286776",
"url": "https://www.ibm.com/support/pages/node/7286776"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286990",
"url": "https://www.ibm.com/support/pages/node/7286990"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286976",
"url": "https://www.ibm.com/support/pages/node/7286976"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286993",
"url": "https://www.ibm.com/support/pages/node/7286993"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286782",
"url": "https://www.ibm.com/support/pages/node/7286782"
},
{
"published_at": "2026-09-07",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286515",
"url": "https://www.ibm.com/support/pages/node/7286515"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286646",
"url": "https://www.ibm.com/support/pages/node/7286646"
},
{
"published_at": "2026-09-11",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7287136",
"url": "https://www.ibm.com/support/pages/node/7287136"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286986",
"url": "https://www.ibm.com/support/pages/node/7286986"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286982",
"url": "https://www.ibm.com/support/pages/node/7286982"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286775",
"url": "https://www.ibm.com/support/pages/node/7286775"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286987",
"url": "https://www.ibm.com/support/pages/node/7286987"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286910",
"url": "https://www.ibm.com/support/pages/node/7286910"
},
{
"published_at": "2026-09-07",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286516",
"url": "https://www.ibm.com/support/pages/node/7286516"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286909",
"url": "https://www.ibm.com/support/pages/node/7286909"
}
]
}
FKIE_CVE-2024-50099
Vulnerability from fkie_nvd - Published: 2024-11-05 18:15 - Updated: 2026-08-04 11:215.5 (Medium) - CVSS:3.1/
5.5 (Medium) - CVSS:3.1/
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.12 | |
| linux | linux_kernel | 6.12 | |
| linux | linux_kernel | 6.12 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/arm64/kernel/probes/decode-insn.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cc86f2e9876c8b5300238cec6bf0bd8c842078ee",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "3728b4eb27910ffedd173018279a970705f2e03a",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "ad4bc35a6d22e9ff9b67d0d0c38bce654232f195",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "bae792617a7e911477f67a3aff850ad4ddf51572",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "9f1e7735474e7457a4d919a517900e46868ae5f6",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "20cde998315a3d2df08e26079a3ea7501abce6db",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
},
{
"lessThan": "acc450aa07099d071b18174c22a1119c57da8227",
"status": "affected",
"version": "9842ceae9fa8deae141533d52a6ead7666962c09",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/arm64/kernel/probes/decode-insn.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.10"
},
{
"lessThan": "4.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.323",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.285",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.228",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.169",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.114",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.58",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"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": "2026-08-04T11:21:19.560",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.3,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.5,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"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": "nvd@nist.gov",
"type": "Primary"
},
{
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-50099",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:22:38.960966Z",
"version": "2.0.3"
}
}
]
},
"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"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-PJ67-HXCX-G74V
Vulnerability from github – Published: 2024-11-05 18:32 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
arm64: probes: Remove broken LDR (literal) uprobe support
The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory.
There are three key problems:
1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()).
2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN.
3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range.
In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1).
Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either:
-
Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range.
-
Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range.
... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers.
Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes.
Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.
{
"affected": [],
"aliases": [
"CVE-2024-50099"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-05T18:15:13Z",
"severity": "MODERATE"
},
"details": "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.",
"id": "GHSA-pj67-hxcx-g74v",
"modified": "2025-11-04T00:31:54Z",
"published": "2024-11-05T18:32:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50099"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20cde998315a3d2df08e26079a3ea7501abce6db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3728b4eb27910ffedd173018279a970705f2e03a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9f1e7735474e7457a4d919a517900e46868ae5f6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/acc450aa07099d071b18174c22a1119c57da8227"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad4bc35a6d22e9ff9b67d0d0c38bce654232f195"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bae792617a7e911477f67a3aff850ad4ddf51572"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc86f2e9876c8b5300238cec6bf0bd8c842078ee"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
ICSA-25-226-07
Vulnerability from csaf_cisa - Published: 2025-08-12 00:00 - Updated: 2026-02-25 07:00MSRC_CVE-2024-50099
Vulnerability from csaf_microsoft - Published: 2024-11-02 00:00 - Updated: 2026-02-21 01:55OESA-2024-2424 (CVE-2024-46685)
Vulnerability from osv_openeuler – Published: 2024-11-15 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: single: fix potential NULL dereference in pcs_get_function()
pinmux_generic_get_function() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcs_get_function().
Found by code review.(CVE-2024-46685)
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Mark XDomain as unplugged when router is removed
I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tb_disconnect_xdomain_paths() waiting for the domain lock.
However, at this point we already cleaned the paths in tb_stop() so there is really no need for tb_disconnect_xdomain_paths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router.(CVE-2024-46702)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]
[WHY & HOW] num_valid_sets needs to be checked to avoid a negative index when accessing reader_wm_sets[num_valid_sets - 1].
This fixes an OVERRUN issue reported by Coverity.(CVE-2024-46815)
In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.(CVE-2024-47679)
In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X". This confuses region_intersects(), which expects all "System RAM" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be "Operation not permitted" instead of "Bad address". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with "System RAM" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- "CXL Window 0" ------------| |-- "System RAM" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- "System RAM" --||-- "CXL Window 0a" --| Where "CXL Window 0a" is part of the original "CXL Window 0" that isn't covered by "System RAM".(CVE-2024-49878)
In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.(CVE-2024-49948)
In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---(CVE-2024-49949)
In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.(CVE-2024-49960)
In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1(CVE-2024-49967)
In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.(CVE-2024-49983)
In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add(CVE-2024-50006)
In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.(CVE-2024-50013)
In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.(CVE-2024-50014)
In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)
In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().(CVE-2024-50082)
In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 </IRQ> <TASK> asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 </TASK> Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs(CVE-2024-50095)
In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)
In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.(CVE-2024-50131)
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Don't crash in stack_top() for tasks without vDSO Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash. This can for example happen when using kunit: [<9000000000203874>] stack_top+0x58/0xa8 [<90000000002956cc>] arch_pick_mmap_layout+0x164/0x220 [<90000000003c284c>] kunit_vm_mmap_init+0x108/0x12c [<90000000003c1fbc>] __kunit_add_resource+0x38/0x8c [<90000000003c2704>] kunit_vm_mmap+0x88/0xc8 [<9000000000410b14>] usercopy_test_init+0xbc/0x25c [<90000000003c1db4>] kunit_try_run_case+0x5c/0x184 [<90000000003c3d54>] kunit_generic_run_threadfn_adapter+0x24/0x48 [<900000000022e4bc>] kthread+0xc8/0xd4 [<9000000000200ce8>] ret_from_kernel_thread+0xc/0xa4(CVE-2024-50133)
In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on.(CVE-2024-50142)
In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb(CVE-2024-50154)
In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.(CVE-2024-50184)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"perf-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-236.0.0.135.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"perf-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-236.0.0.135.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: single: fix potential NULL dereference in pcs_get_function()\r\n\r\npinmux_generic_get_function() can return NULL and the pointer \u0026apos;function\u0026apos;\nwas dereferenced without checking against NULL. Add checking of pointer\n\u0026apos;function\u0026apos; in pcs_get_function().\r\n\r\nFound by code review.(CVE-2024-46685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthunderbolt: Mark XDomain as unplugged when router is removed\r\n\r\nI noticed that when we do discrete host router NVM upgrade and it gets\nhot-removed from the PCIe side as a result of NVM firmware authentication,\nif there is another host connected with enabled paths we hang in tearing\nthem down. This is due to fact that the Thunderbolt networking driver\nalso tries to cleanup the paths and ends up blocking in\ntb_disconnect_xdomain_paths() waiting for the domain lock.\r\n\r\nHowever, at this point we already cleaned the paths in tb_stop() so\nthere is really no need for tb_disconnect_xdomain_paths() to do that\nanymore. Furthermore it already checks if the XDomain is unplugged and\nbails out early so take advantage of that and mark the XDomain as\nunplugged when we remove the parent router.(CVE-2024-46702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]\r\n\r\n[WHY \u0026amp; HOW]\nnum_valid_sets needs to be checked to avoid a negative index when\naccessing reader_wm_sets[num_valid_sets - 1].\r\n\r\nThis fixes an OVERRUN issue reported by Coverity.(CVE-2024-46815)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()\u0026amp;iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it\u0026apos;a race in vfs. Let\u0026apos;s assume there\u0026apos;s a inode (ie ino 261) with i_count 1 is called by iput(), and there\u0026apos;s a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 -\u0026gt;spin_lock(inode) -\u0026gt;dec i_count to 0 -\u0026gt;iput_final() generic_shutdown_super() -\u0026gt;__inode_add_lru() -\u0026gt;evict_inodes() // cause some reason[2] -\u0026gt;if (atomic_read(inode-\u0026gt;i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out -\u0026gt;spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls -\u0026gt;find_inode() // found the above inode 261 -\u0026gt;spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed -\u0026gt;__iget() -\u0026gt;spin_unlock(inode) // schedule back -\u0026gt;spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() -\u0026gt;spin_unlock(inode) -\u0026gt;spin_lock(inode) -\u0026gt;evict() // dec i_count to 0 -\u0026gt;iput_final() -\u0026gt;spin_unlock() -\u0026gt;evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode-\u0026gt;i_state \u0026amp; I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode-\u0026gt;i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.(CVE-2024-47679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \u0026quot;System RAM (kmem)\u0026quot; a descendant of \u0026quot;CXL Window X\u0026quot;. This confuses region_intersects(), which expects all \u0026quot;System RAM\u0026quot; resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 \u0026lt;\u0026lt; 10)) seek=$((0x490000000 \u0026gt;\u0026gt; 10)) count=1 dd: error writing \u0026apos;/dev/mem\u0026apos;: Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \u0026quot;Operation not permitted\u0026quot; instead of \u0026quot;Bad address\u0026quot;. More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn\u0026apos;t allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \u0026quot;System RAM\u0026quot; is a descendant of \u0026quot;CXL Window 0\u0026quot; instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn\u0026apos;t allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \u0026quot;System RAM\u0026quot; not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \u0026quot;CXL Window 0\u0026quot; ------------| |-- \u0026quot;System RAM\u0026quot; --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \u0026quot;System RAM\u0026quot; --||-- \u0026quot;CXL Window 0a\u0026quot; --| Where \u0026quot;CXL Window 0a\u0026quot; is part of the original \u0026quot;CXL Window 0\u0026quot; that isn\u0026apos;t covered by \u0026quot;System RAM\u0026quot;.(CVE-2024-49878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb-\u0026gt;len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious \u0026apos;GSO\u0026apos; packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)-\u0026gt;pkt_len.(CVE-2024-49948)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\u0026quot;net: be more gentle about silly gso requests coming from user\u0026quot;) virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\u0026quot;net: virtio_net_hdr_to_skb: count transport header in UFO\u0026quot;) while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb-\u0026gt;len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb-\u0026gt;len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb-\u0026gt;len - hdr_len, shinfo-\u0026gt;gso_size); Then later we set qdisc_skb_cb(skb)-\u0026gt;pkt_len to back to zero :/ qdisc_skb_cb(skb)-\u0026gt;pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 \u0026lt;49\u0026gt; 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx \u0026lt;-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---(CVE-2024-49949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.(CVE-2024-49960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1(CVE-2024-49967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the \u0026apos;ppath\u0026apos; is updated but it is the \u0026apos;path\u0026apos; that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(\u0026amp;ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth \u0026gt; path[0].p_maxdepth) kfree(path) ---\u0026gt; path First freed *orig_path = path = NULL ---\u0026gt; null ppath kfree(path) ---\u0026gt; path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.(CVE-2024-49983)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add(CVE-2024-50006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, \u0026apos;bh\u0026apos; will not be released and reassigned, which will cause a memory leak.(CVE-2024-50013)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn\u0026apos;t initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: \u0026lt;TASK\u0026gt; dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there\u0026apos;s an attempt to lock sbi-\u0026gt;s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it\u0026apos;s initialization to an earlier point in __ext4_fill_super() fixes this splat.(CVE-2024-50014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: \u0026lt;TASK\u0026gt; gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We\u0026apos;re seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 \u0026lt;f0\u0026gt; 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: \u0026lt;IRQ\u0026gt; try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data-\u0026gt;task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(\u0026amp;p-\u0026gt;pi_lock). p comes from data-\u0026gt;task, and data comes from the waitqueue entry, which is stored on the waiter\u0026apos;s stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data-\u0026gt;task. Meanwhile, the waker was passing the clobbered garbage in data-\u0026gt;task to wake_up_process(), leading to the crash. What\u0026apos;s happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data-\u0026gt;got_token = true; list_del_init(\u0026amp;curr-\u0026gt;entry); if (data.got_token) break; finish_wait(\u0026amp;rqw-\u0026gt;wait, \u0026amp;data.wq); ^- returns immediately because list_empty_careful(\u0026amp;wq_entry-\u0026gt;entry) is true ... return, go do something else ... wake_up_process(data-\u0026gt;task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().(CVE-2024-50082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: \u0026lt;IRQ\u0026gt; ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 \u0026lt;/IRQ\u0026gt; \u0026lt;TASK\u0026gt; asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 \u0026lt;/TASK\u0026gt; Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs(CVE-2024-50095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.(CVE-2024-50131)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: LoongArch: Don\u0026apos;t crash in stack_top() for tasks without vDSO Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash. This can for example happen when using kunit: [\u0026lt;9000000000203874\u0026gt;] stack_top+0x58/0xa8 [\u0026lt;90000000002956cc\u0026gt;] arch_pick_mmap_layout+0x164/0x220 [\u0026lt;90000000003c284c\u0026gt;] kunit_vm_mmap_init+0x108/0x12c [\u0026lt;90000000003c1fbc\u0026gt;] __kunit_add_resource+0x38/0x8c [\u0026lt;90000000003c2704\u0026gt;] kunit_vm_mmap+0x88/0xc8 [\u0026lt;9000000000410b14\u0026gt;] usercopy_test_init+0xbc/0x25c [\u0026lt;90000000003c1db4\u0026gt;] kunit_try_run_case+0x5c/0x184 [\u0026lt;90000000003c3d54\u0026gt;] kunit_generic_run_threadfn_adapter+0x24/0x48 [\u0026lt;900000000022e4bc\u0026gt;] kthread+0xc8/0xd4 [\u0026lt;9000000000200ce8\u0026gt;] ret_from_kernel_thread+0xc/0xa4(CVE-2024-50133)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA\u0026apos;s prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a (\u0026quot;xfrm: Validate address prefix lengths in the xfrm selector.\u0026quot;) syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn\u0026apos;t put limits on prefixlen_{s,d}. But then copy_from_user_state sets x-\u0026gt;sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that\u0026apos;s how prefixlen is going to be used later on.(CVE-2024-50142)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don\u0026apos;t use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). \u0026quot;\u0026quot;\u0026quot; We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req-\u0026gt;sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. \u0026quot;\u0026quot;\u0026quot; The commit 83fccfc3940c (\u0026quot;inet: fix potential deadlock in reqsk_queue_unlink()\u0026quot;) added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer-\u0026gt;entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req-\u0026gt;sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req-\u0026gt;sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req-\u0026gt;sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req-\u0026gt;sk Let\u0026apos;s not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb(CVE-2024-50154)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.(CVE-2024-50184)",
"id": "OESA-2024-2424",
"modified": "2026-08-06T11:07:54Z",
"published": "2024-11-15T11:07:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2424"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46702"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46815"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47679"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49948"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49949"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49983"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50013"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50133"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50142"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50184"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-46685",
"CVE-2024-46702",
"CVE-2024-46815",
"CVE-2024-47679",
"CVE-2024-49878",
"CVE-2024-49948",
"CVE-2024-49949",
"CVE-2024-49960",
"CVE-2024-49967",
"CVE-2024-49983",
"CVE-2024-50006",
"CVE-2024-50013",
"CVE-2024-50014",
"CVE-2024-50073",
"CVE-2024-50082",
"CVE-2024-50095",
"CVE-2024-50099",
"CVE-2024-50131",
"CVE-2024-50133",
"CVE-2024-50142",
"CVE-2024-50154",
"CVE-2024-50184"
]
}
OESA-2024-2425 (CVE-2024-46685)
Vulnerability from osv_openeuler – Published: 2024-11-15 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: single: fix potential NULL dereference in pcs_get_function()
pinmux_generic_get_function() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcs_get_function().
Found by code review.(CVE-2024-46685)
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Mark XDomain as unplugged when router is removed
I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tb_disconnect_xdomain_paths() waiting for the domain lock.
However, at this point we already cleaned the paths in tb_stop() so there is really no need for tb_disconnect_xdomain_paths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router.(CVE-2024-46702)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]
[WHY & HOW] num_valid_sets needs to be checked to avoid a negative index when accessing reader_wm_sets[num_valid_sets - 1].
This fixes an OVERRUN issue reported by Coverity.(CVE-2024-46815)
In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.(CVE-2024-47679)
In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X". This confuses region_intersects(), which expects all "System RAM" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be "Operation not permitted" instead of "Bad address". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with "System RAM" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- "CXL Window 0" ------------| |-- "System RAM" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- "System RAM" --||-- "CXL Window 0a" --| Where "CXL Window 0a" is part of the original "CXL Window 0" that isn't covered by "System RAM".(CVE-2024-49878)
In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.(CVE-2024-49948)
In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---(CVE-2024-49949)
In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.(CVE-2024-49960)
In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1(CVE-2024-49967)
In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.(CVE-2024-49983)
In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add(CVE-2024-50006)
In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.(CVE-2024-50013)
In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.(CVE-2024-50014)
In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)
In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().(CVE-2024-50082)
In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 </IRQ> <TASK> asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 </TASK> Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs(CVE-2024-50095)
In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)
In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.(CVE-2024-50131)
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Don't crash in stack_top() for tasks without vDSO Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash. This can for example happen when using kunit: [<9000000000203874>] stack_top+0x58/0xa8 [<90000000002956cc>] arch_pick_mmap_layout+0x164/0x220 [<90000000003c284c>] kunit_vm_mmap_init+0x108/0x12c [<90000000003c1fbc>] __kunit_add_resource+0x38/0x8c [<90000000003c2704>] kunit_vm_mmap+0x88/0xc8 [<9000000000410b14>] usercopy_test_init+0xbc/0x25c [<90000000003c1db4>] kunit_try_run_case+0x5c/0x184 [<90000000003c3d54>] kunit_generic_run_threadfn_adapter+0x24/0x48 [<900000000022e4bc>] kthread+0xc8/0xd4 [<9000000000200ce8>] ret_from_kernel_thread+0xc/0xa4(CVE-2024-50133)
In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on.(CVE-2024-50142)
In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb(CVE-2024-50154)
In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.(CVE-2024-50184)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm",
"perf-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-236.0.0.138.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-236.0.0.138.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm",
"perf-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-236.0.0.138.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-236.0.0.138.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: single: fix potential NULL dereference in pcs_get_function()\r\n\r\npinmux_generic_get_function() can return NULL and the pointer \u0026apos;function\u0026apos;\nwas dereferenced without checking against NULL. Add checking of pointer\n\u0026apos;function\u0026apos; in pcs_get_function().\r\n\r\nFound by code review.(CVE-2024-46685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthunderbolt: Mark XDomain as unplugged when router is removed\r\n\r\nI noticed that when we do discrete host router NVM upgrade and it gets\nhot-removed from the PCIe side as a result of NVM firmware authentication,\nif there is another host connected with enabled paths we hang in tearing\nthem down. This is due to fact that the Thunderbolt networking driver\nalso tries to cleanup the paths and ends up blocking in\ntb_disconnect_xdomain_paths() waiting for the domain lock.\r\n\r\nHowever, at this point we already cleaned the paths in tb_stop() so\nthere is really no need for tb_disconnect_xdomain_paths() to do that\nanymore. Furthermore it already checks if the XDomain is unplugged and\nbails out early so take advantage of that and mark the XDomain as\nunplugged when we remove the parent router.(CVE-2024-46702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]\r\n\r\n[WHY \u0026amp; HOW]\nnum_valid_sets needs to be checked to avoid a negative index when\naccessing reader_wm_sets[num_valid_sets - 1].\r\n\r\nThis fixes an OVERRUN issue reported by Coverity.(CVE-2024-46815)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()\u0026amp;iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it\u0026apos;a race in vfs. Let\u0026apos;s assume there\u0026apos;s a inode (ie ino 261) with i_count 1 is called by iput(), and there\u0026apos;s a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 -\u0026gt;spin_lock(inode) -\u0026gt;dec i_count to 0 -\u0026gt;iput_final() generic_shutdown_super() -\u0026gt;__inode_add_lru() -\u0026gt;evict_inodes() // cause some reason[2] -\u0026gt;if (atomic_read(inode-\u0026gt;i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out -\u0026gt;spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls -\u0026gt;find_inode() // found the above inode 261 -\u0026gt;spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed -\u0026gt;__iget() -\u0026gt;spin_unlock(inode) // schedule back -\u0026gt;spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() -\u0026gt;spin_unlock(inode) -\u0026gt;spin_lock(inode) -\u0026gt;evict() // dec i_count to 0 -\u0026gt;iput_final() -\u0026gt;spin_unlock() -\u0026gt;evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode-\u0026gt;i_state \u0026amp; I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode-\u0026gt;i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.(CVE-2024-47679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \u0026quot;System RAM (kmem)\u0026quot; a descendant of \u0026quot;CXL Window X\u0026quot;. This confuses region_intersects(), which expects all \u0026quot;System RAM\u0026quot; resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 \u0026lt;\u0026lt; 10)) seek=$((0x490000000 \u0026gt;\u0026gt; 10)) count=1 dd: error writing \u0026apos;/dev/mem\u0026apos;: Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \u0026quot;Operation not permitted\u0026quot; instead of \u0026quot;Bad address\u0026quot;. More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn\u0026apos;t allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \u0026quot;System RAM\u0026quot; is a descendant of \u0026quot;CXL Window 0\u0026quot; instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn\u0026apos;t allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \u0026quot;System RAM\u0026quot; not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \u0026quot;CXL Window 0\u0026quot; ------------| |-- \u0026quot;System RAM\u0026quot; --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \u0026quot;System RAM\u0026quot; --||-- \u0026quot;CXL Window 0a\u0026quot; --| Where \u0026quot;CXL Window 0a\u0026quot; is part of the original \u0026quot;CXL Window 0\u0026quot; that isn\u0026apos;t covered by \u0026quot;System RAM\u0026quot;.(CVE-2024-49878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb-\u0026gt;len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious \u0026apos;GSO\u0026apos; packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)-\u0026gt;pkt_len.(CVE-2024-49948)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\u0026quot;net: be more gentle about silly gso requests coming from user\u0026quot;) virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\u0026quot;net: virtio_net_hdr_to_skb: count transport header in UFO\u0026quot;) while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb-\u0026gt;len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb-\u0026gt;len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb-\u0026gt;len - hdr_len, shinfo-\u0026gt;gso_size); Then later we set qdisc_skb_cb(skb)-\u0026gt;pkt_len to back to zero :/ qdisc_skb_cb(skb)-\u0026gt;pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 \u0026lt;49\u0026gt; 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx \u0026lt;-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---(CVE-2024-49949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.(CVE-2024-49960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1(CVE-2024-49967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the \u0026apos;ppath\u0026apos; is updated but it is the \u0026apos;path\u0026apos; that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(\u0026amp;ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth \u0026gt; path[0].p_maxdepth) kfree(path) ---\u0026gt; path First freed *orig_path = path = NULL ---\u0026gt; null ppath kfree(path) ---\u0026gt; path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.(CVE-2024-49983)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add(CVE-2024-50006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, \u0026apos;bh\u0026apos; will not be released and reassigned, which will cause a memory leak.(CVE-2024-50013)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn\u0026apos;t initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: \u0026lt;TASK\u0026gt; dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there\u0026apos;s an attempt to lock sbi-\u0026gt;s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it\u0026apos;s initialization to an earlier point in __ext4_fill_super() fixes this splat.(CVE-2024-50014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: \u0026lt;TASK\u0026gt; gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We\u0026apos;re seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 \u0026lt;f0\u0026gt; 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: \u0026lt;IRQ\u0026gt; try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data-\u0026gt;task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(\u0026amp;p-\u0026gt;pi_lock). p comes from data-\u0026gt;task, and data comes from the waitqueue entry, which is stored on the waiter\u0026apos;s stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data-\u0026gt;task. Meanwhile, the waker was passing the clobbered garbage in data-\u0026gt;task to wake_up_process(), leading to the crash. What\u0026apos;s happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data-\u0026gt;got_token = true; list_del_init(\u0026amp;curr-\u0026gt;entry); if (data.got_token) break; finish_wait(\u0026amp;rqw-\u0026gt;wait, \u0026amp;data.wq); ^- returns immediately because list_empty_careful(\u0026amp;wq_entry-\u0026gt;entry) is true ... return, go do something else ... wake_up_process(data-\u0026gt;task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().(CVE-2024-50082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: \u0026lt;IRQ\u0026gt; ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 \u0026lt;/IRQ\u0026gt; \u0026lt;TASK\u0026gt; asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 \u0026lt;/TASK\u0026gt; Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs(CVE-2024-50095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.(CVE-2024-50131)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: LoongArch: Don\u0026apos;t crash in stack_top() for tasks without vDSO Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash. This can for example happen when using kunit: [\u0026lt;9000000000203874\u0026gt;] stack_top+0x58/0xa8 [\u0026lt;90000000002956cc\u0026gt;] arch_pick_mmap_layout+0x164/0x220 [\u0026lt;90000000003c284c\u0026gt;] kunit_vm_mmap_init+0x108/0x12c [\u0026lt;90000000003c1fbc\u0026gt;] __kunit_add_resource+0x38/0x8c [\u0026lt;90000000003c2704\u0026gt;] kunit_vm_mmap+0x88/0xc8 [\u0026lt;9000000000410b14\u0026gt;] usercopy_test_init+0xbc/0x25c [\u0026lt;90000000003c1db4\u0026gt;] kunit_try_run_case+0x5c/0x184 [\u0026lt;90000000003c3d54\u0026gt;] kunit_generic_run_threadfn_adapter+0x24/0x48 [\u0026lt;900000000022e4bc\u0026gt;] kthread+0xc8/0xd4 [\u0026lt;9000000000200ce8\u0026gt;] ret_from_kernel_thread+0xc/0xa4(CVE-2024-50133)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA\u0026apos;s prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a (\u0026quot;xfrm: Validate address prefix lengths in the xfrm selector.\u0026quot;) syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn\u0026apos;t put limits on prefixlen_{s,d}. But then copy_from_user_state sets x-\u0026gt;sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that\u0026apos;s how prefixlen is going to be used later on.(CVE-2024-50142)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don\u0026apos;t use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). \u0026quot;\u0026quot;\u0026quot; We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req-\u0026gt;sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. \u0026quot;\u0026quot;\u0026quot; The commit 83fccfc3940c (\u0026quot;inet: fix potential deadlock in reqsk_queue_unlink()\u0026quot;) added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer-\u0026gt;entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req-\u0026gt;sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req-\u0026gt;sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req-\u0026gt;sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req-\u0026gt;sk Let\u0026apos;s not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb(CVE-2024-50154)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.(CVE-2024-50184)",
"id": "OESA-2024-2425",
"modified": "2026-08-06T11:07:54Z",
"published": "2024-11-15T11:07:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2425"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46702"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46815"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47679"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49948"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49949"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49983"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50013"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50133"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50142"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50184"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-46685",
"CVE-2024-46702",
"CVE-2024-46815",
"CVE-2024-47679",
"CVE-2024-49878",
"CVE-2024-49948",
"CVE-2024-49949",
"CVE-2024-49960",
"CVE-2024-49967",
"CVE-2024-49983",
"CVE-2024-50006",
"CVE-2024-50013",
"CVE-2024-50014",
"CVE-2024-50073",
"CVE-2024-50082",
"CVE-2024-50095",
"CVE-2024-50099",
"CVE-2024-50131",
"CVE-2024-50133",
"CVE-2024-50142",
"CVE-2024-50154",
"CVE-2024-50184"
]
}
OESA-2024-2445 (CVE-2022-48878)
Vulnerability from osv_openeuler – Published: 2024-11-22 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_qca: Fix driver shutdown on closed serdev
The driver shutdown callback (which sends EDL_SOC_RESET to the device over serdev) should not be invoked when HCI device is not open (e.g. if hci_dev_open_sync() failed), because the serdev and its TTY are not open either. Also skip this step if device is powered off (qca_power_shutdown()).
The shutdown callback causes use-after-free during system reboot with Qualcomm Atheros Bluetooth:
Unable to handle kernel paging request at virtual address 0072662f67726fd7 ... CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G W 6.1.0-rt5-00325-g8a5f56bcfcca #8 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: tty_driver_flush_buffer+0x4/0x30 serdev_device_write_flush+0x24/0x34 qca_serdev_shutdown+0x80/0x130 [hci_uart] device_shutdown+0x15c/0x260 kernel_restart+0x48/0xac
KASAN report:
BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50 Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1
CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xdc/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x68/0x84 print_report+0x188/0x488 kasan_report+0xa4/0xf0 __asan_load8+0x80/0xac tty_driver_flush_buffer+0x1c/0x50 ttyport_write_flush+0x34/0x44 serdev_device_write_flush+0x48/0x60 qca_serdev_shutdown+0x124/0x274 device_shutdown+0x1e8/0x350 kernel_restart+0x48/0xb0 __do_sys_reboot+0x244/0x2d0 __arm64_sys_reboot+0x54/0x70 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x44/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xbc/0x140 el0t_64_sync+0x190/0x194(CVE-2022-48878)
In the Linux kernel, the following vulnerability has been resolved: rtc: cmos: Fix event handler registration ordering issue Because acpi_install_fixed_event_handler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmos_wake_setup(), which passes rtc_handler() to acpi_install_fixed_event_handler(), before cmos_do_probe(), because rtc_handler() uses dev_get_drvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmos_do_probe(). This leads to a NULL pointer dereference in rtc_handler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmos_wake_setup() is always called after a successful cmos_do_probe() call. While at it, change cmos_pnp_probe() to call cmos_do_probe() after the initial if () statement used for computing the IRQ argument to be passed to cmos_do_probe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that commit.(CVE-2022-48953)
In the Linux kernel, the following vulnerability has been resolved: e100: Fix possible use after free in e100_xmit_prepare In e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, so e100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will resend the skb. But the skb is already freed, which will cause UAF bug when the upper layer resends the skb. Remove the harmful free.(CVE-2022-49026)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA
This dma_alloc_coherent() is undone neither in the remove function, nor in the error handling path of fsl_qdma_probe().
Switch to the managed version to fix both issues.(CVE-2024-35833)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: honor table dormant flag from netdev release event path
Check for table dormant flag otherwise netdev release event path tries to unregister an already unregistered hook.
[524854.857999] ------------[ cut here ]------------ [524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260 [...] [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365 [524854.858869] Workqueue: netns cleanup_net [524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260 [524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41 [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246 [524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438 [524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34 [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005 [524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00 [524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0 [524854.859000] Call Trace: [524854.859006] <TASK> [524854.859013] ? __warn+0x9f/0x1a0 [524854.859027] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859044] ? report_bug+0x1b1/0x1e0 [524854.859060] ? handle_bug+0x3c/0x70 [524854.859071] ? exc_invalid_op+0x17/0x40 [524854.859083] ? asm_exc_invalid_op+0x1a/0x20 [524854.859100] ? __nf_unregister_net_hook+0x6a/0x260 [524854.859116] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables] [524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859461] ? packet_notifier+0xb3/0x360 [524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40 [524854.859489] ? dcbnl_netdevice_event+0x35/0x140 [524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859661] notifier_call_chain+0x7d/0x140 [524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0(CVE-2024-36005)
In the Linux kernel, the following vulnerability has been resolved:
firewire: ohci: mask bus reset interrupts between ISR and bottom half
In the FireWire OHCI interrupt handler, if a bus reset interrupt has occurred, mask bus reset interrupts until bus_reset_work has serviced and cleared the interrupt.
Normally, we always leave bus reset interrupts masked. We infer the bus reset from the self-ID interrupt that happens shortly thereafter. A scenario where we unmask bus reset interrupts was introduced in 2008 in a007bb857e0b26f5d8b73c2ff90782d9c0972620: If OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we will unmask bus reset interrupts so we can log them.
irq_handler logs the bus reset interrupt. However, we can't clear the bus reset event flag in irq_handler, because we won't service the event until later. irq_handler exits with the event flag still set. If the corresponding interrupt is still unmasked, the first bus reset will usually freeze the system due to irq_handler being called again each time it exits. This freeze can be reproduced by loading firewire_ohci with "modprobe firewire_ohci debug=-1" (to enable all debugging output). Apparently there are also some cases where bus_reset_work will get called soon enough to clear the event, and operation will continue normally.
This freeze was first reported a few months after a007bb85 was committed, but until now it was never fixed. The debug level could safely be set to -1 through sysfs after the module was loaded, but this would be ineffectual in logging bus reset interrupts since they were only unmasked during initialization.
irq_handler will now leave the event flag set but mask bus reset interrupts, so irq_handler won't be called again and there will be no freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will unmask the interrupt after servicing the event, so future interrupts will be caught as desired.
As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be enabled through sysfs in addition to during initial module loading. However, when enabled through sysfs, logging of bus reset interrupts will be effective only starting with the second bus reset, after bus_reset_work has executed.(CVE-2024-36950)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix NULL dereference at band check in starting tx ba session
In MLD connection, link_data/link_conf are dynamically allocated. They don't point to vif->bss_conf. So, there will be no chanreq assigned to vif->bss_conf and then the chan will be NULL. Tweak the code to check ht_supported/vht_supported/has_he/has_eht on sta deflink.
Crash log (with rtw89 version under MLO development): [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9890.526102] #PF: supervisor read access in kernel mode [ 9890.526105] #PF: error_code(0x0000) - not-present page [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1 [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 [ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core] [ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 All code ======== 0: f7 e8 imul %eax 2: d5 (bad) 3: 93 xchg %eax,%ebx 4: 3e ea ds (bad) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c: 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz
Code starting with the faulting instruction
0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 test %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873 [ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70 [ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000 [ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000 [ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Call Trace: [ 9890.526324] <TASK> [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713) [ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator ---truncated---(CVE-2024-43911)
In the Linux kernel, the following vulnerability has been resolved:
staging: iio: frequency: ad9834: Validate frequency parameter value
In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value.
Modify parameters checking.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47663)
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm80xx: Set phy->enable_completion only when we wait for it
pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash.(CVE-2024-47666)
In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf__check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the mtu_len on error path which can be lifted later again.(CVE-2024-47728)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the dcn20_program_pipe function. The issue could occur when pipe_ctx->plane_state is null. The fix adds a check to ensure pipe_ctx->plane_state is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)(CVE-2024-49914)
In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.(CVE-2024-49945)
In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs(CVE-2024-49963)
In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.(CVE-2024-49982)
In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.(CVE-2024-50115)
In the Linux kernel, the following vulnerability has been resolved: bpf: Use raw_spinlock_t in ringbuf The function __bpf_ringbuf_reserve is invoked from a tracepoint, which disables preemption. Using spinlock_t in this context can lead to a "sleep in atomic" warning in the RT variant. This issue is illustrated in the example below: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [<ffffd33a5c88ea44>] migrate_enable+0xc0/0x39c CPU: 7 PID: 556208 Comm: test_progs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Switch the spinlock to raw_spinlock_t to avoid this error.(CVE-2024-50138)
In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.(CVE-2024-50184)
In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.(CVE-2024-50195)
In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.(CVE-2024-50198)
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data(CVE-2024-50237)
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release(CVE-2024-50242)
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().(CVE-2024-50245)
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check(CVE-2024-50246)
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.(CVE-2024-50247)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.102.0.183.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.102.0.183.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.102.0.183.oe2203sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-136.102.0.183.oe2203sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: hci_qca: Fix driver shutdown on closed serdev\r\n\r\nThe driver shutdown callback (which sends EDL_SOC_RESET to the device\nover serdev) should not be invoked when HCI device is not open (e.g. if\nhci_dev_open_sync() failed), because the serdev and its TTY are not open\neither. Also skip this step if device is powered off\n(qca_power_shutdown()).\r\n\r\nThe shutdown callback causes use-after-free during system reboot with\nQualcomm Atheros Bluetooth:\r\n\r\n Unable to handle kernel paging request at virtual address\n 0072662f67726fd7\n ...\n CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G W\n 6.1.0-rt5-00325-g8a5f56bcfcca #8\n Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)\n Call trace:\n tty_driver_flush_buffer+0x4/0x30\n serdev_device_write_flush+0x24/0x34\n qca_serdev_shutdown+0x80/0x130 [hci_uart]\n device_shutdown+0x15c/0x260\n kernel_restart+0x48/0xac\r\n\r\nKASAN report:\r\n\r\n BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50\n Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1\r\n\r\n CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted\n 6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28\n Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)\n Call trace:\n dump_backtrace.part.0+0xdc/0xf0\n show_stack+0x18/0x30\n dump_stack_lvl+0x68/0x84\n print_report+0x188/0x488\n kasan_report+0xa4/0xf0\n __asan_load8+0x80/0xac\n tty_driver_flush_buffer+0x1c/0x50\n ttyport_write_flush+0x34/0x44\n serdev_device_write_flush+0x48/0x60\n qca_serdev_shutdown+0x124/0x274\n device_shutdown+0x1e8/0x350\n kernel_restart+0x48/0xb0\n __do_sys_reboot+0x244/0x2d0\n __arm64_sys_reboot+0x54/0x70\n invoke_syscall+0x60/0x190\n el0_svc_common.constprop.0+0x7c/0x160\n do_el0_svc+0x44/0xf0\n el0_svc+0x2c/0x6c\n el0t_64_sync_handler+0xbc/0x140\n el0t_64_sync+0x190/0x194(CVE-2022-48878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: rtc: cmos: Fix event handler registration ordering issue Because acpi_install_fixed_event_handler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmos_wake_setup(), which passes rtc_handler() to acpi_install_fixed_event_handler(), before cmos_do_probe(), because rtc_handler() uses dev_get_drvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmos_do_probe(). This leads to a NULL pointer dereference in rtc_handler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmos_wake_setup() is always called after a successful cmos_do_probe() call. While at it, change cmos_pnp_probe() to call cmos_do_probe() after the initial if () statement used for computing the IRQ argument to be passed to cmos_do_probe() which is cleaner than calling it in each branch of that if () (local variable \u0026quot;irq\u0026quot; can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 (\u0026quot;rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0\u0026quot;) caused this issue to affect a larger number of systems, because previously it only affected systems with ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that commit.(CVE-2022-48953)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: e100: Fix possible use after free in e100_xmit_prepare In e100_xmit_prepare(), if we can\u0026apos;t map the skb, then return -ENOMEM, so e100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will resend the skb. But the skb is already freed, which will cause UAF bug when the upper layer resends the skb. Remove the harmful free.(CVE-2022-49026)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA\r\n\r\nThis dma_alloc_coherent() is undone neither in the remove function, nor in\nthe error handling path of fsl_qdma_probe().\r\n\r\nSwitch to the managed version to fix both issues.(CVE-2024-35833)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: honor table dormant flag from netdev release event path\r\n\r\nCheck for table dormant flag otherwise netdev release event path tries\nto unregister an already unregistered hook.\r\n\r\n[524854.857999] ------------[ cut here ]------------\n[524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260\n[...]\n[524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365\n[524854.858869] Workqueue: netns cleanup_net\n[524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260\n[524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff \u0026lt;0f\u0026gt; 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41\n[524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246\n[524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a\n[524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438\n[524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34\n[524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005\n[524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00\n[524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000\n[524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0\n[524854.859000] Call Trace:\n[524854.859006] \u0026lt;TASK\u0026gt;\n[524854.859013] ? __warn+0x9f/0x1a0\n[524854.859027] ? __nf_unregister_net_hook+0x21a/0x260\n[524854.859044] ? report_bug+0x1b1/0x1e0\n[524854.859060] ? handle_bug+0x3c/0x70\n[524854.859071] ? exc_invalid_op+0x17/0x40\n[524854.859083] ? asm_exc_invalid_op+0x1a/0x20\n[524854.859100] ? __nf_unregister_net_hook+0x6a/0x260\n[524854.859116] ? __nf_unregister_net_hook+0x21a/0x260\n[524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables]\n[524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]\n[524854.859461] ? packet_notifier+0xb3/0x360\n[524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40\n[524854.859489] ? dcbnl_netdevice_event+0x35/0x140\n[524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]\n[524854.859661] notifier_call_chain+0x7d/0x140\n[524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0(CVE-2024-36005)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirewire: ohci: mask bus reset interrupts between ISR and bottom half\r\n\r\nIn the FireWire OHCI interrupt handler, if a bus reset interrupt has\noccurred, mask bus reset interrupts until bus_reset_work has serviced and\ncleared the interrupt.\r\n\r\nNormally, we always leave bus reset interrupts masked. We infer the bus\nreset from the self-ID interrupt that happens shortly thereafter. A\nscenario where we unmask bus reset interrupts was introduced in 2008 in\na007bb857e0b26f5d8b73c2ff90782d9c0972620: If\nOHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we\nwill unmask bus reset interrupts so we can log them.\r\n\r\nirq_handler logs the bus reset interrupt. However, we can\u0026apos;t clear the bus\nreset event flag in irq_handler, because we won\u0026apos;t service the event until\nlater. irq_handler exits with the event flag still set. If the\ncorresponding interrupt is still unmasked, the first bus reset will\nusually freeze the system due to irq_handler being called again each\ntime it exits. This freeze can be reproduced by loading firewire_ohci\nwith \u0026quot;modprobe firewire_ohci debug=-1\u0026quot; (to enable all debugging output).\nApparently there are also some cases where bus_reset_work will get called\nsoon enough to clear the event, and operation will continue normally.\r\n\r\nThis freeze was first reported a few months after a007bb85 was committed,\nbut until now it was never fixed. The debug level could safely be set\nto -1 through sysfs after the module was loaded, but this would be\nineffectual in logging bus reset interrupts since they were only\nunmasked during initialization.\r\n\r\nirq_handler will now leave the event flag set but mask bus reset\ninterrupts, so irq_handler won\u0026apos;t be called again and there will be no\nfreeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will\nunmask the interrupt after servicing the event, so future interrupts\nwill be caught as desired.\r\n\r\nAs a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be\nenabled through sysfs in addition to during initial module loading.\nHowever, when enabled through sysfs, logging of bus reset interrupts will\nbe effective only starting with the second bus reset, after\nbus_reset_work has executed.(CVE-2024-36950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: fix NULL dereference at band check in starting tx ba session\r\n\r\nIn MLD connection, link_data/link_conf are dynamically allocated. They\ndon\u0026apos;t point to vif-\u0026gt;bss_conf. So, there will be no chanreq assigned to\nvif-\u0026gt;bss_conf and then the chan will be NULL. Tweak the code to check\nht_supported/vht_supported/has_he/has_eht on sta deflink.\r\n\r\nCrash log (with rtw89 version under MLO development):\n[ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 9890.526102] #PF: supervisor read access in kernel mode\n[ 9890.526105] #PF: error_code(0x0000) - not-present page\n[ 9890.526109] PGD 0 P4D 0\n[ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI\n[ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1\n[ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018\n[ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core]\n[ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211\n[ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 \u0026lt;83\u0026gt; 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3\nAll code\n========\n 0:\tf7 e8 \timul %eax\n 2:\td5 \t(bad)\n 3:\t93 \txchg %eax,%ebx\n 4:\t3e ea \tds (bad)\n 6:\t48 83 c4 28 \tadd $0x28,%rsp\n a:\t89 d8 \tmov %ebx,%eax\n c:\t5b \tpop %rbx\n d:\t41 5c \tpop %r12\n f:\t41 5d \tpop %r13\n 11:\t41 5e \tpop %r14\n 13:\t41 5f \tpop %r15\n 15:\t5d \tpop %rbp\n 16:\tc3 \tretq\n 17:\tcc \tint3\n 18:\tcc \tint3\n 19:\tcc \tint3\n 1a:\tcc \tint3\n 1b:\t49 8b 84 24 e0 f1 ff \tmov -0xe20(%r12),%rax\n 22:\tff\n 23:\t48 8b 80 90 1b 00 00 \tmov 0x1b90(%rax),%rax\n 2a:*\t83 38 03 \tcmpl $0x3,(%rax)\t\t\u0026lt;-- trapping instruction\n 2d:\t0f 84 37 fe ff ff \tje 0xfffffffffffffe6a\n 33:\tbb ea ff ff ff \tmov $0xffffffea,%ebx\n 38:\teb cc \tjmp 0x6\n 3a:\t49 \trex.WB\n 3b:\t8b \t.byte 0x8b\n 3c:\t84 24 10 \ttest %ah,(%rax,%rdx,1)\n 3f:\tf3 \trepz\r\n\r\nCode starting with the faulting instruction\n===========================================\n 0:\t83 38 03 \tcmpl $0x3,(%rax)\n 3:\t0f 84 37 fe ff ff \tje 0xfffffffffffffe40\n 9:\tbb ea ff ff ff \tmov $0xffffffea,%ebx\n e:\teb cc \tjmp 0xffffffffffffffdc\n 10:\t49 \trex.WB\n 11:\t8b \t.byte 0x8b\n 12:\t84 24 10 \ttest %ah,(%rax,%rdx,1)\n 15:\tf3 \trepz\n[ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246\n[ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8\n[ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685\n[ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873\n[ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70\n[ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000\n[ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000\n[ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0\n[ 9890.526321] Call Trace:\n[ 9890.526324] \u0026lt;TASK\u0026gt;\n[ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479)\n[ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)\n[ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713)\n[ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator\n---truncated---(CVE-2024-43911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstaging: iio: frequency: ad9834: Validate frequency parameter value\r\n\r\nIn ad9834_write_frequency() clk_get_rate() can return 0. In such case\nad9834_calc_freqreg() call will lead to division by zero. Checking\n\u0026apos;if (fout \u0026gt; (clk_freq / 2))\u0026apos; doesn\u0026apos;t protect in case of \u0026apos;fout\u0026apos; is 0.\nad9834_write_frequency() is called from ad9834_write(), where fout is\ntaken from text buffer, which can contain any value.\r\n\r\nModify parameters checking.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47663)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: pm80xx: Set phy-\u0026gt;enable_completion only when we wait for it\r\n\r\npm8001_phy_control() populates the enable_completion pointer with a stack\naddress, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and\nreturns. The problem arises when a phy control response comes late. After\n300 ms the pm8001_phy_control() function returns and the passed\nenable_completion stack address is no longer valid. Late phy control\nresponse invokes complete() on a dangling enable_completion pointer which\nleads to a kernel crash.(CVE-2024-47666)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we\u0026apos;re readding the issue we\u0026apos;re trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.(CVE-2024-47728)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx-\u0026gt;plane_state` is null. The fix adds a check to ensure `pipe_ctx-\u0026gt;plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed \u0026apos;pipe_ctx-\u0026gt;plane_state\u0026apos; could be null (see line 1877)(CVE-2024-49914)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.(CVE-2024-49945)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn\u0026apos;t consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs(CVE-2024-49963)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\u0026quot;aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\u0026quot;) makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb-\u0026gt;dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb-\u0026gt;dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.(CVE-2024-49982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn\u0026apos;t enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn\u0026apos;t using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM\u0026apos;s much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it\u0026apos;s only the nSVM flow that is broken.(CVE-2024-50115)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: bpf: Use raw_spinlock_t in ringbuf The function __bpf_ringbuf_reserve is invoked from a tracepoint, which disables preemption. Using spinlock_t in this context can lead to a \u0026quot;sleep in atomic\u0026quot; warning in the RT variant. This issue is illustrated in the example below: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [\u0026lt;ffffd33a5c88ea44\u0026gt;] migrate_enable+0xc0/0x39c CPU: 7 PID: 556208 Comm: test_progs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Switch the spinlock to raw_spinlock_t to avoid this error.(CVE-2024-50138)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.(CVE-2024-50184)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct\u0026apos;s tv_sec and tv_nsec range before calling ptp-\u0026gt;info-\u0026gt;settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp-\u0026gt;tv_sec and tp-\u0026gt;tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.(CVE-2024-50195)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.(CVE-2024-50198)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data(CVE-2024-50237)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release(CVE-2024-50242)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().(CVE-2024-50245)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check(CVE-2024-50246)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.(CVE-2024-50247)",
"id": "OESA-2024-2445",
"modified": "2026-08-06T11:07:55Z",
"published": "2024-11-22T11:07:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2445"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48953"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49026"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35833"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36950"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47663"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47666"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49963"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50115"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50184"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50195"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50198"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50237"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50242"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50245"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50246"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50247"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-48878",
"CVE-2022-48953",
"CVE-2022-49026",
"CVE-2024-35833",
"CVE-2024-36005",
"CVE-2024-36950",
"CVE-2024-43911",
"CVE-2024-47663",
"CVE-2024-47666",
"CVE-2024-47728",
"CVE-2024-49914",
"CVE-2024-49945",
"CVE-2024-49963",
"CVE-2024-49982",
"CVE-2024-50099",
"CVE-2024-50115",
"CVE-2024-50138",
"CVE-2024-50184",
"CVE-2024-50195",
"CVE-2024-50198",
"CVE-2024-50237",
"CVE-2024-50242",
"CVE-2024-50245",
"CVE-2024-50246",
"CVE-2024-50247"
]
}
OESA-2024-2446 (CVE-2024-26944)
Vulnerability from osv_openeuler – Published: 2024-11-22 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: fix use-after-free in do_zone_finish()
Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070.
BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007
CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? btrfs_put_root+0x2d/0x220 [btrfs] ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs] cleaner_kthread+0x21e/0x380 [btrfs] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK>
Allocated by task 3493983: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 btrfs_alloc_device+0xb3/0x4e0 [btrfs] device_list_add.constprop.0+0x993/0x1630 [btrfs] btrfs_scan_one_device+0x219/0x3d0 [btrfs] btrfs_control_ioctl+0x26e/0x310 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76
Freed by task 3494056: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3f/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x32/0x70 kfree+0x11b/0x320 btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs] btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs] btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs] btrfs_ioctl+0xb27/0x57d0 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76
The buggy address belongs to the object at ffff8881543c8000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 96 bytes inside of freed 1024-byte region [ffff8881543c8000, ffff8881543c8400)
The buggy address belongs to the physical page: page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8 head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
This UAF happens because we're accessing stale zone information of a already removed btrfs_device in do_zone_finish().
The sequence of events is as follows:
btrfs_dev_replace_start btrfs_scrub_dev btrfs_dev_replace_finishing btrfs_dev_replace_update_device_in_mapping_tree <-- devices replaced btrfs_rm_dev_replace_free_srcdev btrfs_free_device <-- device freed
cleaner_kthread btrfs_delete_unused_bgs btrfs_zone_finish do_zone_finish <-- refers the freed device
The reason for this is that we're using a ---truncated---(CVE-2024-26944)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: HCI: Fix potential null-ptr-deref
Fix potential null-ptr-deref in hci_le_big_sync_established_evt().(CVE-2024-36011)
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: Fix napi_skb_cache_put warning
After the commit bdacf3e34945 ("net: Use nested-BH locking for napi_alloc_cache.") was merged, the following warning began to appear:
WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0
__warn+0x12f/0x340
napi_skb_cache_put+0x82/0x4b0
napi_skb_cache_put+0x82/0x4b0
report_bug+0x165/0x370
handle_bug+0x3d/0x80
exc_invalid_op+0x1a/0x50
asm_exc_invalid_op+0x1a/0x20
__free_old_xmit+0x1c8/0x510
napi_skb_cache_put+0x82/0x4b0
__free_old_xmit+0x1c8/0x510
__free_old_xmit+0x1c8/0x510
__pfx___free_old_xmit+0x10/0x10
The issue arises because virtio is assuming it's running in NAPI context even when it's not, such as in the netpoll case.
To resolve this, modify virtnet_poll_tx() to only set NAPI when budget is available. Same for virtnet_poll_cleantx(), which always assumed that it was in a NAPI context.(CVE-2024-43835)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix NULL dereference at band check in starting tx ba session
In MLD connection, link_data/link_conf are dynamically allocated. They don't point to vif->bss_conf. So, there will be no chanreq assigned to vif->bss_conf and then the chan will be NULL. Tweak the code to check ht_supported/vht_supported/has_he/has_eht on sta deflink.
Crash log (with rtw89 version under MLO development): [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9890.526102] #PF: supervisor read access in kernel mode [ 9890.526105] #PF: error_code(0x0000) - not-present page [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1 [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 [ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core] [ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 All code ======== 0: f7 e8 imul %eax 2: d5 (bad) 3: 93 xchg %eax,%ebx 4: 3e ea ds (bad) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c: 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz
Code starting with the faulting instruction
0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 test %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873 [ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70 [ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000 [ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000 [ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Call Trace: [ 9890.526324] <TASK> [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713) [ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator ---truncated---(CVE-2024-43911)
In the Linux kernel, the following vulnerability has been resolved:
bonding: fix xfrm real_dev null pointer dereference
We shouldn't set real_dev to NULL because packets can be in transit and xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume real_dev is set.
Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: error_code(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel: <TASK> kernel: ? __die+0x1f/0x60 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? page_fault_oops+0x142/0x4c0 kernel: ? do_user_addr_fault+0x65/0x670 kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50 kernel: bond0: (slave eni0np1): making interface the new active one kernel: ? exc_page_fault+0x7b/0x180 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): making interface the new active one kernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding] kernel: xfrm_output+0x61/0x3b0 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ip_push_pending_frames+0x56/0x80(CVE-2024-44989)
In the Linux kernel, the following vulnerability has been resolved:
igb: cope with large MAX_SKB_FRAGS
Sabrina reports that the igb driver does not cope well with large MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload corruption on TX.
An easy reproducer is to run ssh to connect to the machine. With MAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails. This has been reported originally in https://bugzilla.redhat.com/show_bug.cgi?id=2265320
The root cause of the issue is that the driver does not take into account properly the (possibly large) shared info size when selecting the ring layout, and will try to fit two packets inside the same 4K page even when the 1st fraglist will trump over the 2nd head.
Address the issue by checking if 2K buffers are insufficient.(CVE-2024-45030)
In the Linux kernel, the following vulnerability has been resolved:
bonding: change ipsec_lock from spin lock to mutex
In the cited commit, bond->ipsec_lock is added to protect ipsec_list, hence xdo_dev_state_add and xdo_dev_state_delete are called inside this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep, "scheduling while atomic" will be triggered when changing bond's active slave.
[ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200 [ 101.055726] Modules linked in: [ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1 [ 101.058760] Hardware name: [ 101.059434] Call Trace: [ 101.059436] <TASK> [ 101.060873] dump_stack_lvl+0x51/0x60 [ 101.061275] __schedule_bug+0x4e/0x60 [ 101.061682] __schedule+0x612/0x7c0 [ 101.062078] ? __mod_timer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] schedule_timeout+0x77/0xf0 [ 101.063265] ? asm_common_interrupt+0x22/0x40 [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10 [ 101.064215] __wait_for_common+0x87/0x190 [ 101.064648] ? usleep_range_state+0x90/0x90 [ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core] [ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core] [ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core] [ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core] [ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.067738] ? kmalloc_trace+0x4d/0x350 [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core] [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core] [ 101.069312] bond_change_active_slave+0x392/0x900 [bonding] [ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding] [ 101.070454] __bond_opt_set+0xa6/0x430 [bonding] [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding] [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding] [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0 [ 101.073033] vfs_write+0x2d8/0x400 [ 101.073416] ? alloc_fd+0x48/0x180 [ 101.073798] ksys_write+0x5f/0xe0 [ 101.074175] do_syscall_64+0x52/0x110 [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53
As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called from bond_change_active_slave, which requires holding the RTNL lock. And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user context. So ipsec_lock doesn't have to be spin lock, change it to mutex, and thus the above issue can be resolved.(CVE-2024-46678)
In the Linux kernel, the following vulnerability has been resolved:
fou: Fix null-ptr-deref in GRO.
We observed a null-ptr-deref in fou_gro_receive() while shutting down a host. [0]
The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol in struct fou.
When fou_release() is called due to netns dismantle or explicit tunnel teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data. Then, the tunnel socket is destroyed after a single RCU grace period.
So, in-flight udp4_gro_receive() could find the socket and execute the FOU GRO handler, where sk->sk_user_data could be NULL.
Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL checks in FOU GRO handlers.
[0]: BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0 SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1 Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017 RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou] Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42 RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010 RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08 RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002 R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400 R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0 FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) </IRQ> do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626) RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575) Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246 RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900 RDX: ffff93daee800000 RSI: ffff93d ---truncated---(CVE-2024-46763)
In the Linux kernel, the following vulnerability has been resolved:
tcp_bpf: fix return value of tcp_bpf_sendmsg()
When we cork messages in psock->cork, the last message triggers the flushing will result in sending a sk_msg larger than the current message size. In this case, in tcp_bpf_send_verdict(), 'copied' becomes negative at least in the following case:
468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); // <==== HERE 473 return -EACCES;
Therefore, it could lead to the following BUG with a proper value of 'copied' (thanks to syzbot). We should not use negative 'copied' as a return value here.
------------[ cut here ]------------ kernel BUG at net/socket.c:733! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Hardware name: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : sock_sendmsg_nosec net/socket.c:733 [inline] pc : sock_sendmsg_nosec net/socket.c:728 [inline] pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745 lr : sock_sendmsg_nosec net/socket.c:730 [inline] lr : __sock_sendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef Call trace: sock_sendmsg_nosec net/socket.c:733 [inline] __sock_sendmsg+0x5c/0x60 net/socket.c:745 _syssendmsg+0x274/0x2ac net/socket.c:2597 _sys_sendmsg+0xac/0x100 net/socket.c:2651 __sys_sendmsg+0x84/0xe0 net/socket.c:2680 __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ end trace 0000000000000000 ]---(CVE-2024-46783)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix smatch static checker warning
adev->gfx.imu.funcs could be NULL(CVE-2024-46835)
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm80xx: Set phy->enable_completion only when we wait for it
pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash.(CVE-2024-47666)
In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling.(CVE-2024-47674)
In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.(CVE-2024-47723)
In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf__check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the mtu_len on error path which can be lifted later again.(CVE-2024-47728)
In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.(CVE-2024-49945)
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().(CVE-2024-50056)
In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.(CVE-2024-50061)
In the Linux kernel, the following vulnerability has been resolved: unicode: Don't special case ignorable code points We don't need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)
In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.(CVE-2024-50115)
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix UAF on iso_sock_timeout conn->sk maybe have been unlinked/freed while waiting for iso_conn_lock so this checks if the conn->sk is still valid by checking if it part of iso_sk_list.(CVE-2024-50124)
In the Linux kernel, the following vulnerability has been resolved: bpf: Use raw_spinlock_t in ringbuf The function __bpf_ringbuf_reserve is invoked from a tracepoint, which disables preemption. Using spinlock_t in this context can lead to a "sleep in atomic" warning in the RT variant. This issue is illustrated in the example below: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [<ffffd33a5c88ea44>] migrate_enable+0xc0/0x39c CPU: 7 PID: 556208 Comm: test_progs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Switch the spinlock to raw_spinlock_t to avoid this error.(CVE-2024-50138)
(CVE-2024-50151)
In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_device(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->free_device().(CVE-2024-50153)
In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)
In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.(CVE-2024-50193)
In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.(CVE-2024-50198)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)
In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-50215)
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data(CVE-2024-50237)
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release(CVE-2024-50242)
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.(CVE-2024-50243)
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.(CVE-2024-50244)
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().(CVE-2024-50245)
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check(CVE-2024-50246)
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.(CVE-2024-50247)
In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.(CVE-2024-50250)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"kernel-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"kernel-source-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"perf-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"python3-perf-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-55.0.0.58.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-55.0.0.58.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"kernel-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"kernel-source-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"perf-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"python3-perf-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-55.0.0.58.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-55.0.0.58.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: zoned: fix use-after-free in do_zone_finish()\r\n\r\nShinichiro reported the following use-after-free triggered by the device\nreplace operation in fstests btrfs/070.\r\n\r\n BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0\n ==================================================================\n BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs]\n Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007\r\n\r\n CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1\n Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x5b/0x90\n print_report+0xcf/0x670\n ? __virt_addr_valid+0x200/0x3e0\n kasan_report+0xd8/0x110\n ? do_zone_finish+0x91a/0xb90 [btrfs]\n ? do_zone_finish+0x91a/0xb90 [btrfs]\n do_zone_finish+0x91a/0xb90 [btrfs]\n btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs]\n ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs]\n ? btrfs_put_root+0x2d/0x220 [btrfs]\n ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs]\n cleaner_kthread+0x21e/0x380 [btrfs]\n ? __pfx_cleaner_kthread+0x10/0x10 [btrfs]\n kthread+0x2e3/0x3c0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x70\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\n Allocated by task 3493983:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n btrfs_alloc_device+0xb3/0x4e0 [btrfs]\n device_list_add.constprop.0+0x993/0x1630 [btrfs]\n btrfs_scan_one_device+0x219/0x3d0 [btrfs]\n btrfs_control_ioctl+0x26e/0x310 [btrfs]\n __x64_sys_ioctl+0x134/0x1b0\n do_syscall_64+0x99/0x190\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\n Freed by task 3494056:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3f/0x60\n poison_slab_object+0x102/0x170\n __kasan_slab_free+0x32/0x70\n kfree+0x11b/0x320\n btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs]\n btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs]\n btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs]\n btrfs_ioctl+0xb27/0x57d0 [btrfs]\n __x64_sys_ioctl+0x134/0x1b0\n do_syscall_64+0x99/0x190\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\n The buggy address belongs to the object at ffff8881543c8000\n which belongs to the cache kmalloc-1k of size 1024\n The buggy address is located 96 bytes inside of\n freed 1024-byte region [ffff8881543c8000, ffff8881543c8400)\r\n\r\n The buggy address belongs to the physical page:\n page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8\n head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff)\n page_type: 0xffffffff()\n raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002\n raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\r\n\r\n Memory state around the buggy address:\n ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u0026gt;ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ^\n ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\r\n\r\nThis UAF happens because we\u0026apos;re accessing stale zone information of a\nalready removed btrfs_device in do_zone_finish().\r\n\r\nThe sequence of events is as follows:\r\n\r\nbtrfs_dev_replace_start\n btrfs_scrub_dev\n btrfs_dev_replace_finishing\n btrfs_dev_replace_update_device_in_mapping_tree \u0026lt;-- devices replaced\n btrfs_rm_dev_replace_free_srcdev\n btrfs_free_device \u0026lt;-- device freed\r\n\r\ncleaner_kthread\n btrfs_delete_unused_bgs\n btrfs_zone_finish\n do_zone_finish \u0026lt;-- refers the freed device\r\n\r\nThe reason for this is that we\u0026apos;re using a\n---truncated---(CVE-2024-26944)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: HCI: Fix potential null-ptr-deref\r\n\r\nFix potential null-ptr-deref in hci_le_big_sync_established_evt().(CVE-2024-36011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvirtio_net: Fix napi_skb_cache_put warning\r\n\r\nAfter the commit bdacf3e34945 (\u0026quot;net: Use nested-BH locking for\nnapi_alloc_cache.\u0026quot;) was merged, the following warning began to appear:\r\n\r\n\t WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0\r\n\r\n\t __warn+0x12f/0x340\n\t napi_skb_cache_put+0x82/0x4b0\n\t napi_skb_cache_put+0x82/0x4b0\n\t report_bug+0x165/0x370\n\t handle_bug+0x3d/0x80\n\t exc_invalid_op+0x1a/0x50\n\t asm_exc_invalid_op+0x1a/0x20\n\t __free_old_xmit+0x1c8/0x510\n\t napi_skb_cache_put+0x82/0x4b0\n\t __free_old_xmit+0x1c8/0x510\n\t __free_old_xmit+0x1c8/0x510\n\t __pfx___free_old_xmit+0x10/0x10\r\n\r\nThe issue arises because virtio is assuming it\u0026apos;s running in NAPI context\neven when it\u0026apos;s not, such as in the netpoll case.\r\n\r\nTo resolve this, modify virtnet_poll_tx() to only set NAPI when budget\nis available. Same for virtnet_poll_cleantx(), which always assumed that\nit was in a NAPI context.(CVE-2024-43835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: fix NULL dereference at band check in starting tx ba session\r\n\r\nIn MLD connection, link_data/link_conf are dynamically allocated. They\ndon\u0026apos;t point to vif-\u0026gt;bss_conf. So, there will be no chanreq assigned to\nvif-\u0026gt;bss_conf and then the chan will be NULL. Tweak the code to check\nht_supported/vht_supported/has_he/has_eht on sta deflink.\r\n\r\nCrash log (with rtw89 version under MLO development):\n[ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 9890.526102] #PF: supervisor read access in kernel mode\n[ 9890.526105] #PF: error_code(0x0000) - not-present page\n[ 9890.526109] PGD 0 P4D 0\n[ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI\n[ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1\n[ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018\n[ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core]\n[ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211\n[ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 \u0026lt;83\u0026gt; 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3\nAll code\n========\n 0:\tf7 e8 \timul %eax\n 2:\td5 \t(bad)\n 3:\t93 \txchg %eax,%ebx\n 4:\t3e ea \tds (bad)\n 6:\t48 83 c4 28 \tadd $0x28,%rsp\n a:\t89 d8 \tmov %ebx,%eax\n c:\t5b \tpop %rbx\n d:\t41 5c \tpop %r12\n f:\t41 5d \tpop %r13\n 11:\t41 5e \tpop %r14\n 13:\t41 5f \tpop %r15\n 15:\t5d \tpop %rbp\n 16:\tc3 \tretq\n 17:\tcc \tint3\n 18:\tcc \tint3\n 19:\tcc \tint3\n 1a:\tcc \tint3\n 1b:\t49 8b 84 24 e0 f1 ff \tmov -0xe20(%r12),%rax\n 22:\tff\n 23:\t48 8b 80 90 1b 00 00 \tmov 0x1b90(%rax),%rax\n 2a:*\t83 38 03 \tcmpl $0x3,(%rax)\t\t\u0026lt;-- trapping instruction\n 2d:\t0f 84 37 fe ff ff \tje 0xfffffffffffffe6a\n 33:\tbb ea ff ff ff \tmov $0xffffffea,%ebx\n 38:\teb cc \tjmp 0x6\n 3a:\t49 \trex.WB\n 3b:\t8b \t.byte 0x8b\n 3c:\t84 24 10 \ttest %ah,(%rax,%rdx,1)\n 3f:\tf3 \trepz\r\n\r\nCode starting with the faulting instruction\n===========================================\n 0:\t83 38 03 \tcmpl $0x3,(%rax)\n 3:\t0f 84 37 fe ff ff \tje 0xfffffffffffffe40\n 9:\tbb ea ff ff ff \tmov $0xffffffea,%ebx\n e:\teb cc \tjmp 0xffffffffffffffdc\n 10:\t49 \trex.WB\n 11:\t8b \t.byte 0x8b\n 12:\t84 24 10 \ttest %ah,(%rax,%rdx,1)\n 15:\tf3 \trepz\n[ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246\n[ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8\n[ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685\n[ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873\n[ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70\n[ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000\n[ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000\n[ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0\n[ 9890.526321] Call Trace:\n[ 9890.526324] \u0026lt;TASK\u0026gt;\n[ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479)\n[ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)\n[ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713)\n[ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator\n---truncated---(CVE-2024-43911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: fix xfrm real_dev null pointer dereference\r\n\r\nWe shouldn\u0026apos;t set real_dev to NULL because packets can be in transit and\nxfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume\nreal_dev is set.\r\n\r\n Example trace:\n kernel: BUG: unable to handle page fault for address: 0000000000001030\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: #PF: supervisor write access in kernel mode\n kernel: #PF: error_code(0x0002) - not-present page\n kernel: PGD 0 P4D 0\n kernel: Oops: 0002 [#1] PREEMPT SMP\n kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12\n kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\n kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 \u0026lt;83\u0026gt; 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel:\n kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60\n kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00\n kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014\n kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000\n kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000\n kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000\n kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: Call Trace:\n kernel: \u0026lt;TASK\u0026gt;\n kernel: ? __die+0x1f/0x60\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel: ? page_fault_oops+0x142/0x4c0\n kernel: ? do_user_addr_fault+0x65/0x670\n kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: ? exc_page_fault+0x7b/0x180\n kernel: ? asm_exc_page_fault+0x22/0x30\n kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim]\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding]\n kernel: xfrm_output+0x61/0x3b0\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel: ip_push_pending_frames+0x56/0x80(CVE-2024-44989)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nigb: cope with large MAX_SKB_FRAGS\r\n\r\nSabrina reports that the igb driver does not cope well with large\nMAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload\ncorruption on TX.\r\n\r\nAn easy reproducer is to run ssh to connect to the machine. With\nMAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails. This has\nbeen reported originally in\nhttps://bugzilla.redhat.com/show_bug.cgi?id=2265320\r\n\r\nThe root cause of the issue is that the driver does not take into\naccount properly the (possibly large) shared info size when selecting\nthe ring layout, and will try to fit two packets inside the same 4K\npage even when the 1st fraglist will trump over the 2nd head.\r\n\r\nAddress the issue by checking if 2K buffers are insufficient.(CVE-2024-45030)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: change ipsec_lock from spin lock to mutex\r\n\r\nIn the cited commit, bond-\u0026gt;ipsec_lock is added to protect ipsec_list,\nhence xdo_dev_state_add and xdo_dev_state_delete are called inside\nthis lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep,\n\u0026quot;scheduling while atomic\u0026quot; will be triggered when changing bond\u0026apos;s\nactive slave.\r\n\r\n[ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200\n[ 101.055726] Modules linked in:\n[ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1\n[ 101.058760] Hardware name:\n[ 101.059434] Call Trace:\n[ 101.059436] \u0026lt;TASK\u0026gt;\n[ 101.060873] dump_stack_lvl+0x51/0x60\n[ 101.061275] __schedule_bug+0x4e/0x60\n[ 101.061682] __schedule+0x612/0x7c0\n[ 101.062078] ? __mod_timer+0x25c/0x370\n[ 101.062486] schedule+0x25/0xd0\n[ 101.062845] schedule_timeout+0x77/0xf0\n[ 101.063265] ? asm_common_interrupt+0x22/0x40\n[ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10\n[ 101.064215] __wait_for_common+0x87/0x190\n[ 101.064648] ? usleep_range_state+0x90/0x90\n[ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core]\n[ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core]\n[ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core]\n[ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core]\n[ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding]\n[ 101.067738] ? kmalloc_trace+0x4d/0x350\n[ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core]\n[ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core]\n[ 101.069312] bond_change_active_slave+0x392/0x900 [bonding]\n[ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding]\n[ 101.070454] __bond_opt_set+0xa6/0x430 [bonding]\n[ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding]\n[ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding]\n[ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding]\n[ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0\n[ 101.073033] vfs_write+0x2d8/0x400\n[ 101.073416] ? alloc_fd+0x48/0x180\n[ 101.073798] ksys_write+0x5f/0xe0\n[ 101.074175] do_syscall_64+0x52/0x110\n[ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53\r\n\r\nAs bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called\nfrom bond_change_active_slave, which requires holding the RTNL lock.\nAnd bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state\nxdo_dev_state_add and xdo_dev_state_delete APIs, which are in user\ncontext. So ipsec_lock doesn\u0026apos;t have to be spin lock, change it to\nmutex, and thus the above issue can be resolved.(CVE-2024-46678)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfou: Fix null-ptr-deref in GRO.\r\n\r\nWe observed a null-ptr-deref in fou_gro_receive() while shutting down\na host. [0]\r\n\r\nThe NULL pointer is sk-\u0026gt;sk_user_data, and the offset 8 is of protocol\nin struct fou.\r\n\r\nWhen fou_release() is called due to netns dismantle or explicit tunnel\nteardown, udp_tunnel_sock_release() sets NULL to sk-\u0026gt;sk_user_data.\nThen, the tunnel socket is destroyed after a single RCU grace period.\r\n\r\nSo, in-flight udp4_gro_receive() could find the socket and execute the\nFOU GRO handler, where sk-\u0026gt;sk_user_data could be NULL.\r\n\r\nLet\u0026apos;s use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL\nchecks in FOU GRO handlers.\r\n\r\n[0]:\nBUG: kernel NULL pointer dereference, address: 0000000000000008\n PF: supervisor read access in kernel mode\n PF: error_code(0x0000) - not-present page\nPGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0\nSMP PTI\nCPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1\nHardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017\nRIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]\nCode: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 \u0026lt;0f\u0026gt; b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42\nRSP: 0018:ffffa330c0003d08 EFLAGS: 00010297\nRAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010\nRDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08\nRBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002\nR10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400\nR13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0\nFS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)\n ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)\n ? no_context (arch/x86/mm/fault.c:752)\n ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483)\n ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571)\n ? fou_gro_receive (net/ipv4/fou.c:233) [fou]\n udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559)\n udp4_gro_receive (net/ipv4/udp_offload.c:604)\n inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7))\n dev_gro_receive (net/core/dev.c:6035 (discriminator 4))\n napi_gro_receive (net/core/dev.c:6170)\n ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena]\n ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena]\n napi_poll (net/core/dev.c:6847)\n net_rx_action (net/core/dev.c:6917)\n __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299)\n asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)\n\u0026lt;/IRQ\u0026gt;\n do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77)\n irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435)\n common_interrupt (arch/x86/kernel/irq.c:239)\n asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)\nRIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)\nCode: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00\nRSP: 0018:ffffffffb5603e58 EFLAGS: 00000246\nRAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900\nRDX: ffff93daee800000 RSI: ffff93d\n---truncated---(CVE-2024-46763)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp_bpf: fix return value of tcp_bpf_sendmsg()\r\n\r\nWhen we cork messages in psock-\u0026gt;cork, the last message triggers the\nflushing will result in sending a sk_msg larger than the current\nmessage size. In this case, in tcp_bpf_send_verdict(), \u0026apos;copied\u0026apos; becomes\nnegative at least in the following case:\r\n\r\n468 case __SK_DROP:\n469 default:\n470 sk_msg_free_partial(sk, msg, tosend);\n471 sk_msg_apply_bytes(psock, tosend);\n472 *copied -= (tosend + delta); // \u0026lt;==== HERE\n473 return -EACCES;\r\n\r\nTherefore, it could lead to the following BUG with a proper value of\n\u0026apos;copied\u0026apos; (thanks to syzbot). We should not use negative \u0026apos;copied\u0026apos; as a\nreturn value here.\r\n\r\n ------------[ cut here ]------------\n kernel BUG at net/socket.c:733!\n Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n Modules linked in:\n CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0\n Hardware name: linux,dummy-virt (DT)\n pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : sock_sendmsg_nosec net/socket.c:733 [inline]\n pc : sock_sendmsg_nosec net/socket.c:728 [inline]\n pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745\n lr : sock_sendmsg_nosec net/socket.c:730 [inline]\n lr : __sock_sendmsg+0x54/0x60 net/socket.c:745\n sp : ffff800088ea3b30\n x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000\n x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000\n x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90\n x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001\n x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0\n x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000\n x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef\n Call trace:\n sock_sendmsg_nosec net/socket.c:733 [inline]\n __sock_sendmsg+0x5c/0x60 net/socket.c:745\n ____sys_sendmsg+0x274/0x2ac net/socket.c:2597\n ___sys_sendmsg+0xac/0x100 net/socket.c:2651\n __sys_sendmsg+0x84/0xe0 net/socket.c:2680\n __do_sys_sendmsg net/socket.c:2689 [inline]\n __se_sys_sendmsg net/socket.c:2687 [inline]\n __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49\n el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151\n el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712\n el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730\n el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598\n Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000)\n ---[ end trace 0000000000000000 ]---(CVE-2024-46783)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix smatch static checker warning\r\n\r\nadev-\u0026gt;gfx.imu.funcs could be NULL(CVE-2024-46835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: pm80xx: Set phy-\u0026gt;enable_completion only when we wait for it\r\n\r\npm8001_phy_control() populates the enable_completion pointer with a stack\naddress, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and\nreturns. The problem arises when a phy control response comes late. After\n300 ms the pm8001_phy_control() function returns and the passed\nenable_completion stack address is no longer valid. Late phy control\nresponse invokes complete() on a dangling enable_completion pointer which\nleads to a kernel crash.(CVE-2024-47666)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a \u0026apos;struct page\u0026apos;. That\u0026apos;s all very much intentional, but it does mean that it\u0026apos;s easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it\u0026apos;s very easy to do the error handling in the wrong order. In particular, it\u0026apos;s easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling.(CVE-2024-47674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp-\u0026gt;db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp-\u0026gt;db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.(CVE-2024-47723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we\u0026apos;re readding the issue we\u0026apos;re trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.(CVE-2024-47728)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.(CVE-2024-49945)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: \u0026apos;fmtdesc\u0026apos; dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: \u0026apos;fmtdesc\u0026apos; dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().(CVE-2024-50056)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, \u0026amp;master-\u0026gt;hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master-\u0026gt;base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(\u0026amp;master-\u0026gt;base) | device_unregister(\u0026amp;master-\u0026gt;dev) | device_release | //free master-\u0026gt;base | | i3c_master_do_daa(\u0026amp;master-\u0026gt;base) | //use master-\u0026gt;base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.(CVE-2024-50061)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: unicode: Don\u0026apos;t special case ignorable code points We don\u0026apos;t need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn\u0026apos;t enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn\u0026apos;t using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM\u0026apos;s much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it\u0026apos;s only the nSVM flow that is broken.(CVE-2024-50115)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix UAF on iso_sock_timeout conn-\u0026gt;sk maybe have been unlinked/freed while waiting for iso_conn_lock so this checks if the conn-\u0026gt;sk is still valid by checking if it part of iso_sk_list.(CVE-2024-50124)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: bpf: Use raw_spinlock_t in ringbuf The function __bpf_ringbuf_reserve is invoked from a tracepoint, which disables preemption. Using spinlock_t in this context can lead to a \u0026quot;sleep in atomic\u0026quot; warning in the RT variant. This issue is illustrated in the example below: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [\u0026lt;ffffd33a5c88ea44\u0026gt;] migrate_enable+0xc0/0x39c CPU: 7 PID: 556208 Comm: test_progs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Switch the spinlock to raw_spinlock_t to avoid this error.(CVE-2024-50138)\r\n\r\n(CVE-2024-50151)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev-\u0026gt;transport-\u0026gt;free_device(), but dev-\u0026gt;transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba-\u0026gt;backend-\u0026gt;ops-\u0026gt;free_device().(CVE-2024-50153)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \u0026quot;%ux%ux8\u0026quot;, xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don\u0026apos;t have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.(CVE-2024-50193)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.(CVE-2024-50198)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl-\u0026gt;dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it\u0026apos;s better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-50215)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data(CVE-2024-50237)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release(CVE-2024-50242)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.(CVE-2024-50243)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.(CVE-2024-50244)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().(CVE-2024-50245)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check(CVE-2024-50246)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.(CVE-2024-50247)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster\u0026apos;s recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter-\u0026gt;pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter-\u0026gt;pos. Hence we corrupt user data by copying it to the wrong place. If iter-\u0026gt;pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We\u0026apos;re not done yet -- there\u0026apos;s no call to invalidate_inode_pages2_range, so programs that have the file range mmap\u0026apos;d will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we\u0026apos;re operating on.(CVE-2024-50250)",
"id": "OESA-2024-2446",
"modified": "2026-08-06T11:07:55Z",
"published": "2024-11-22T11:07:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2446"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26944"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36011"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44989"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45030"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46763"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46783"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47666"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47674"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47723"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50056"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50061"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50115"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50124"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50151"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50153"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50180"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50193"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50198"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50202"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50215"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50237"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50242"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50243"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50245"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50246"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50247"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50250"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-26944",
"CVE-2024-36011",
"CVE-2024-43835",
"CVE-2024-43911",
"CVE-2024-44989",
"CVE-2024-45030",
"CVE-2024-46678",
"CVE-2024-46763",
"CVE-2024-46783",
"CVE-2024-46835",
"CVE-2024-47666",
"CVE-2024-47674",
"CVE-2024-47723",
"CVE-2024-47728",
"CVE-2024-49945",
"CVE-2024-50056",
"CVE-2024-50061",
"CVE-2024-50089",
"CVE-2024-50099",
"CVE-2024-50115",
"CVE-2024-50124",
"CVE-2024-50138",
"CVE-2024-50151",
"CVE-2024-50153",
"CVE-2024-50180",
"CVE-2024-50193",
"CVE-2024-50198",
"CVE-2024-50202",
"CVE-2024-50215",
"CVE-2024-50237",
"CVE-2024-50242",
"CVE-2024-50243",
"CVE-2024-50244",
"CVE-2024-50245",
"CVE-2024-50246",
"CVE-2024-50247",
"CVE-2024-50250"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.