lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2024102125-CVE-2024-49927-86cf@gregkh>
Date: Mon, 21 Oct 2024 20:02:15 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2024-49927: x86/ioapic: Handle allocation failures gracefully

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

x86/ioapic: Handle allocation failures gracefully

Breno observed panics when using failslab under certain conditions during
runtime:

   can not alloc irq_pin_list (-1,0,20)
   Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed

   panic+0x4e9/0x590
   mp_irqdomain_alloc+0x9ab/0xa80
   irq_domain_alloc_irqs_locked+0x25d/0x8d0
   __irq_domain_alloc_irqs+0x80/0x110
   mp_map_pin_to_irq+0x645/0x890
   acpi_register_gsi_ioapic+0xe6/0x150
   hpet_open+0x313/0x480

That's a pointless panic which is a leftover of the historic IO/APIC code
which panic'ed during early boot when the interrupt allocation failed.

The only place which might justify panic is the PIT/HPET timer_check() code
which tries to figure out whether the timer interrupt is delivered through
the IO/APIC. But that code does not require to handle interrupt allocation
failures. If the interrupt cannot be allocated then timer delivery fails
and it either panics due to that or falls back to legacy mode.

Cure this by removing the panic wrapper around __add_pin_to_irq_node() and
making mp_irqdomain_alloc() aware of the failure condition and handle it as
any other failure in this function gracefully.

The Linux kernel CVE team has assigned CVE-2024-49927 to this issue.


Affected and fixed versions
===========================

	Fixed in 5.15.168 with commit e479cb835fee
	Fixed in 6.1.113 with commit ec862cd843fa
	Fixed in 6.6.55 with commit 077e1b7cd521
	Fixed in 6.10.14 with commit 649a5c2ffae7
	Fixed in 6.11.3 with commit f17efbeb2922
	Fixed in 6.12-rc1 with commit 830802a0fea8

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-49927
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	arch/x86/kernel/apic/io_apic.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/e479cb835feeb2abff97f25766e23b96a6eabe28
	https://git.kernel.org/stable/c/ec862cd843faa6f0e84a7a07362f2786446bf697
	https://git.kernel.org/stable/c/077e1b7cd521163ded545987bbbd389519aeed71
	https://git.kernel.org/stable/c/649a5c2ffae797ce792023a70e84c7fe4b6fb8e0
	https://git.kernel.org/stable/c/f17efbeb2922327ea01a9efa8829fea9a30e547d
	https://git.kernel.org/stable/c/830802a0fea8fb39d3dc9fb7d6b5581e1343eb1f

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ