[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1612091319500.16984@cbobk.fhfr.pm>
Date: Fri, 9 Dec 2016 13:20:41 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: João Paulo Rechi Vita <jprvita@...il.com>
cc: Benjamin Tissoires <benjamin.tissoires@...hat.com>,
linux@...lessm.com,
João Paulo Rechi Vita <jprvita@...lessm.com>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i2c-hid: Disable IRQ before freeing buffers
On Tue, 6 Dec 2016, João Paulo Rechi Vita wrote:
> The HID report buffers that are initially allocated on i2c_hid_probe()
> might not be big enough to hold the HID reports from a specific device,
> in which case they will be freed and new ones will be allocated in
> i2c_hid_start(), at point which the device's report size is known. But
> at this point ihid->irq is already running, and may call
> i2c_hid_get_input() which passes ihid->inbuf to i2c_master_recv(). Since
> this handler runs in a separate thread, ihid->inbuf may be freed at this
> very moment, and i2c_master_recv() will write on memory which may be
> already owned by a different part of the kernel, corrupting its data.
>
> This problem has been observed on an Asus UX360UA laptop which has an
> I2C touchpad, and results in a complete system freeze or an unusable
> slowness with a lof of "BUG: unable to handle kernel paging request at
> <address>" warnings. Enabling SLUB debugging shows a use-after-free
> warning on memory allocated in i2c_hid_alloc_buffers() and freed in
> i2c_hid_free_buffers():
>
> =============================================================================
> BUG kmalloc-64 (Not tainted): Poison overwritten
> -----------------------------------------------------------------------------
[ ... snip ... ]
Excellent report, applied, thanks!
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists