Vulnerabilidad en kernel de Linux (CVE-2022-49196)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries: Se corrige el uso después de liberar en remove_phb_dynamic() En remove_phb_dynamic() usamos &phb->io_resource, después de haber llamado a device_unregister(&host_bridge->dev). Pero la anulación del registro puede haber liberado a phb, porque pcibios_free_controller_deferred() es la función de liberación para host_bridge. Si no hay referencias pendientes cuando llamamos a device_unregister(), phb se liberará de nosotros. Esto ha pasado desapercibido, pero con slub_debug y page_poison habilitados puede provocar un bloqueo: PID: 7574 TAREA: c0000000d492cb80 CPU: 13 COMANDO: "drmgr" #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc #1 [c0000000e4f075d0] oops_end at c000000000029608 #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4 #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8 #4 [c0000000e4f076f0] data_access_slb_common_virt en c000000000008b30 Marco de excepción de acceso a datos SLB [380]: R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100 R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9 R6: 3894674d000000c0 R7: 0000000000000000 R8: 000000000000000ff R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000 R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000 R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003 R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005 R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0 R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8 R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800 R30: c00000004d1d2400 R31: c00000004d1d2540 PIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474 CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003 CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3 DSISR: c0000000e4f07920 Resultado de llamada al sistema: fffffffffffffff2 [NIP: release_resource+56] [LR: release_resource+48] #5 [c0000000e4f07a00] release_resource en c000000000167258 (no confiable) #6 [c0000000e4f07a30] remove_phb_dynamic en c000000000105648 #7 [c0000000e4f07ab0] dlpar_remove_slot en c0080000031a09e8 [rpadlpar_io] #8 [c0000000e4f07b50] remove_slot_store en c0080000031a0b9c [rpadlpar_io] #9 [c0000000e4f07be0] kobj_attr_store en c000000000817d8c #10 [c0000000e4f07c00] sysfs_kf_write en c00000000063e504 #11 [c0000000e4f07c20] kernfs_fop_write_iter en c00000000063d868 #12 [c0000000e4f07c70] new_sync_write en c00000000054339c #13 [c0000000e4f07d10] vfs_write en c000000000546624 #14 [c0000000e4f07d60] ksys_write en c0000000005469f4 #15 [c0000000e4f07db0] system_call_exception at c000000000030840 #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168 Para evitarlo, podemos tomar una referencia a host_bridge->dev hasta que terminemos de usar phb. Luego, cuando eliminemos la referencia, se liberará phb.