Vulnerabilidad en kernel de Linux (CVE-2024-57914)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpci: soluciona el problema del puntero NULL en el caso de irq compartida. La función tcpci_irq() puede encontrarse con el siguiente problema de desreferencia de puntero NULL: [2.641851] No se puede gestionar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000010 [2.641951] estado 0x1, 0x37f [2.650659] Información de aborto de memoria: [2.656490] ESR = 0x0000000096000004 [2.660230] EC = 0x25: DABT (EL actual), IL = 32 bits [2.665532] SET = 0, FnV = 0 [2.668579] EA = 0, S1PTW = 0 [ 2.671715] FSC = 0x04: error de traducción de nivel 0 [ 2.676584] Información de cancelación de datos: [ 2.679459] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 2.684936] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 2.689980] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 2.695284] [0000000000000010] dirección de usuario pero active_mm es intercambiador [ 2.701632] Error interno: Oops: 0000000096000004 [#1] PREEMPT SMP [ 2.707883] Módulos vinculados en: [ 2.710936] CPU: 1 UID: 0 PID: 87 Comm: irq/111-2-0051 No contaminado 6.12.0-rc6-06316-g7f63786ad3d1-dirty #4 [ 2.720570] Nombre del hardware: Placa NXP i.MX93 11X11 EVK (DT) [ 2.726040] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.732989] pc : tcpci_irq+0x38/0x318 [ 2.736647] lr : _tcpci_irq+0x14/0x20 [ 2.740295] sp : ffff80008324bd30 [ 2.743597] x29: ffff80008324bd70 x28: ffff800080107894 x27: ffff800082198f70 [ 2.750721] x26: ffff0000050e6680 x25: ffff000004d172ac x24: ffff0000050f0000 [ 2.757845] x23: ffff000004d17200 x22: 0000000000000001 x21: ffff0000050f0000 [ 2.764969] x20: ffff000004d17200 x19: 0000000000000000 x18: 0000000000000001 [ 2.772093] x17: 0000000000000000 x16: ffff80008183d8a0 x15: ffff00007fbab040 [ 2.779217] x14: ffff00007fb918c0 x13: 0000000000000000 x12: 000000000000017a [ 2.786341] x11: 0000000000000001 x10: 0000000000000a90 x9 : ffff80008324bd00 [ 2.793465] x8 : ffff0000050f0af0 x7 : ffff00007fbaa840 x6 : 0000000000000031 [ 2.800589] x5 : 000000000000017a x4 : 0000000000000002 x3 : 0000000000000002 [ 2.807713] x2 : ffff80008324bd3a x1 : 00000000000000010 x0 : 0000000000000000 [ 2.814838] Rastreo de llamadas: [ 2.817273] tcpci_irq+0x38/0x318 [ 2.820583] _tcpci_irq+0x14/0x20 [ 2.823885] irq_thread_fn+0x2c/0xa8 [ 2.827456] irq_thread+0x16c/0x2f4 [ 2.830940] kthread+0x110/0x114 [ 2.834164] ret_from_fork+0x10/0x20 [ 2.837738] Código: f9426420 f9001fe0 d2800000 52800201 (f9400a60) Esto puede suceder en el caso de irq compartido. Por ejemplo, dos puertos Tipo-C comparten un irq. Después de que el primer puerto terminó tcpci_register_port(), puede activar la interrupción. Sin embargo, si la interrupción llega por casualidad, el segundo puerto termina devm_request_threaded_irq(), el controlador de interrupción del segundo puerto se ejecutará primero. Entonces, el problema anterior ocurre debido a que tcpci sigue siendo un puntero NULL en tcpci_irq() cuando se desreferencia a regmap. devm_request_threaded_irq() <-- port1 irq viene deshabilitar_irq(client->irq); tcpci_register_port() Esto restaurará la lógica al estado anterior a el commit (77e85107a771 "usb: typec: tcpci: support edge irq"). Sin embargo, mover tcpci_register_port() antes crea un problema cuando se usa el irq de borde porque tcpci_init() se llamará antes que devm_request_threaded_irq(). tcpci_init() escribe ALERT_MASK en el hardware para indicarle que comience a generar interrupciones, pero aún no estamos listos para lidiar con ellas, entonces los eventos ALERT pueden perderse y la línea ALERT no se recuperará al nivel alto para siempre. Para evitar el problema, esto también establecerá el registro ALERT_MASK después del retorno de devm_request_threaded_irq().