"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."
"value":"En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: bpf: corrige la fuga de la direcci\u00f3n del kernel en la recuperaci\u00f3n at\u00f3mica. El cambio en el commit 37086bfdc737 (\"bpf: propaga los l\u00edmites de la pila a los registros en at\u00f3micos con BPF_FETCH\") alrededor del manejo de check_mem_access() tiene errores ya que esto permitir\u00eda a usuarios sin privilegios filtrar punteros del kernel. Por ejemplo, una recuperaci\u00f3n at\u00f3mica/y con -1 en un destino de pila que contiene un puntero derramado migrar\u00e1 el tipo de registro derramado a un escalar, que luego se puede exportar fuera del programa (ya que escalar! = puntero) volc\u00e1ndolo en un valor de mapa. La implementaci\u00f3n original de XADD evitaba esta situaci\u00f3n 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\u00f3n en lugar de registrarse seg\u00fan la sem\u00e1ntica de XADD, ya que no lo hac\u00eda contener una recuperaci\u00f3n de valor. BPF_READ tambi\u00e9n incluy\u00f3 una verificaci\u00f3n en check_stack_read_fixed_off() que rechaza el programa si la ranura de la pila es de __is_pointer_value() si dst_regno < 0. Esto \u00faltimo es para distinguir si estamos tratando con un derrame/llenado de pila regular o alguna operaci\u00f3n aritm\u00e9tica que no est\u00e1 permitido en valores no escalares, consulte tambi\u00e9n 6e7e63cbb023 (\"bpf: Prohibir XADD en punteros dispersos para usuarios sin privilegios\") para obtener m\u00e1s contexto sobre check_mem_access() y su manejo del valor del marcador de posici\u00f3n -1. Una opci\u00f3n m\u00ednimamente 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\u00edmites de la pila a los registros."
