Message-ID: <1501791863.2047.18.camel@codethink.co.uk>
Subject: Re: [PATCH 4.4 58/83] x86/ioapic: Pass the correct data to
 unmask_ioapic_irq()
From: Ben Hutchings <ben.hutchings@codethink.co.uk>
To: Seunghun Han <kkamagui@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Thu, 03 Aug 2017 21:24:23 +0100
In-Reply-To: <20170725191717.528196938@linuxfoundation.org>
References: <20170725191708.449126292@linuxfoundation.org>
         <20170725191717.528196938@linuxfoundation.org>
Organization: Codethink Ltd.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1210
Lines: 34

On Tue, 2017-07-25 at 12:19 -0700, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Seunghun Han <kkamagui@gmail.com>
> 
> commit e708e35ba6d89ff785b225cd07dcccab04fa954a upstream.
> 
> One of the rarely executed code pathes in check_timer() calls
> unmask_ioapic_irq() passing irq_get_chip_data(0) as argument.
> 
> That's wrong as unmask_ioapic_irq() expects a pointer to the irq data of
> interrupt 0. irq_get_chip_data(0) returns NULL, so the following
> dereference in unmask_ioapic_irq() causes a kernel panic.
> 
> The issue went unnoticed in the first place because irq_get_chip_data()
> returns a void pointer so the compiler cannot do a type check on the
> argument. The code path was added for machines with broken configuration,
> but it seems that those machines are either not running current kernels or
> simply do not longer exist.
>
> Hand in irq_get_irq_data(0) as argument which provides the correct data.
[...]

This just pushes the null dereference down into io_apic_modify_irq().
Maybe unmask_ioapic_irq() shouldn't be used here at all?

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.