CVE-2024-49927

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/ioapic: Handle allocation failures gracefully<br /> <br /> Breno observed panics when using failslab under certain conditions during<br /> runtime:<br /> <br /> can not alloc irq_pin_list (-1,0,20)<br /> Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed<br /> <br /> panic+0x4e9/0x590<br /> mp_irqdomain_alloc+0x9ab/0xa80<br /> irq_domain_alloc_irqs_locked+0x25d/0x8d0<br /> __irq_domain_alloc_irqs+0x80/0x110<br /> mp_map_pin_to_irq+0x645/0x890<br /> acpi_register_gsi_ioapic+0xe6/0x150<br /> hpet_open+0x313/0x480<br /> <br /> That&amp;#39;s a pointless panic which is a leftover of the historic IO/APIC code<br /> which panic&amp;#39;ed during early boot when the interrupt allocation failed.<br /> <br /> The only place which might justify panic is the PIT/HPET timer_check() code<br /> which tries to figure out whether the timer interrupt is delivered through<br /> the IO/APIC. But that code does not require to handle interrupt allocation<br /> failures. If the interrupt cannot be allocated then timer delivery fails<br /> and it either panics due to that or falls back to legacy mode.<br /> <br /> Cure this by removing the panic wrapper around __add_pin_to_irq_node() and<br /> making mp_irqdomain_alloc() aware of the failure condition and handle it as<br /> any other failure in this function gracefully.