"value":"In the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix refcnt handling in padata_free_shell()\n\nIn a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead\nto system UAF (Use-After-Free) issues. Due to the lengthy analysis of\nthe pcrypt_aead01 function call, I'll describe the problem scenario\nusing a simplified model:\n\nSuppose there's a user of padata named `user_function` that adheres to\nthe padata requirement of calling `padata_free_shell` after `serial()`\nhas been invoked, as demonstrated in the following code:\n\n```c\nstruct request {\n struct padata_priv padata;\n struct completion *done;\n};\n\nvoid parallel(struct padata_priv *padata) {\n do_something();\n}\n\nvoid serial(struct padata_priv *padata) {\n struct request *request = container_of(padata,\n \t\t\t\tstruct request,\n\t\t\t\tpadata);\n complete(request->done);\n}\n\nvoid user_function() {\n DECLARE_COMPLETION(done)\n padata->parallel = parallel;\n padata->serial = serial;\n padata_do_parallel();\n wait_for_completion(&done);\n padata_free_shell();\n}\n```\n\nIn the corresponding padata.c file, there's the following code:\n\n```c\nstatic void padata_serial_worker(struct work_struct *serial_work) {\n ...\n cnt = 0;\n\n while (!list_empty(&local_list)) {\n ...\n padata->serial(padata);\n cnt++;\n }\n\n local_bh_enable();\n\n if (refcount_sub_and_test(cnt, &pd->refcnt))\n padata_free_pd(pd);\n}\n```\n\nBecause of the high system load and the accumulation of unexecuted\nsoftirq at this moment, `local_bh_enable()` in padata takes longer\nto execute than usual. Subsequently, when accessing `pd->refcnt`,\n`pd` has already been released by `padata_free_shell()`, resulting\nin a UAF issue with `pd->refcnt`.\n\nThe fix is straightforward: add `refcount_dec_and_test` before calling\n`padata_free_pd` in `padata_free_shell`."
"value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: padata: corrige el manejo de refcnt en padata_free_shell(). En un entorno arm64 de alta carga, la prueba pcrypt_aead01 en LTP puede provocar problemas de UAF (Use-After-Free) del sistema. Debido al extenso an\u00e1lisis de la llamada a la funci\u00f3n pcrypt_aead01, describir\u00e9 el escenario del problema usando un modelo simplificado: supongamos que hay un usuario de padata llamado `user_function` que cumple con el requisito de padata de llamar a `padata_free_shell` despu\u00e9s de `serial()`. ha sido invocado, como se demuestra en el siguiente c\u00f3digo: ```c struct request { struct padata_priv padata; finalizaci\u00f3n de la estructura *hecho; }; void paralelo(struct padata_priv *padata) { hacer_algo(); } void serial(struct padata_priv *padata) { solicitud de estructura *request = container_of(padata, solicitud de estructura, padata); completar(solicitud->hecho); } void user_function() { DECLARE_COMPLETION(hecho) padata->parallel = parallel; padata->serial = serial; padata_do_parallel(); wait_for_completion(&hecho); padata_free_shell(); } ``` En el archivo padata.c correspondiente, hay el siguiente c\u00f3digo: ```c static void padata_serial_worker(struct work_struct *serial_work) { ... cnt = 0; while (!list_empty(&local_list)) { ... padata->serial(padata); cnt++; } local_bh_enable(); if (refcount_sub_and_test(cnt, &pd->refcnt)) padata_free_pd(pd); } ``` Debido a la alta carga del sistema y la acumulaci\u00f3n de software no ejecutado en este momento, `local_bh_enable()` en padata tarda m\u00e1s de lo habitual en ejecutarse. Posteriormente, al acceder a `pd->refcnt`, `pd` ya ha sido liberado por `padata_free_shell()`, lo que genera un problema de UAF con `pd->refcnt`. La soluci\u00f3n es sencilla: agregue `refcount_dec_and_test` antes de llamar a `padata_free_pd` en `padata_free_shell`."
