{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-04-15T13:41:12.785","vulnerabilities":[{"cve":{"id":"CVE-2023-54267","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2025-12-30T13:16:15.517","lastModified":"2025-12-31T20:42:43.210","vulnStatus":"Awaiting Analysis","cveTags":[],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc\/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT\n\nlppaca_shared_proc() takes a pointer to the lppaca which is typically\naccessed through get_lppaca().  With DEBUG_PREEMPT enabled, this leads\nto checking if preemption is enabled, for example:\n\n  BUG: using smp_processor_id() in preemptible [00000000] code: grep\/10693\n  caller is lparcfg_data+0x408\/0x19a0\n  CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2\n  Call Trace:\n    dump_stack_lvl+0x154\/0x200 (unreliable)\n    check_preemption_disabled+0x214\/0x220\n    lparcfg_data+0x408\/0x19a0\n    ...\n\nThis isn't actually a problem however, as it does not matter which\nlppaca is accessed, the shared proc state will be the same.\nvcpudispatch_stats_procfs_init() already works around this by disabling\npreemption, but the lparcfg code does not, erroring any time\n\/proc\/powerpc\/lparcfg is accessed with DEBUG_PREEMPT enabled.\n\nInstead of disabling preemption on the caller side, rework\nlppaca_shared_proc() to not take a pointer and instead directly access\nthe lppaca, bypassing any potential preemption checks.\n\n[mpe: Rework to avoid needing a definition in paca.h and lppaca.h]"},{"lang":"es","value":"En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\npowerpc\/pseries: Reestructurar lppaca_shared_proc() para evitar DEBUG_PREEMPT\n\nlppaca_shared_proc() toma un puntero al lppaca al que se accede típicamente a través de get_lppaca(). Con DEBUG_PREEMPT habilitado, esto lleva a verificar si la preemptibilidad está habilitada, por ejemplo:\n\n  BUG: usando smp_processor_id() en código preemptible [00000000]: grep\/10693\n  el llamador es lparcfg_data+0x408\/0x19a0\n  CPU: 4 PID: 10693 Comm: grep No contaminado 6.5.0-rc3 #2\n  Traza de Llamadas:\n    dump_stack_lvl+0x154\/0x200 (no fiable)\n    check_preemption_disabled+0x214\/0x220\n    lparcfg_data+0x408\/0x19a0\n    ...\n\nEsto no es realmente un problema, sin embargo, ya que no importa qué lppaca se acceda, el estado compartido del proceso será el mismo. vcpudispatch_stats_procfs_init() ya soluciona esto deshabilitando la preemptibilidad, pero el código lparcfg no lo hace, generando un error cada vez que se accede a \/proc\/powerpc\/lparcfg con DEBUG_PREEMPT habilitado.\n\nEn lugar de deshabilitar la preemptibilidad en el lado del llamador, reestructurar lppaca_shared_proc() para que no tome un puntero y en su lugar acceda directamente al lppaca, evitando cualquier posible verificación de preemptibilidad.\n\n[mpe: Reestructurar para evitar la necesidad de una definición en paca.h y lppaca.h]"}],"metrics":{},"references":[{"url":"https:\/\/git.kernel.org\/stable\/c\/2935443dc9c28499223d8c881474259e4b998f2a","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https:\/\/git.kernel.org\/stable\/c\/3c5e8e666794d7dde6d14ea846c6c04f2bb34900","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https:\/\/git.kernel.org\/stable\/c\/4c8568cf4c45b415854195c8832b557cdefba57a","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https:\/\/git.kernel.org\/stable\/c\/953c54dfdc5d3eb7243ed902b50acb5ea1db4355","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https:\/\/git.kernel.org\/stable\/c\/eac030b22ea12cdfcbb2e941c21c03964403c63f","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https:\/\/git.kernel.org\/stable\/c\/f45ee5c074013a0fbfce77a5af5efddb01f5d4f4","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}]}}]}