{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-05-13T04:27:39.322","vulnerabilities":[{"cve":{"id":"CVE-2021-47608","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2024-06-19T15:15:55.360","lastModified":"2024-11-21T06:36:39.567","vulnStatus":"Modified","cveTags":[],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kernel address leakage in atomic fetch\n\nThe change in commit 37086bfdc737 (\"bpf: Propagate stack bounds to registers\nin atomics w/ BPF_FETCH\") around check_mem_access() handling is buggy since\nthis would allow for unprivileged users to leak kernel pointers. For example,\nan atomic fetch/and with -1 on a stack destination which holds a spilled\npointer will migrate the spilled register type into a scalar, which can then\nbe exported out of the program (since scalar != pointer) by dumping it into\na map value.\n\nThe original implementation of XADD was preventing this situation by using\na double call to check_mem_access() one with BPF_READ and a subsequent one\nwith BPF_WRITE, in both cases passing -1 as a placeholder value instead of\nregister as per XADD semantics since it didn't contain a value fetch. The\nBPF_READ also included a check in check_stack_read_fixed_off() which rejects\nthe program if the stack slot is of __is_pointer_value() if dst_regno < 0.\nThe latter is to distinguish whether we're dealing with a regular stack spill/\nfill or some arithmetical operation which is disallowed on non-scalars, see\nalso 6e7e63cbb023 (\"bpf: Forbid XADD on spilled pointers for unprivileged\nusers\") for more context on check_mem_access() and its handling of placeholder\nvalue -1.\n\nOne minimally intrusive option to fix the leak is for the BPF_FETCH case to\ninitially check the BPF_READ case via check_mem_access() with -1 as register,\nfollowed by the actual load case with non-negative load_reg to propagate\nstack bounds to registers."},{"lang":"es","value":"En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige la fuga de la dirección del kernel en la recuperación atómica. El cambio en el commit 37086bfdc737 (\"bpf: propaga los límites de la pila a los registros en atómicos con BPF_FETCH\") alrededor del manejo de check_mem_access() tiene errores ya que esto permitiría a usuarios sin privilegios filtrar punteros del kernel. Por ejemplo, una recuperación atómica/y con -1 en un destino de pila que contiene un puntero derramado migrará el tipo de registro derramado a un escalar, que luego se puede exportar fuera del programa (ya que escalar! = puntero) volcándolo en un valor de mapa. La implementación original de XADD evitaba esta situación mediante el uso de una llamada doble a check_mem_access(), una con BPF_READ y otra posterior con BPF_WRITE, en ambos casos pasando -1 como valor de marcador de posición en lugar de registrarse según la semántica de XADD, ya que no lo hacía contener una recuperación de valor. BPF_READ también incluyó una verificación en check_stack_read_fixed_off() que rechaza el programa si la ranura de la pila es de __is_pointer_value() si dst_regno &lt; 0. Esto último es para distinguir si estamos tratando con un derrame/llenado de pila regular o alguna operación aritmética que no está permitido en valores no escalares, consulte también 6e7e63cbb023 (\"bpf: Prohibir XADD en punteros dispersos para usuarios sin privilegios\") para obtener más contexto sobre check_mem_access() y su manejo del valor del marcador de posición -1. Una opción mínimamente intrusiva para solucionar la fuga es que el caso BPF_FETCH verifique inicialmente el caso BPF_READ mediante check_mem_access() con -1 como registro, seguido del caso de carga real con load_reg no negativo para propagar los límites de la pila a los registros."}],"metrics":{"cvssMetricV31":[{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"NONE","availabilityImpact":"NONE"},"exploitabilityScore":1.8,"impactScore":3.6}]},"weaknesses":[{"source":"nvd@nist.gov","type":"Primary","description":[{"lang":"en","value":"NVD-CWE-noinfo"}]}],"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.12","versionEndExcluding":"5.15.11","matchCriteriaId":"9E292CA0-C53B-4C70-B5CE-94AC1BC7673F"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:5.16:rc1:*:*:*:*:*:*","matchCriteriaId":"357AA433-37E8-4323-BFB2-3038D6E4B414"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:5.16:rc2:*:*:*:*:*:*","matchCriteriaId":"A73429BA-C2D9-4D0C-A75F-06A1CA8B3983"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:5.16:rc3:*:*:*:*:*:*","matchCriteriaId":"F621B5E3-E99D-49E7-90B9-EC3B77C95383"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:5.16:rc4:*:*:*:*:*:*","matchCriteriaId":"F7BFDCAA-1650-49AA-8462-407DD593F94F"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:5.16:rc5:*:*:*:*:*:*","matchCriteriaId":"6EC9882F-866D-4ACB-8FBC-213D8D8436C8"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/423628125a484538111c2c6d9bb1588eb086053b","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/7d3baf0afa3aa9102d6a521a8e4c41888bb79882","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/423628125a484538111c2c6d9bb1588eb086053b","source":"af854a3a-2127-422b-91ae-364da2661108","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/7d3baf0afa3aa9102d6a521a8e4c41888bb79882","source":"af854a3a-2127-422b-91ae-364da2661108","tags":["Patch"]}]}}]}