CVE-2024-42096

{"id": "CVE-2024-42096", "cveTags": [], "metrics": {}, "published": "2024-07-29T18:15:12.087", "references": [{"url": "https://git.kernel.org/stable/c/093d9603b60093a9aaae942db56107f6432a5dca", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/161cef818545ecf980f0e2ebaf8ba7326ce53c2b", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/16222beb9f8e5ceb0beeb5cbe54bef16df501a92", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/27c3be840911b15a3f24ed623f86153c825b6b29", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/2d07fea561d64357fb7b3f3751e653bf20306d77", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/49c09ca35a5f521d7fa18caf62fdf378f15e8aa4", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/65ebdde16e7f5da99dbf8a548fb635837d78384e", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/a3b65c8cbc139bfce9541bc81c1bb766e5ba3f68", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86: stop playing stack games in profile_pc()\n\nThe 'profile_pc()' function is used for timer-based profiling, which\nisn't really all that relevant any more to begin with, but it also ends\nup making assumptions based on the stack layout that aren't necessarily\nvalid.\n\nBasically, the code tries to account the time spent in spinlocks to the\ncaller rather than the spinlock, and while I support that as a concept,\nit's not worth the code complexity or the KASAN warnings when no serious\nprofiling is done using timers anyway these days.\n\nAnd the code really does depend on stack layout that is only true in the\nsimplest of cases. We've lost the comment at some point (I think when\nthe 32-bit and 64-bit code was unified), but it used to say:\n\n\tAssume the lock function has either no stack frame or a copy\n\tof eflags from PUSHF.\n\nwhich explains why it just blindly loads a word or two straight off the\nstack pointer and then takes a minimal look at the values to just check\nif they might be eflags or the return pc:\n\n\tEflags always has bits 22 and up cleared unlike kernel addresses\n\nbut that basic stack layout assumption assumes that there isn't any lock\ndebugging etc going on that would complicate the code and cause a stack\nframe.\n\nIt causes KASAN unhappiness reported for years by syzkaller [1] and\nothers [2].\n\nWith no real practical reason for this any more, just remove the code.\n\nJust for historical interest, here's some background commits relating to\nthis code from 2006:\n\n 0cb91a229364 (\"i386: Account spinlocks to the caller during profiling for !FP kernels\")\n 31679f38d886 (\"Simplify profile_pc on x86-64\")\n\nand a code unification from 2009:\n\n ef4512882dbe (\"x86: time_32/64.c unify profile_pc\")\n\nbut the basics of this thing actually goes back to before the git tree."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86: deja de jugar juegos de pila en perfil_pc() La funci\u00f3n 'profile_pc()' se utiliza para la creaci\u00f3n de perfiles basada en temporizador, lo cual ya no es tan relevante para empezar. , pero tambi\u00e9n termina haciendo suposiciones basadas en el dise\u00f1o de la pila que no son necesariamente v\u00e1lidas. B\u00e1sicamente, el c\u00f3digo intenta contabilizar el tiempo invertido en bloqueos de giro para la persona que llama en lugar del bloqueo de giro, y si bien apoyo eso como concepto, no vale la pena la complejidad del c\u00f3digo o las advertencias de KASAN cuando de todos modos no se realiza una creaci\u00f3n de perfiles seria usando temporizadores en estos d\u00edas. . Y el c\u00f3digo realmente depende del dise\u00f1o de la pila, lo que solo es cierto en los casos m\u00e1s simples. Perdimos el comentario en alg\u00fan momento (creo que cuando se unific\u00f3 el c\u00f3digo de 32 y 64 bits), pero sol\u00eda decir: Supongamos que la funci\u00f3n de bloqueo no tiene marco de pila o tiene una copia de eflags de PUSHF. lo que explica por qu\u00e9 simplemente carga ciegamente una o dos palabras directamente desde el puntero de la pila y luego echa un vistazo m\u00ednimo a los valores para comprobar si podr\u00edan ser eflags o la PC de retorno: Eflags siempre tiene los bits 22 y superiores limpios, a diferencia de las direcciones del kernel, pero Esa suposici\u00f3n b\u00e1sica del dise\u00f1o de la pila supone que no hay ninguna depuraci\u00f3n de bloqueo, etc., que complicar\u00eda el c\u00f3digo y provocar\u00eda un marco de pila. Provoca la infelicidad de KASAN que Syzkaller [1] y otros [2] han informado durante a\u00f1os. Sin ninguna raz\u00f3n pr\u00e1ctica real para esto, simplemente elimine el c\u00f3digo. Solo por inter\u00e9s hist\u00f3rico, aqu\u00ed hay algunas confirmaciones de antecedentes relacionadas con este c\u00f3digo de 2006: 0cb91a229364 (\"i386: La cuenta se bloquea en la persona que llama durante la creaci\u00f3n de perfiles para los n\u00facleos !FP\") 31679f38d886 (\"Simplificar perfil_pc en x86-64\") y una unificaci\u00f3n de c\u00f3digo de 2009: ef4512882dbe (\"x86: time_32/64.c unify perfil_pc\") pero los conceptos b\u00e1sicos de esto en realidad se remontan a antes del \u00e1rbol git."}], "lastModified": "2024-07-30T13:33:30.653", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}