"value":"In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/imx-irqsteer: Handle runtime power management correctly\n\nThe power domain is automatically activated from clk_prepare(). However, on\ncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes\nsleeping functions, which triggers the 'scheduling while atomic' bug in the\ncontext switch path during device probing:\n\n BUG: scheduling while atomic: kworker/u13:1/48/0x00000002\n Call trace:\n __schedule_bug+0x54/0x6c\n __schedule+0x7f0/0xa94\n schedule+0x5c/0xc4\n schedule_preempt_disabled+0x24/0x40\n __mutex_lock.constprop.0+0x2c0/0x540\n __mutex_lock_slowpath+0x14/0x20\n mutex_lock+0x48/0x54\n clk_prepare_lock+0x44/0xa0\n clk_prepare+0x20/0x44\n imx_irqsteer_resume+0x28/0xe0\n pm_generic_runtime_resume+0x2c/0x44\n __genpd_runtime_resume+0x30/0x80\n genpd_runtime_resume+0xc8/0x2c0\n __rpm_callback+0x48/0x1d8\n rpm_callback+0x6c/0x78\n rpm_resume+0x490/0x6b4\n __pm_runtime_resume+0x50/0x94\n irq_chip_pm_get+0x2c/0xa0\n __irq_do_set_handler+0x178/0x24c\n irq_set_chained_handler_and_data+0x60/0xa4\n mxc_gpio_probe+0x160/0x4b0\n\nCure this by implementing the irq_bus_lock/sync_unlock() interrupt chip\ncallbacks and handle power management in them as they are invoked from\nnon-atomic context.\n\n[ tglx: Rewrote change log, added Fixes tag ]"
"value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/imx-irqsteer: manejar correctamente la administraci\u00f3n de energ\u00eda en tiempo de ejecuci\u00f3n. El dominio de energ\u00eda se activa autom\u00e1ticamente desde clk_prepare(). Sin embargo, en ciertas plataformas como i.MX8QM e i.MX8QXP, el manejo de encendido invoca funciones de suspensi\u00f3n, lo que desencadena el error de 'programaci\u00f3n mientras es at\u00f3mico' en la ruta de cambio de contexto durante la prueba del dispositivo: ERROR: programaci\u00f3n mientras es at\u00f3mico: kworker/u13 :1/48/0x00000002 Seguimiento de llamadas: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 Schedule+0x5c/0xc4 Schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0 x20 mutex_lock+0x48/0x54 clk_prepare_lock+ 0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+ 0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0 Solucione esto implementando las devoluciones de llamada del chip de interrupci\u00f3n irq_bus_lock/sync_unlock() y maneje la administraci\u00f3n de energ\u00eda en ellos a medida que se invocan desde un contexto no at\u00f3mico. [tglx: registro de cambios reescrito, etiqueta de correcciones agregada]"