{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-50063", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-10-21T19:36:19.939Z", "datePublished": "2024-10-21T19:39:51.718Z", "dateUpdated": "2024-12-19T09:32:16.780Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-12-19T09:32:16.780Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Prevent tail call between progs attached to different hooks\n\nbpf progs can be attached to kernel functions, and the attached functions\ncan take different parameters or return different return values. If\nprog attached to one kernel function tail calls prog attached to another\nkernel function, the ctx access or return value verification could be\nbypassed.\n\nFor example, if prog1 is attached to func1 which takes only 1 parameter\nand prog2 is attached to func2 which takes two parameters. Since verifier\nassumes the bpf ctx passed to prog2 is constructed based on func2's\nprototype, verifier allows prog2 to access the second parameter from\nthe bpf ctx passed to it. The problem is that verifier does not prevent\nprog1 from passing its bpf ctx to prog2 via tail call. In this case,\nthe bpf ctx passed to prog2 is constructed from func1 instead of func2,\nthat is, the assumption for ctx access verification is bypassed.\n\nAnother example, if BPF LSM prog1 is attached to hook file_alloc_security,\nand BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier\nknows the return value rules for these two hooks, e.g. it is legal for\nbpf_lsm_audit_rule_known to return positive number 1, and it is illegal\nfor file_alloc_security to return positive number. So verifier allows\nprog2 to return positive number 1, but does not allow prog1 to return\npositive number. The problem is that verifier does not prevent prog1\nfrom calling prog2 via tail call. In this case, prog2's return value 1\nwill be used as the return value for prog1's hook file_alloc_security.\nThat is, the return value rule is bypassed.\n\nThis patch adds restriction for tail call to prevent such bypasses."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["include/linux/bpf.h", "kernel/bpf/core.c"], "versions": [{"version": "f1b9509c2fb0ef4db8d22dac9aef8e856a5d81f6", "lessThan": "5d5e3b4cbe8ee16b7bf96fd73a421c92a9da3ca1", "status": "affected", "versionType": "git"}, {"version": "f1b9509c2fb0ef4db8d22dac9aef8e856a5d81f6", "lessThan": "88c2a10e6c176c2860cd0659f4c0e9d20b3f64d1", "status": "affected", "versionType": "git"}, {"version": "f1b9509c2fb0ef4db8d22dac9aef8e856a5d81f6", "lessThan": "28ead3eaabc16ecc907cfb71876da028080f6356", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["include/linux/bpf.h", "kernel/bpf/core.c"], "versions": [{"version": "5.5", "status": "affected"}, {"version": "0", "lessThan": "5.5", "status": "unaffected", "versionType": "semver"}, {"version": "6.6.57", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.11.4", "lessThanOrEqual": "6.11.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.12", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/5d5e3b4cbe8ee16b7bf96fd73a421c92a9da3ca1"}, {"url": "https://git.kernel.org/stable/c/88c2a10e6c176c2860cd0659f4c0e9d20b3f64d1"}, {"url": "https://git.kernel.org/stable/c/28ead3eaabc16ecc907cfb71876da028080f6356"}], "title": "bpf: Prevent tail call between progs attached to different hooks", "x_generator": {"engine": "bippy-5f407fcff5a0"}}, "adp": [{"metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2024-50063", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-10-22T13:22:37.407385Z"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-10-22T13:28:41.892Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2024-50063", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-10-22T13:22:37.407385Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-10-22T13:22:40.892Z"}}], "cna": {"title": "bpf: Prevent tail call between progs attached to different hooks", "affected": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "f1b9509c2fb0", "lessThan": "5d5e3b4cbe8e", "versionType": "git"}, {"status": "affected", "version": "f1b9509c2fb0", "lessThan": "88c2a10e6c17", "versionType": "git"}, {"status": "affected", "version": "f1b9509c2fb0", "lessThan": "28ead3eaabc1", "versionType": "git"}], "programFiles": ["include/linux/bpf.h", "kernel/bpf/core.c"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "5.5"}, {"status": "unaffected", "version": "0", "lessThan": "5.5", "versionType": "semver"}, {"status": "unaffected", "version": "6.6.57", "versionType": "semver", "lessThanOrEqual": "6.6.*"}, {"status": "unaffected", "version": "6.11.4", "versionType": "semver", "lessThanOrEqual": "6.11.*"}, {"status": "unaffected", "version": "6.12-rc1", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["include/linux/bpf.h", "kernel/bpf/core.c"], "defaultStatus": "affected"}], "references": [{"url": "https://git.kernel.org/stable/c/5d5e3b4cbe8ee16b7bf96fd73a421c92a9da3ca1"}, {"url": "https://git.kernel.org/stable/c/88c2a10e6c176c2860cd0659f4c0e9d20b3f64d1"}, {"url": "https://git.kernel.org/stable/c/28ead3eaabc16ecc907cfb71876da028080f6356"}], "x_generator": {"engine": "bippy-9e1c9544281a"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Prevent tail call between progs attached to different hooks\n\nbpf progs can be attached to kernel functions, and the attached functions\ncan take different parameters or return different return values. If\nprog attached to one kernel function tail calls prog attached to another\nkernel function, the ctx access or return value verification could be\nbypassed.\n\nFor example, if prog1 is attached to func1 which takes only 1 parameter\nand prog2 is attached to func2 which takes two parameters. Since verifier\nassumes the bpf ctx passed to prog2 is constructed based on func2's\nprototype, verifier allows prog2 to access the second parameter from\nthe bpf ctx passed to it. The problem is that verifier does not prevent\nprog1 from passing its bpf ctx to prog2 via tail call. In this case,\nthe bpf ctx passed to prog2 is constructed from func1 instead of func2,\nthat is, the assumption for ctx access verification is bypassed.\n\nAnother example, if BPF LSM prog1 is attached to hook file_alloc_security,\nand BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier\nknows the return value rules for these two hooks, e.g. it is legal for\nbpf_lsm_audit_rule_known to return positive number 1, and it is illegal\nfor file_alloc_security to return positive number. So verifier allows\nprog2 to return positive number 1, but does not allow prog1 to return\npositive number. The problem is that verifier does not prevent prog1\nfrom calling prog2 via tail call. In this case, prog2's return value 1\nwill be used as the return value for prog1's hook file_alloc_security.\nThat is, the return value rule is bypassed.\n\nThis patch adds restriction for tail call to prevent such bypasses."}], "providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-08T06:48:26.330Z"}}}, "cveMetadata": {"cveId": "CVE-2024-50063", "state": "PUBLISHED", "dateUpdated": "2024-11-08T06:48:26.330Z", "dateReserved": "2024-10-21T19:36:19.939Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-10-21T19:39:51.718Z", "assignerShortName": "Linux"}, "dataVersion": "5.1"}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "AB671910-B967-44C6-8171-2422856A1696", "versionEndExcluding": "6.6.57", "versionStartIncluding": "5.5", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "AA84D336-CE9A-4535-B901-1AD77EC17C34", "versionEndExcluding": "6.11.4", "versionStartIncluding": "6.7", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Prevent tail call between progs attached to different hooks\n\nbpf progs can be attached to kernel functions, and the attached functions\ncan take different parameters or return different return values. If\nprog attached to one kernel function tail calls prog attached to another\nkernel function, the ctx access or return value verification could be\nbypassed.\n\nFor example, if prog1 is attached to func1 which takes only 1 parameter\nand prog2 is attached to func2 which takes two parameters. Since verifier\nassumes the bpf ctx passed to prog2 is constructed based on func2's\nprototype, verifier allows prog2 to access the second parameter from\nthe bpf ctx passed to it. The problem is that verifier does not prevent\nprog1 from passing its bpf ctx to prog2 via tail call. In this case,\nthe bpf ctx passed to prog2 is constructed from func1 instead of func2,\nthat is, the assumption for ctx access verification is bypassed.\n\nAnother example, if BPF LSM prog1 is attached to hook file_alloc_security,\nand BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier\nknows the return value rules for these two hooks, e.g. it is legal for\nbpf_lsm_audit_rule_known to return positive number 1, and it is illegal\nfor file_alloc_security to return positive number. So verifier allows\nprog2 to return positive number 1, but does not allow prog1 to return\npositive number. The problem is that verifier does not prevent prog1\nfrom calling prog2 via tail call. In this case, prog2's return value 1\nwill be used as the return value for prog1's hook file_alloc_security.\nThat is, the return value rule is bypassed.\n\nThis patch adds restriction for tail call to prevent such bypasses."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Evitar llamada de cola entre programas adjuntos a diferentes ganchos Los programas bpf se pueden adjuntar a funciones del kernel, y las funciones adjuntas pueden tomar diferentes par\u00e1metros o devolver diferentes valores de retorno. Si prog adjunto a una funci\u00f3n del kernel llama de cola a prog adjunto a otra funci\u00f3n del kernel, se podr\u00eda omitir la verificaci\u00f3n del acceso o del valor de retorno de ctx. Por ejemplo, si prog1 est\u00e1 adjunto a func1 que toma solo 1 par\u00e1metro y prog2 est\u00e1 adjunto a func2 que toma dos par\u00e1metros. Dado que el verificador asume que el bpf ctx pasado a prog2 se construye en base al prototipo de func2, el verificador permite a prog2 acceder al segundo par\u00e1metro del bpf ctx que se le pasa. El problema es que el verificador no impide que prog1 pase su bpf ctx a prog2 mediante llamada de cola. En este caso, el bpf ctx pasado a prog2 se construye a partir de func1 en lugar de func2, es decir, se omite la suposici\u00f3n de verificaci\u00f3n de acceso a ctx. Otro ejemplo, si BPF LSM prog1 est\u00e1 conectado al gancho file_alloc_security y BPF LSM prog2 est\u00e1 conectado al gancho bpf_lsm_audit_rule_known. El verificador conoce las reglas de valor de retorno para estos dos ganchos, por ejemplo, es legal que bpf_lsm_audit_rule_known devuelva un n\u00famero positivo 1 y es ilegal que file_alloc_security devuelva un n\u00famero positivo. Por lo tanto, el verificador permite que prog2 devuelva un n\u00famero positivo 1, pero no permite que prog1 devuelva un n\u00famero positivo. El problema es que el verificador no impide que prog1 llame a prog2 a trav\u00e9s de una llamada de cola. En este caso, el valor de retorno 1 de prog2 se utilizar\u00e1 como el valor de retorno para el gancho file_alloc_security de prog1. Es decir, se omite la regla del valor de retorno. Este parche agrega una restricci\u00f3n para la llamada de cola para evitar tales omisiones."}], "id": "CVE-2024-50063", "lastModified": "2024-11-22T17:26:31.070", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 7.8, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 5.9, "source": "nvd@nist.gov", "type": "Primary"}]}, "published": "2024-10-21T20:15:18.360", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/28ead3eaabc16ecc907cfb71876da028080f6356"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/5d5e3b4cbe8ee16b7bf96fd73a421c92a9da3ca1"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/88c2a10e6c176c2860cd0659f4c0e9d20b3f64d1"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "NVD-CWE-noinfo"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{"bugzilla": {"description": "kernel: bpf: Prevent tail call between progs attached to different hooks", "id": "2320617", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2320617"}, "csaw": false, "cvss3": {"cvss3_base_score": "6.7", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H", "status": "draft"}, "cwe": "CWE-841", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nbpf: Prevent tail call between progs attached to different hooks\nbpf progs can be attached to kernel functions, and the attached functions\ncan take different parameters or return different return values. If\nprog attached to one kernel function tail calls prog attached to another\nkernel function, the ctx access or return value verification could be\nbypassed.\nFor example, if prog1 is attached to func1 which takes only 1 parameter\nand prog2 is attached to func2 which takes two parameters. Since verifier\nassumes the bpf ctx passed to prog2 is constructed based on func2's\nprototype, verifier allows prog2 to access the second parameter from\nthe bpf ctx passed to it. The problem is that verifier does not prevent\nprog1 from passing its bpf ctx to prog2 via tail call. In this case,\nthe bpf ctx passed to prog2 is constructed from func1 instead of func2,\nthat is, the assumption for ctx access verification is bypassed.\nAnother example, if BPF LSM prog1 is attached to hook file_alloc_security,\nand BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier\nknows the return value rules for these two hooks, e.g. it is legal for\nbpf_lsm_audit_rule_known to return positive number 1, and it is illegal\nfor file_alloc_security to return positive number. So verifier allows\nprog2 to return positive number 1, but does not allow prog1 to return\npositive number. The problem is that verifier does not prevent prog1\nfrom calling prog2 via tail call. In this case, prog2's return value 1\nwill be used as the return value for prog1's hook file_alloc_security.\nThat is, the return value rule is bypassed.\nThis patch adds restriction for tail call to prevent such bypasses."], "name": "CVE-2024-50063", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Will not fix", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Will not fix", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Will not fix", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Will not fix", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-10-21T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-50063\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-50063\nhttps://lore.kernel.org/linux-cve-announce/2024102136-CVE-2024-50063-1a59@gregkh/T"], "statement": "The default Red Hat Enterprise Linux kernel prevents unprivileged users from being able to use eBPF by the kernel.unprivileged_bpf_disabled sysctl. This would require a privileged user with CAP_SYS_ADMIN or root to be able to abuse this flaw reducing its attack space.\nFor the Red Hat Enterprise Linux 9 to confirm the current state, inspect the sysctl with the command:\ncat /proc/sys/kernel/unprivileged_bpf_disabled\nThe setting of 1 would mean that unprivileged users can not use eBPF, mitigating the flaw.", "threat_severity": "Moderate"}