{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-56786", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-12-29T11:26:39.770Z", "datePublished": "2025-01-08T17:52:02.435Z", "dateUpdated": "2025-01-08T17:52:02.435Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2025-01-08T17:52:02.435Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: put bpf_link's program when link is safe to be deallocated\n\nIn general, BPF link's underlying BPF program should be considered to be\nreachable through attach hook -> link -> prog chain, and, pessimistically,\nwe have to assume that as long as link's memory is not safe to free,\nattach hook's code might hold a pointer to BPF program and use it.\n\nAs such, it's not (generally) correct to put link's program early before\nwaiting for RCU GPs to go through. More eager bpf_prog_put() that we\ncurrently do is mostly correct due to BPF program's release code doing\nsimilar RCU GP waiting, but as will be shown in the following patches,\nBPF program can be non-sleepable (and, thus, reliant on only \"classic\"\nRCU GP), while BPF link's attach hook can have sleepable semantics and\nneeds to be protected by RCU Tasks Trace, and for such cases BPF link\nhas to go through RCU Tasks Trace + \"classic\" RCU GPs before being\ndeallocated. And so, if we put BPF program early, we might free BPF\nprogram before we free BPF link, leading to use-after-free situation.\n\nSo, this patch defers bpf_prog_put() until we are ready to perform\nbpf_link's deallocation. At worst, this delays BPF program freeing by\none extra RCU GP, but that seems completely acceptable. Alternatively,\nwe'd need more elaborate ways to determine BPF hook, BPF link, and BPF\nprogram lifetimes, and how they relate to each other, which seems like\nan unnecessary complication.\n\nNote, for most BPF links we still will perform eager bpf_prog_put() and\nlink dealloc, so for those BPF links there are no observable changes\nwhatsoever. Only BPF links that use deferred dealloc might notice\nslightly delayed freeing of BPF programs.\n\nAlso, to reduce code and logic duplication, extract program put + link\ndealloc logic into bpf_link_dealloc() helper."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["kernel/bpf/syscall.c"], "versions": [{"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "lessThan": "5fe23c57abadfd46a7a66e81f3536e4757252a0b", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "lessThan": "2fcb921c2799c49ac5e365cf4110f94a64ae4885", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", "lessThan": "f44ec8733a8469143fde1984b5e6931b2e2f6f3f", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["kernel/bpf/syscall.c"], "versions": [{"version": "6.6.66", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.12.5", "lessThanOrEqual": "6.12.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.13-rc1", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b"}, {"url": "https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885"}, {"url": "https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f"}], "title": "bpf: put bpf_link's program when link is safe to be deallocated", "x_generator": {"engine": "bippy-5f407fcff5a0"}}}}

{}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "90A079EF-8212-45DF-84FB-C525A64635B0", "versionEndExcluding": "6.6.66", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "9501D045-7A94-42CA-8B03-821BE94A65B7", "versionEndExcluding": "6.12.5", "versionStartIncluding": "6.7", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: put bpf_link's program when link is safe to be deallocated\n\nIn general, BPF link's underlying BPF program should be considered to be\nreachable through attach hook -> link -> prog chain, and, pessimistically,\nwe have to assume that as long as link's memory is not safe to free,\nattach hook's code might hold a pointer to BPF program and use it.\n\nAs such, it's not (generally) correct to put link's program early before\nwaiting for RCU GPs to go through. More eager bpf_prog_put() that we\ncurrently do is mostly correct due to BPF program's release code doing\nsimilar RCU GP waiting, but as will be shown in the following patches,\nBPF program can be non-sleepable (and, thus, reliant on only \"classic\"\nRCU GP), while BPF link's attach hook can have sleepable semantics and\nneeds to be protected by RCU Tasks Trace, and for such cases BPF link\nhas to go through RCU Tasks Trace + \"classic\" RCU GPs before being\ndeallocated. And so, if we put BPF program early, we might free BPF\nprogram before we free BPF link, leading to use-after-free situation.\n\nSo, this patch defers bpf_prog_put() until we are ready to perform\nbpf_link's deallocation. At worst, this delays BPF program freeing by\none extra RCU GP, but that seems completely acceptable. Alternatively,\nwe'd need more elaborate ways to determine BPF hook, BPF link, and BPF\nprogram lifetimes, and how they relate to each other, which seems like\nan unnecessary complication.\n\nNote, for most BPF links we still will perform eager bpf_prog_put() and\nlink dealloc, so for those BPF links there are no observable changes\nwhatsoever. Only BPF links that use deferred dealloc might notice\nslightly delayed freeing of BPF programs.\n\nAlso, to reduce code and logic duplication, extract program put + link\ndealloc logic into bpf_link_dealloc() helper."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: poner el programa de bpf_link cuando es seguro desasignarlo En general, se debe considerar que el programa BPF subyacente del enlace BPF es accesible a trav\u00e9s de la cadena de gancho de conexi\u00f3n -> enlace -> programa y, de manera pesimista, tenemos que asumir que mientras no sea seguro liberar la memoria del enlace, el c\u00f3digo del gancho de conexi\u00f3n podr\u00eda contener un puntero al programa BPF y usarlo. Como tal, no es (generalmente) correcto poner el programa del enlace antes de esperar a que pasen los GP de RCU. El bpf_prog_put() m\u00e1s ansioso que hacemos actualmente es mayormente correcto debido a que el c\u00f3digo de lanzamiento del programa BPF hace una espera similar de GP RCU, pero como se mostrar\u00e1 en los parches siguientes, el programa BPF puede no ser inactivo (y, por lo tanto, depender solo del GP RCU \"cl\u00e1sico\"), mientras que el gancho de conexi\u00f3n del enlace BPF puede tener sem\u00e1ntica inactiva y necesita estar protegido por el Seguimiento de tareas RCU, y para tales casos el enlace BPF tiene que pasar por el Seguimiento de tareas RCU + GP RCU \"cl\u00e1sicos\" antes de ser desasignado. Y entonces, si ponemos el programa BPF temprano, podr\u00edamos liberar el programa BPF antes de liberar el enlace BPF, lo que lleva a una situaci\u00f3n de use-after-free. Entonces, este parche pospone bpf_prog_put() hasta que estemos listos para realizar la desasignaci\u00f3n de bpf_link. En el peor de los casos, esto retrasa la liberaci\u00f3n del programa BPF por un GP RCU adicional, pero eso parece completamente aceptable. Alternativamente, necesitar\u00edamos formas m\u00e1s elaboradas de determinar el gancho BPF, el enlace BPF y la duraci\u00f3n del programa BPF, y c\u00f3mo se relacionan entre s\u00ed, lo que parece una complicaci\u00f3n innecesaria. Tenga en cuenta que, para la mayor\u00eda de los enlaces BPF, seguiremos ejecutando bpf_prog_put() y link dealloc con avidez, por lo que para esos enlaces BPF no hay cambios observables en absoluto. Solo los enlaces BPF que usan dealloc diferido pueden notar una liberaci\u00f3n ligeramente retrasada de los programas BPF. Adem\u00e1s, para reducir la duplicaci\u00f3n de c\u00f3digo y l\u00f3gica, extraiga la l\u00f3gica de put del programa + link dealloc en el asistente bpf_link_dealloc()."}], "id": "CVE-2024-56786", "lastModified": "2025-01-10T18:53:06.473", "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": "2025-01-08T18:15:19.633", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f"}], "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: put bpf_link's program when link is safe to be deallocated", "id": "2336541", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2336541"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\nbpf: put bpf_link's program when link is safe to be deallocated\nIn general, BPF link's underlying BPF program should be considered to be\nreachable through attach hook -> link -> prog chain, and, pessimistically,\nwe have to assume that as long as link's memory is not safe to free,\nattach hook's code might hold a pointer to BPF program and use it.\nAs such, it's not (generally) correct to put link's program early before\nwaiting for RCU GPs to go through. More eager bpf_prog_put() that we\ncurrently do is mostly correct due to BPF program's release code doing\nsimilar RCU GP waiting, but as will be shown in the following patches,\nBPF program can be non-sleepable (and, thus, reliant on only \"classic\"\nRCU GP), while BPF link's attach hook can have sleepable semantics and\nneeds to be protected by RCU Tasks Trace, and for such cases BPF link\nhas to go through RCU Tasks Trace + \"classic\" RCU GPs before being\ndeallocated. And so, if we put BPF program early, we might free BPF\nprogram before we free BPF link, leading to use-after-free situation.\nSo, this patch defers bpf_prog_put() until we are ready to perform\nbpf_link's deallocation. At worst, this delays BPF program freeing by\none extra RCU GP, but that seems completely acceptable. Alternatively,\nwe'd need more elaborate ways to determine BPF hook, BPF link, and BPF\nprogram lifetimes, and how they relate to each other, which seems like\nan unnecessary complication.\nNote, for most BPF links we still will perform eager bpf_prog_put() and\nlink dealloc, so for those BPF links there are no observable changes\nwhatsoever. Only BPF links that use deferred dealloc might notice\nslightly delayed freeing of BPF programs.\nAlso, to reduce code and logic duplication, extract program put + link\ndealloc logic into bpf_link_dealloc() helper."], "name": "CVE-2024-56786", "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": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2025-01-08T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-56786\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-56786\nhttps://lore.kernel.org/linux-cve-announce/2025010808-CVE-2024-56786-1f56@gregkh/T"], "threat_severity": "Low"}