* Re: [PATCH] Input: i8042 - replace strlcat() with seq_buf and scnprintf()
From: Dmitry Torokhov @ 2026-07-11 22:51 UTC (permalink / raw)
To: Ian Bridges; +Cc: linux-input, linux-kernel, linux-hardening
In-Reply-To: <akyW4xkvCCROM0SE@dev>
On Tue, Jul 07, 2026 at 01:04:19AM -0500, Ian Bridges wrote:
> In preparation for removing the strlcat() API[1], replace its uses in
> i8042-acpipnpio.h.
>
> i8042_pnp_id_to_string() accumulates a variable number of PNP ids in
> a loop, which is what seq_buf is for. The kbd and aux probe functions
> build a name from at most three parts that are all known up front, so
> the whole construction becomes a single scnprintf() there.
>
> Link: https://github.com/KSPP/linux/issues/370 [1]
> Signed-off-by: Ian Bridges <icb@fastmail.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [git pull] Input updates for v7.2-rc2
From: pr-tracker-bot @ 2026-07-11 22:48 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Linus Torvalds, linux-kernel, linux-input
In-Reply-To: <alLFtWOLPlPPPQEn@google.com>
The pull request you sent on Sat, 11 Jul 2026 15:37:44 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v7.2-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/44696aa3a489d2baf58efa61b37833f100072bee
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH] Input: joydev - replace ev_match boolean with goto for early exit
From: Dmitry Torokhov @ 2026-07-11 22:47 UTC (permalink / raw)
To: linux-input, linux-kernel
In-Reply-To: <ak8hKSa9HNYPoOZZ@thesun>
Hi Ashton,
On Thu, Jul 09, 2026 at 04:18:49PM +1200, Ashton Warner wrote:
> The joydev_dev_is_absolute_mouse runs unnecessary Event type checks to
> determine whether a joydev device is an absolute mouse. Change ev_match
> to a goto statement to exit early.
>
> Signed-off-by: Ashton Warner <drflamemontgomery@gmail.com>
I think this is one of the cases where I'd avoid using goto. The extra
computation is not in hot path and will be unnoticeable.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: fix bracket
From: Dmitry Torokhov @ 2026-07-11 22:38 UTC (permalink / raw)
To: Manuel Ebner
Cc: Hugo Villeneuve, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260710090153.431170-2-manuelebner@mailbox.org>
On Fri, Jul 10, 2026 at 11:01:53AM +0200, Manuel Ebner wrote:
> Add missing '('.
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [git pull] Input updates for v7.2-rc2
From: Dmitry Torokhov @ 2026-07-11 22:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v7.2-rc2
to receive updates for the input subsystem. You will get:
- A fix for MELFAS MMS114 touchscreen driver to reject invalid touch IDs
and avoid multi-touch slot corruption
- A fix for a crash in Sega Dreamcast (Maple) mouse driver when opening
the device, caused by missing driver data
- Fixes for Maple drivers (keyboard, mouse, joystick) to properly order
setting driver data and device registration to avoid races.
Changelog:
---------
Dmitry Torokhov (4):
Input: maplemouse - set driver data before registering input device
Input: maplecontrol - set driver data before registering input device
Input: maple_keyb - set driver data before registering input device
Input: mms114 - fix multi-touch slot corruption
Florian Fuchs (1):
Input: maplemouse - fix NULL pointer dereference in open()
Diffstat:
--------
drivers/input/joystick/maplecontrol.c | 3 ++-
drivers/input/keyboard/maple_keyb.c | 4 ++--
drivers/input/mouse/maplemouse.c | 9 ++++++---
drivers/input/touchscreen/mms114.c | 2 +-
4 files changed, 11 insertions(+), 7 deletions(-)
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] iio: temperature: hid-sensor-temperature: switch to non-devm iio_device_register()
From: Jonathan Cameron @ 2026-07-11 22:30 UTC (permalink / raw)
To: srinivas pandruvada
Cc: Sanjay Chitroda, jikos, dlechner, nuno.sa, andy, hongyan.song,
linux-input, linux-iio, linux-kernel
In-Reply-To: <086180fe0da41a5e8ce1b130483996a366f588ea.camel@linux.intel.com>
On Wed, 08 Jul 2026 16:25:41 -0700
srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
> On Thu, 2026-06-25 at 17:46 +0530, Sanjay Chitroda wrote:
> > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> >
> > Avoid using devm_iio_device_register(), as this driver requires
> > explicit
> > error handling and teardown ordering.
> >
> > With devm_iio_device_register(), IIO device remains registered until
> > the
> > devres cleanup phase. However, driver's remove() callback removes the
> > sensor hub callback and trigger support. This can create a race
> > window
> > where IIO device is still visible and read_raw() requests are issued.
> > These requests might call sensor_hub_input_attr_get_raw_value(),
> > which
> > waits up to 5 seconds for a response from the sensor hub callback
> > that
> > has already been removed.
> >
> > Add an explicit iio_device_unregister() call in the teardown path to
> > ensure deterministic cleanup, so that userspace can no longer access
> > the
> > device once backend resources begin to be dismantled.
> >
> > Fixes: 59d0f2da3569 ("iio: hid: Add temperature sensor support")
> > Cc: stable@vger.kernel.org
> > Reviewed-by: Maxwell Doose <m32285159@gmail.com>
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> > Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> >
>
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Applied to the fixes-togreg branch of iio.git.
Note that to take anything non fix related on top of this will require
me waiting until this is upstream. I'm not sure how many fixes
I'll have outstanding (and so if I will soon reach critical mass)
but most likely that will be at least a few weeks at least.
Thanks
Jonathan
>
> > ---
> > Changes in v2:
> > - Added review tags of Maxwell and Andy along with stable Cc
> > - Based on input from Srinivas and investigation use-after-free
> > explanation was not sufficiently justified so updated the commit
> > message with appropriate information and kept Fixes tag
> > - Link to v1:
> > https://lore.kernel.org/all/20260622052135.1804135-1-sanjayembedded@gmail.com
> > ---
> > drivers/iio/temperature/hid-sensor-temperature.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/temperature/hid-sensor-temperature.c
> > b/drivers/iio/temperature/hid-sensor-temperature.c
> > index a8d3a15f9c53..ab6ec8f659b8 100644
> > --- a/drivers/iio/temperature/hid-sensor-temperature.c
> > +++ b/drivers/iio/temperature/hid-sensor-temperature.c
> > @@ -244,7 +244,7 @@ static int hid_temperature_probe(struct
> > platform_device *pdev)
> > if (ret)
> > goto error_remove_trigger;
> >
> > - ret = devm_iio_device_register(indio_dev->dev.parent,
> > indio_dev);
> > + ret = iio_device_register(indio_dev);
> > if (ret)
> > goto error_remove_callback;
> >
> > @@ -264,6 +264,7 @@ static void hid_temperature_remove(struct
> > platform_device *pdev)
> > struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> > struct temperature_state *temp_st = iio_priv(indio_dev);
> >
> > + iio_device_unregister(indio_dev);
> > sensor_hub_remove_callback(hsdev,
> > HID_USAGE_SENSOR_TEMPERATURE);
> > hid_sensor_remove_trigger(indio_dev, &temp_st-
> > >common_attributes);
> > }
^ permalink raw reply
* Re: [PATCH v5 1/3] Input: applespi - cancel pending work on driver remove
From: Dmitry Torokhov @ 2026-07-11 21:55 UTC (permalink / raw)
To: Shih-Yuan Lee, Ronald Tschalär
Cc: Mark Brown, linux-input, linux-spi, linux-kernel
In-Reply-To: <20260711131140.18777-2-fourdollars@debian.org>
Hi Shih-Yuan,
On Sat, Jul 11, 2026 at 09:11:38PM +0800, Shih-Yuan Lee wrote:
> During driver removal in applespi_remove(), the managed private data
> structure is freed by devres. However, the driver does not cancel the
> asynchronous work applespi->work, which registers the touchpad input
> device.
>
> This creates a use-after-free (UAF) vulnerability if a pending or
> running worker thread attempts to access the private data after the
> remove function returns.
>
> Fix this by explicitly calling cancel_work_sync(&applespi->work) in
> applespi_remove() before cleanups.
>
> Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
> ---
> drivers/input/keyboard/applespi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
> index b5ff71cd5a70..3bdb9e7cfb8b 100644
> --- a/drivers/input/keyboard/applespi.c
> +++ b/drivers/input/keyboard/applespi.c
> @@ -1822,6 +1822,8 @@ static void applespi_remove(struct spi_device *spi)
>
> applespi_drain_reads(applespi);
>
> + cancel_work_sync(&applespi->work);
> +
> debugfs_remove_recursive(applespi->debugfs_root);
> }
For this, and the next one, the issue is that the touchpad discovery is
asynchronous. I wonder if making touchpad detection synchronous and
making the entire driver as PROBE_PREFER_ASYNCHRONOUS would not make it
simpler and more robust.
It looks like Ronald tried to do that in [1] but unfortunately it was
dropped on the floor (my fault :( ). Maybe you can try it out and
freshen it?
Thanks.
--
Dmitry
[1] https://lore.kernel.org/all/20190721070523.24695-1-ronald@innovation.ch/
^ permalink raw reply
* RE: [PATCH 0/2] HID: hyperv: bound initial device info descriptor
From: Michael Kelley @ 2026-07-11 18:06 UTC (permalink / raw)
To: Michael Bommarito, Jiri Kosina, Benjamin Tissoires,
kys@microsoft.com, Haiyang Zhang, Wei Liu
Cc: Dexuan Cui, Long Li, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <20260710022854.3739558-1-michael.bommarito@gmail.com>
From: Michael Bommarito <michael.bommarito@gmail.com> Sent: Thursday, July 9, 2026 7:29 PM
>
> A malicious Hyper-V host or backend can crash a guest with a short
> SYNTH_HID_INITIAL_DEVICE_INFO message. mousevsc_on_receive_device_info()
> trusts the HID descriptor bLength and wDescriptorLength without checking
> that the received VMBus packet actually contains both byte ranges, so a
> truncated packet with an oversized report-descriptor length makes the
> guest read past the received packet while copying the descriptor. This
> matters most for a confidential guest, where the host is outside the trust
> boundary.
For some additional background on the assumed threat model that
underlies this kind of validation (and lack thereof), see [1]. This Hyper-V
mouse driver has .allowed_in_isolated set to "false", so it is never loaded
in a CoCo VM. In normal VMs, the threat model says that we trust the
Hyper-V host not to provide bad values.
But as I said in [1], I'm good with taking additional validations. But Wei
Liu as the maintainer for the Hyper-V drivers is the person who should
decide whether we want to take additional validations.
If we take these additional validations, there's a separate question of
whether to backport them to stable kernels. I'm inclined to *not*
backport to avoid introducing churn (and the risk of breaking something)
when it isn't fixing an observed or likely-to-happen problem. But Wei Liu
should probably weigh in on that as well.
[1] https://lore.kernel.org/linux-hyperv/SN6PR02MB4157D595B990A321BFA85B40D4002@SN6PR02MB4157.namprd02.prod.outlook.com/
Michael
>
> Patch 1 passes the received initial-device-info size into the parser and
> rejects descriptor lengths that exceed the packet. Patch 2 adds
> same-translation-unit KUnit coverage: a well-formed message that must
> still parse and the truncated/oversized message that must now be rejected.
>
> Reproduced with the KUnit/KASAN test: stock reads past the packet on the
> short message after the benign control passes; patched rejects it and both
> cases pass.
>
> Cc: stable@vger.kernel.org
>
> Michael Bommarito (2):
> HID: hyperv: validate initial device info bounds
> HID: hyperv: add KUnit coverage for device info bounds
>
> drivers/hid/Kconfig | 10 +++
> drivers/hid/hid-hyperv.c | 144 ++++++++++++++++++++++++++++++++++++---
> 2 files changed, 144 insertions(+), 10 deletions(-)
>
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH v2 00/10] treewide: replace linux/gpio.h
From: Linus Walleij @ 2026-07-11 15:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Bartosz Golaszewski, Arnd Bergmann, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260710211954.1373336-1-arnd@kernel.org>
On Fri, Jul 10, 2026 at 11:20 PM Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
The series:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] HID: multitouch: reclassify HTIX5288 to WIN_8_FORCE_MULTI_INPUT_NSMU
From: Xianglin Lin @ 2026-07-11 14:22 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input, Xianglin Lin
Commit b5e65ae557da ("HID: multitouch: Add quirk for Hantick 5288
touchpad") assigned MT_CLS_NSMU to the HTIX5288 (0911:5288). This was
necessary because the device sometimes fails to send touch release
signals when transitioning from >=2 fingers to <2 fingers, and
MT_QUIRK_NOT_SEEN_MEANS_UP fixes stuck touches by treating missing
contacts as released.
However, MT_CLS_NSMU only carries MT_QUIRK_NOT_SEEN_MEANS_UP. It
lacks MT_QUIRK_CONTACT_CNT_ACCURATE and MT_QUIRK_IGNORE_DUPLICATES.
As a result, after a two-finger scroll finger lift, the device still
reports stale coordinates from the released contact in subsequent
frames, and the driver overwrites the remaining active slot with
those frozen coordinates. The remaining finger appears stuck at the
lift position until all fingers are lifted.
This was confirmed via evtest on Arch Linux 7.1.3: after
TRACKING_ID=-1 for the released slot, every subsequent frame contained
duplicate position pairs -- the real moving finger's coordinates
followed by the lifted finger's frozen position, both attributed to
the active slot.
Reclassify the device to MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU
(0x0018), which preserves the original MT_QUIRK_NOT_SEEN_MEANS_UP
fix while adding the necessary Win8 quirks (CONTACT_CNT_ACCURATE,
IGNORE_DUPLICATES), preventing stale coordinate contamination.
The additional FORCE_MULTI_INPUT flag is harmless here: it separates
the mouse and touchpad collections into distinct input devices,
which is the standard behavior libinput already expects.
Fixes: b5e65ae557da ("HID: multitouch: Add quirk for Hantick 5288 touchpad")
Signed-off-by: Xianglin Lin <1021538027@qq.com>
---
drivers/hid/hid-multitouch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -2722,7 +2722,7 @@ static const struct hid_device_id mt_devices[] = {
HID_ANY_ID) },
/* Hantick */
- { .driver_data = MT_CLS_NSMU,
+ { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU,
HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
I2C_VENDOR_ID_HANTICK, I2C_PRODUCT_ID_HANTICK_5288) },
--
2.55.0
^ permalink raw reply
* Re: [PATCH v5 2/3] Input: applespi - fix NULL pointer dereference in tp_dim open
From: sashiko-bot @ 2026-07-11 13:26 UTC (permalink / raw)
To: Shih-Yuan Lee; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260711131140.18777-3-fourdollars@debian.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unsolicited or repeated PACKET_DEV_INFO messages cause multiple touchpad input devices to be allocated and registered, leaking previously registered ones.
--
--- Patch [2]: [PATCH v5 2/3] Input: applespi - fix NULL pointer dereference in tp_dim open ---
commit 083469b928bf6d69e48361fe4f8c93f87f2a7820
Author: Shih-Yuan Lee <fourdollars@debian.org>
Input: applespi - fix NULL pointer dereference in tp_dim open
The tp_dim debugfs file is registered synchronously during driver probe
in applespi_probe(). However, the applespi->touchpad_input_dev is
initialized and registered asynchronously in the driver's worker thread.
> diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
> index 3bdb9e7cfb8b2..4d339445e9c71 100644
> --- a/drivers/input/keyboard/applespi.c
> +++ b/drivers/input/keyboard/applespi.c
> @@ -963,12 +963,18 @@ static void applespi_debug_update_dimensions(struct applespi_data *applespi,
> static int applespi_tp_dim_open(struct inode *inode, struct file *file)
> {
> struct applespi_data *applespi = inode->i_private;
> + struct input_dev *touchpad;
>
> file->private_data = applespi;
>
> + /* Pairs with smp_store_release in applespi_register_touchpad_device() */
> + touchpad = smp_load_acquire(&applespi->touchpad_input_dev);
[Severity: High]
This isn't a bug introduced by this patch, but looking at the worker
thread that sets applespi->touchpad_input_dev, is there a resource leak
if the hardware sends repeated PACKET_DEV_INFO messages?
In applespi_handle_cmd_response(), work is unconditionally scheduled
whenever a PACKET_DEV_INFO packet is received:
drivers/input/keyboard/applespi.c:applespi_handle_cmd_response() {
...
if (packet->device == PACKET_DEV_INFO &&
le16_to_cpu(message->type) == 0x1020) {
/*
* We're not allowed to sleep here, but registering an input
* device can sleep.
*/
applespi->rcvd_tp_info = message->tp_info;
schedule_work(&applespi->work);
return;
}
...
}
When the worker runs applespi_register_touchpad_device(), it unconditionally
allocates and registers a new input device via devm_input_allocate_device()
and input_register_device(), overwriting the applespi->touchpad_input_dev
pointer.
Because the allocated device is devm managed, the old device and its associated
character device minor numbers are never unregistered or freed until the SPI
driver unbinds. Does this code need to check if the touchpad device is already
initialized before allocating and registering a new one to prevent exhausting
system memory?
> + if (!touchpad)
> + return -ENODEV;
> +
> snprintf(applespi->tp_dim_val, sizeof(applespi->tp_dim_val),
> "0x%.4x %dx%d+%u+%u\n",
> - applespi->touchpad_input_dev->id.product,
> + touchpad->id.product,
> applespi->tp_dim_min_x, applespi->tp_dim_min_y,
> applespi->tp_dim_max_x - applespi->tp_dim_min_x,
> applespi->tp_dim_max_y - applespi->tp_dim_min_y);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260711131140.18777-1-fourdollars@debian.org?part=2
^ permalink raw reply
* Re: [PATCH v5 1/3] Input: applespi - cancel pending work on driver remove
From: sashiko-bot @ 2026-07-11 13:26 UTC (permalink / raw)
To: Shih-Yuan Lee; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260711131140.18777-2-fourdollars@debian.org>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
Pre-existing issues:
- [High] Repeated PACKET_DEV_INFO packets lead to unbounded devm memory leaks and duplicate input device registrations.
- [High] Unchecked access of asynchronously allocated applespi->touchpad_input_dev in the debugfs tp_dim open handler.
- [High] Unbound wait in applespi_drain_writes() can block driver unbind and suspend forever if hardware is unresponsive.
- [High] Missing async teardown in applespi_probe error path if GPE enablement fails.
- [High] Mismatched finger data reported to input subsystem due to flawed iteration logic.
- [Low] Redundant manual assignment of dev.parent on input devices allocated with devm_input_allocate_device().
--
--- Patch [1]: [PATCH v5 1/3] Input: applespi - cancel pending work on driver remove ---
commit 541134ed7dfbfee9d31126ce14257c1f72d8e7a7
Author: Shih-Yuan Lee <fourdollars@debian.org>
Input: applespi - cancel pending work on driver remove
During driver removal in applespi_remove(), the managed private data
structure is freed by devres. However, the driver does not cancel the
asynchronous work applespi->work, which registers the touchpad input
device.
> diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
> --- a/drivers/input/keyboard/applespi.c
> +++ b/drivers/input/keyboard/applespi.c
> @@ -1820,8 +1820,10 @@ static void applespi_remove(struct spi_device *spi)
> {
> struct applespi_data *applespi = spi_get_drvdata(spi);
>
> applespi_drain_writes(applespi);
[Severity: High]
This isn't a bug introduced by this patch, but can this wait indefinitely
and block driver unbind or system suspend?
applespi_drain_writes() waits for the hardware without a timeout:
drivers/input/keyboard/applespi.c:applespi_drain_writes() {
...
wait_event_lock_irq(applespi->drain_complete, !applespi->write_active,
applespi->cmd_msg_lock);
...
}
If the external hardware hangs and write_active remains true, would this
task become blocked forever?
>
> acpi_disable_gpe(NULL, applespi->gpe);
> acpi_remove_gpe_handler(NULL, applespi->gpe, applespi_notify);
> device_wakeup_disable(&spi->dev);
>
> applespi_drain_reads(applespi);
>
> + cancel_work_sync(&applespi->work);
> +
> debugfs_remove_recursive(applespi->debugfs_root);
> }
[Severity: Low]
This isn't a bug introduced by this patch, but does this code redundantly
assign the parent device?
drivers/input/keyboard/applespi.c:applespi_register_touchpad_device() {
...
touchpad_input_dev = devm_input_allocate_device(&applespi->spi->dev);
...
touchpad_input_dev->dev.parent = &applespi->spi->dev;
...
}
And similarly in applespi_probe():
drivers/input/keyboard/applespi.c:applespi_probe() {
...
applespi->keyboard_input_dev->dev.parent = &spi->dev;
...
}
The input subsystem guidelines state that devm_input_allocate_device()
automatically sets the parent, making manual assignment redundant.
[Severity: High]
This isn't a bug introduced by this patch, but can a repeated
PACKET_DEV_INFO from the hardware cause an unbounded memory leak and
duplicate device registrations?
drivers/input/keyboard/applespi.c:applespi_handle_cmd_response() {
...
if (packet->type == PACKET_DEV_INFO) {
...
schedule_work(&applespi->work);
}
...
}
When the work runs, it executes applespi_register_touchpad_device(),
which unconditionally allocates a new managed device:
drivers/input/keyboard/applespi.c:applespi_register_touchpad_device() {
...
touchpad_input_dev = devm_input_allocate_device(&applespi->spi->dev);
...
error = input_register_device(touchpad_input_dev);
...
}
If the peripheral sends multiple PACKET_DEV_INFO packets, would this
blindly allocate and register multiple touchpad devices without checking
if one already exists?
[Severity: High]
This isn't a bug introduced by this patch, but could this dereference a
NULL pointer if the async worker hasn't completed initializing the
touchpad?
drivers/input/keyboard/applespi.c:applespi_probe() {
...
debugfs_create_file("tp_dim", 0400, applespi->debugfs_root, applespi,
&applespi_tp_dim_fops);
...
}
If userspace opens this file before applespi_register_touchpad_device()
is finished by the workqueue, applespi_tp_dim_open() is called:
drivers/input/keyboard/applespi.c:applespi_tp_dim_open() {
...
applespi->touchpad_input_dev->id.product,
...
}
Since touchpad_input_dev might still be NULL, will this crash the kernel?
[Severity: High]
This isn't a bug introduced by this patch, but does the probe error path
miss cleaning up async tasks and SPI reads?
drivers/input/keyboard/applespi.c:applespi_probe() {
...
acpi_sts = acpi_enable_gpe(NULL, applespi->gpe);
if (ACPI_FAILURE(acpi_sts)) {
dev_err(&spi->dev, "failed to enable GPE\n");
return -ENODEV;
}
...
}
If acpi_install_gpe_handler() (called earlier) receives an interrupt
before acpi_enable_gpe() fails, it could queue an async SPI transfer or
work item. Returning -ENODEV immediately frees the applespi structure
without calling applespi_drain_reads() or cancel_work_sync(), which
could result in a use-after-free.
[Severity: High]
This isn't a bug introduced by this patch, but does this iteration logic
mismatch the finger data reported to the input subsystem?
drivers/input/keyboard/applespi.c:report_tp_state() {
...
report_finger_data(input, applespi->slots[i], &applespi->pos[i],
&t->fingers[i]);
...
}
If earlier loops filter out fingers (e.g., touch_major == 0) and store
their coordinates densely in applespi->pos, reusing the same sequential
index i for t->fingers[i] could pair the packed positions with the
wrong original finger data from the hardware. Could this corrupt
multitouch reporting?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260711131140.18777-1-fourdollars@debian.org?part=1
^ permalink raw reply
* [PATCH v5 3/3] spi: pxa2xx: disable DMA for Apple MacBook8,1
From: Shih-Yuan Lee @ 2026-07-11 13:11 UTC (permalink / raw)
To: Dmitry Torokhov, Mark Brown
Cc: linux-input, linux-spi, linux-kernel, Shih-Yuan Lee
In-Reply-To: <20260711131140.18777-1-fourdollars@debian.org>
On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller's DMA
handshake and interrupt routing frequently fail or time out on boot,
causing the keyboard and trackpad to become unresponsive.
Avoid this architectural bug by disabling DMA and forcing the SPI
controller to use PIO mode. Move this platform/motherboard-level quirk
to the SPI host controller driver (spi-pxa2xx-pci.c) where LPSS setup
occurs, preventing layering violations, TOCTOU races, or execute-after-free
bugs in the client driver.
Additionally, introduce a `force_pio` module parameter in the PCI
host controller driver to allow other users to force PIO mode for
debugging.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=108331
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/spi/spi-pxa2xx-pci.c | 35 +++++++++++++++++++++++++++++++++--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index cae77ac18520..31bdaa096d9e 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -18,9 +18,14 @@
#include <linux/dmaengine.h>
#include <linux/platform_data/dma-dw.h>
+#include <linux/dmi.h>
#include "spi-pxa2xx.h"
+static bool spi_pxa2xx_force_pio;
+module_param_named(force_pio, spi_pxa2xx_force_pio, bool, 0444);
+MODULE_PARM_DESC(force_pio, "Force PIO mode (disables DMA) for SPI transfers. ([0] = disabled, 1 = enabled)");
+
#define PCI_DEVICE_ID_INTEL_QUARK_X1000 0x0935
#define PCI_DEVICE_ID_INTEL_BYT 0x0f0e
#define PCI_DEVICE_ID_INTEL_MRFLD 0x1194
@@ -93,6 +98,32 @@ static void lpss_dma_put_device(void *dma_dev)
pci_dev_put(dma_dev);
}
+static const struct dmi_system_id pxa2xx_spi_pci_dmi_table[] = {
+ {
+ .ident = "Apple MacBook8,1",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBook8,1"),
+ },
+ },
+ { }
+};
+
+static bool pxa2xx_spi_pci_can_dma(struct pci_dev *dev)
+{
+ if (spi_pxa2xx_force_pio) {
+ pci_info(dev, "Forcing PIO mode (disabling DMA)\n");
+ return false;
+ }
+
+ if (dmi_check_system(pxa2xx_spi_pci_dmi_table)) {
+ pci_info(dev, "MacBook8,1 detected: disabling DMA to force PIO mode\n");
+ return false;
+ }
+
+ return true;
+}
+
static int lpss_spi_setup(struct pci_dev *dev, struct pxa2xx_spi_controller *c)
{
struct ssp_device *ssp = &c->ssp;
@@ -166,7 +197,7 @@ static int lpss_spi_setup(struct pci_dev *dev, struct pxa2xx_spi_controller *c)
c->dma_filter = lpss_dma_filter;
c->dma_burst_size = 1;
- c->enable_dma = 1;
+ c->enable_dma = pxa2xx_spi_pci_can_dma(dev);
return 0;
}
@@ -238,7 +269,7 @@ static int mrfld_spi_setup(struct pci_dev *dev, struct pxa2xx_spi_controller *c)
c->dma_filter = lpss_dma_filter;
c->dma_burst_size = 8;
- c->enable_dma = 1;
+ c->enable_dma = pxa2xx_spi_pci_can_dma(dev);
return 0;
}
--
2.39.5
^ permalink raw reply related
* [PATCH v5 2/3] Input: applespi - fix NULL pointer dereference in tp_dim open
From: Shih-Yuan Lee @ 2026-07-11 13:11 UTC (permalink / raw)
To: Dmitry Torokhov, Mark Brown
Cc: linux-input, linux-spi, linux-kernel, Shih-Yuan Lee
In-Reply-To: <20260711131140.18777-1-fourdollars@debian.org>
The tp_dim debugfs file is registered synchronously during driver probe
in applespi_probe(). However, the applespi->touchpad_input_dev is
initialized and registered asynchronously in the driver's worker thread.
If a userspace process opens the debugfs file before the worker thread
has completed initialization, applespi_tp_dim_open() will dereference
the NULL applespi->touchpad_input_dev pointer, causing a kernel panic.
Fix this by using smp_load_acquire() to safely load touchpad_input_dev
and return -ENODEV if it is not yet initialized.
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/input/keyboard/applespi.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
index 3bdb9e7cfb8b..4d339445e9c7 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -963,12 +963,18 @@ static void applespi_debug_update_dimensions(struct applespi_data *applespi,
static int applespi_tp_dim_open(struct inode *inode, struct file *file)
{
struct applespi_data *applespi = inode->i_private;
+ struct input_dev *touchpad;
file->private_data = applespi;
+ /* Pairs with smp_store_release in applespi_register_touchpad_device() */
+ touchpad = smp_load_acquire(&applespi->touchpad_input_dev);
+ if (!touchpad)
+ return -ENODEV;
+
snprintf(applespi->tp_dim_val, sizeof(applespi->tp_dim_val),
"0x%.4x %dx%d+%u+%u\n",
- applespi->touchpad_input_dev->id.product,
+ touchpad->id.product,
applespi->tp_dim_min_x, applespi->tp_dim_min_y,
applespi->tp_dim_max_x - applespi->tp_dim_min_x,
applespi->tp_dim_max_y - applespi->tp_dim_min_y);
--
2.39.5
^ permalink raw reply related
* [PATCH v5 1/3] Input: applespi - cancel pending work on driver remove
From: Shih-Yuan Lee @ 2026-07-11 13:11 UTC (permalink / raw)
To: Dmitry Torokhov, Mark Brown
Cc: linux-input, linux-spi, linux-kernel, Shih-Yuan Lee
In-Reply-To: <20260711131140.18777-1-fourdollars@debian.org>
During driver removal in applespi_remove(), the managed private data
structure is freed by devres. However, the driver does not cancel the
asynchronous work applespi->work, which registers the touchpad input
device.
This creates a use-after-free (UAF) vulnerability if a pending or
running worker thread attempts to access the private data after the
remove function returns.
Fix this by explicitly calling cancel_work_sync(&applespi->work) in
applespi_remove() before cleanups.
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/input/keyboard/applespi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
index b5ff71cd5a70..3bdb9e7cfb8b 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -1822,6 +1822,8 @@ static void applespi_remove(struct spi_device *spi)
applespi_drain_reads(applespi);
+ cancel_work_sync(&applespi->work);
+
debugfs_remove_recursive(applespi->debugfs_root);
}
--
2.39.5
^ permalink raw reply related
* [PATCH v5 0/3] Input/SPI: fixes for MacBook8,1 DMA timeout, UAF, and NULL pointer dereference
From: Shih-Yuan Lee @ 2026-07-11 13:11 UTC (permalink / raw)
To: Dmitry Torokhov, Mark Brown
Cc: linux-input, linux-spi, linux-kernel, Shih-Yuan Lee
In-Reply-To: <20260711055247.5412-1-fourdollars@debian.org>
Hi Dmitry, Mark, and the linux-input/linux-spi community,
This patch series addresses a long-standing DMA initialization timeout on the
early 2015 12" MacBook (MacBook8,1) on any boot (including cold boot), as well
as two pre-existing, high-severity UAF/NULL-pointer bugs in the applespi driver.
Changes in v5:
- Updated both `lpss_spi_setup()` and `mrfld_spi_setup()` in `spi-pxa2xx-pci.c`
to consistently respect the `force_pio` module parameter across all supported
PCI devices (avoiding hardcoded DMA enable on Merrifield systems).
Changes in v4:
- Reverted the runtime `can_dma` callback override from `applespi.c` to avoid
architectural layering violation, data races (TOCTOU) with concurrent SPI
transfers, and execute-after-free vulnerability upon module unload.
- Moved the DMI quirk forcing PIO mode for MacBook8,1 to the host PCI glue
driver (spi-pxa2xx-pci.c) where LPSS setup occurs.
- Formatted the DMI match using a structured `pxa2xx_spi_pci_dmi_table` and
helper function `pxa2xx_spi_pci_can_dma()`.
- Added a `force_pio` module parameter in spi-pxa2xx-pci.c to allow other
users to manually force PIO mode for debugging.
Changes in v3:
- Added a `force_pio` module parameter to applespi to allow users to manually
disable DMA for SPI transfers.
- Resolved the execute-after-free vulnerability by unconditionally restoring
the original can_dma callback (even if NULL) in the driver remove path.
- Fixed the probe timing issue by applying the can_dma override at the very
beginning of applespi_probe() so that all early initialization transfers
safely use PIO mode, and properly restoring it in all probe error paths.
- Documented the Bugzilla link in the commit message of Patch 1.
Changes in v2:
- Fixed an unbind/remove execute-after-free vulnerability by storing and
restoring the host controller's original can_dma callback in applespi_probe()
and applespi_remove().
- Split the fixes into a 3-patch logical series.
Patch 1 fixes a pre-existing UAF vulnerability in the driver unbind path by
explicitly calling cancel_work_sync() on the asynchronous registration worker
work struct before devres frees the driver private data.
Patch 2 fixes a pre-existing race condition in the debugfs interface where
userspace could open the tp_dim file before the asynchronous worker has
finished initializing applespi->touchpad_input_dev, leading to a NULL
pointer dereference. We resolve this using smp_load_acquire() and checking
for NULL.
Patch 3 introduces a structured DMI quirk and a `force_pio` module parameter
in spi-pxa2xx-pci.c to disable DMA on MacBook8,1. This forces the controller
to use the rock-solid PIO mode from the very beginning.
Best regards,
Shih-Yuan Lee
Shih-Yuan Lee (3):
Input: applespi - cancel pending work on driver remove
Input: applespi - fix NULL pointer dereference in tp_dim open
spi: pxa2xx: disable DMA for Apple MacBook8,1
drivers/input/keyboard/applespi.c | 10 ++++++++-
drivers/spi/spi-pxa2xx-pci.c | 35 +++++++++++++++++++++++++++++--
2 files changed, 42 insertions(+), 3 deletions(-)
--
2.39.5
^ permalink raw reply
* Re: [PATCH v2 06/10] ASoC: replace linux/gpio.h inclusions
From: Charles Keepax @ 2026-07-11 12:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Linus Walleij, Bartosz Golaszewski, Arnd Bergmann,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement, Frank Li,
Robert Jarzmik, Krzysztof Kozlowski, Greg Ungerer,
Thomas Bogendoerfer, Hauke Mehrtens, Rafał Miłecki,
Yoshinori Sato, John Paul Adrian Glaubitz, Dmitry Torokhov,
Dominik Brodowski, linux-kernel, linux-arm-kernel,
linux-samsung-soc, patches, linux-m68k, linux-mips, linux-sh,
linux-input, linux-sunxi, linux-phy, linux-rockchip, linux-sound,
Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-7-arnd@kernel.org>
On Fri, Jul 10, 2026 at 11:19:51PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h is going away,s o use linux/gpio/consumer.h instead.
>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> sound/soc/codecs/cs42l84.c | 1 -
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH v2 05/10] mfd: replace linux/gpio.h inclusions
From: Charles Keepax @ 2026-07-11 12:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Linus Walleij, Bartosz Golaszewski, Arnd Bergmann,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement, Frank Li,
Robert Jarzmik, Krzysztof Kozlowski, Greg Ungerer,
Thomas Bogendoerfer, Hauke Mehrtens, Rafał Miłecki,
Yoshinori Sato, John Paul Adrian Glaubitz, Dmitry Torokhov,
Dominik Brodowski, linux-kernel, linux-arm-kernel,
linux-samsung-soc, patches, linux-m68k, linux-mips, linux-sh,
linux-input, linux-sunxi, linux-phy, linux-rockchip, linux-sound,
Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-6-arnd@kernel.org>
On Fri, Jul 10, 2026 at 11:19:50PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.
>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/mfd/arizona-irq.c | 2 +-
> drivers/mfd/wm8994-irq.c | 2 +-
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH v4 1/3] Input: applespi - cancel pending work on driver remove
From: sashiko-bot @ 2026-07-11 12:05 UTC (permalink / raw)
To: Shih-Yuan Lee; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260711114937.16670-2-fourdollars@debian.org>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Multiple processing of `PACKET_DEV_INFO` causes the driver to unconditionally allocate and register multiple touchpad devices, leaking previously allocated devm resources.
- [High] Potential use-after-free of `applespi->gpe` in `applespi_async_read_complete()` due to premature driver unbind.
- [High] Dereferencing `applespi->touchpad_input_dev` before it is initialized in `applespi_tp_dim_open`.
--
--- Patch [1]: [PATCH v4 1/3] Input: applespi - cancel pending work on driver remove ---
commit 89c8a3961b949e3c0049b442d0905f82cd245fbd
Author: Shih-Yuan Lee <fourdollars@debian.org>
Input: applespi - cancel pending work on driver remove
This commit fixes a use-after-free vulnerability during driver removal.
It explicitly cancels the pending worker thread that registers the touchpad
device before devres frees the private data structure.
> diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
> index b5ff71cd5a701..3bdb9e7cfb8b2 100644
> --- a/drivers/input/keyboard/applespi.c
> +++ b/drivers/input/keyboard/applespi.c
> @@ -1822,6 +1822,8 @@ static void applespi_remove(struct spi_device *spi)
>
> applespi_drain_reads(applespi);
[Severity: High]
This is a pre-existing issue, but can applespi_drain_reads() lead to a
use-after-free of applespi->gpe?
In applespi_remove(), applespi_drain_reads() waits for the read to complete:
static void applespi_drain_reads(struct applespi_data *applespi)
{
...
wait_event_lock_irq(applespi->drain_complete, !applespi->read_active,
applespi->cmd_msg_lock);
...
}
The async read callback signals completion and wakes the waitqueue:
static void applespi_async_read_complete(void *context)
{
...
applespi_msg_complete(applespi, true, true);
...
acpi_finish_gpe(NULL, applespi->gpe);
}
If applespi_remove() unblocks, completes, and triggers devres cleanup
before the read callback finishes, could the callback dereference the freed
applespi->gpe when calling acpi_finish_gpe()?
> + cancel_work_sync(&applespi->work);
> +
> debugfs_remove_recursive(applespi->debugfs_root);
> }
[Severity: High]
This is a pre-existing issue, but does the driver leak devm resources if
multiple info packets are received?
When the driver receives a PACKET_DEV_INFO packet:
applespi_handle_cmd_response()
applespi->rcvd_tp_info = message->tp_info;
schedule_work(&applespi->work);
The worker unconditionally allocates and registers the touchpad device:
applespi_register_touchpad_device()
touchpad_input_dev = devm_input_allocate_device(&applespi->spi->dev);
...
sts = input_register_device(touchpad_input_dev);
...
smp_store_release(&applespi->touchpad_input_dev, touchpad_input_dev);
If a malfunctioning or malicious device sends multiple PACKET_DEV_INFO
messages, does this overwrite applespi->touchpad_input_dev and leak the
previously allocated devm resources and registered input devices?
[Severity: High]
This is a pre-existing issue, but can the debugfs tp_dim file dereference a
NULL pointer?
The touchpad_input_dev is allocated asynchronously by the worker:
applespi_worker()
applespi_register_touchpad_device()
However, the debugfs entry is created synchronously during probe:
applespi_probe()
debugfs_create_file("tp_dim", ...);
If userspace opens the tp_dim file before the worker completes initialization,
applespi_tp_dim_open() will unconditionally dereference the pointer:
applespi_tp_dim_open()
snprintf(applespi->tp_dim_val, sizeof(applespi->tp_dim_val),
"0x%.4x %dx%d+%u+%u\n",
applespi->touchpad_input_dev->id.product,
Could this lead to a kernel panic since applespi->touchpad_input_dev might
still be NULL?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260711114937.16670-1-fourdollars@debian.org?part=1
^ permalink raw reply
* Re: [PATCH v4 2/3] Input: applespi - fix NULL pointer dereference in tp_dim open
From: sashiko-bot @ 2026-07-11 12:02 UTC (permalink / raw)
To: Shih-Yuan Lee; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260711114937.16670-3-fourdollars@debian.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing state clearance in early return paths of `applespi_got_data` causes deadlocks on device suspend or removal.
- [High] Re-submitting an active `spi_message` on timeout causes SPI core queue list corruption.
--
--- Patch [2]: [PATCH v4 2/3] Input: applespi - fix NULL pointer dereference in tp_dim open ---
commit 6c0dbd1a82c175c3c7ce52b489ebc6b640544832
Author: Shih-Yuan Lee <fourdollars@debian.org>
Input: applespi - fix NULL pointer dereference in tp_dim open
This commit fixes a NULL pointer dereference in applespi_tp_dim_open().
It uses smp_load_acquire() to safely load the asynchronously initialized
touchpad_input_dev and returns -ENODEV if it is not yet available.
> diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
> index 3bdb9e7cfb8b2..4d339445e9c71 100644
> --- a/drivers/input/keyboard/applespi.c
> +++ b/drivers/input/keyboard/applespi.c
> @@ -963,12 +963,18 @@ static void applespi_debug_update_dimensions(struct applespi_data *applespi,
> static int applespi_tp_dim_open(struct inode *inode, struct file *file)
> {
> struct applespi_data *applespi = inode->i_private;
> + struct input_dev *touchpad;
>
> file->private_data = applespi;
>
> + /* Pairs with smp_store_release in applespi_register_touchpad_device() */
> + touchpad = smp_load_acquire(&applespi->touchpad_input_dev);
> + if (!touchpad)
> + return -ENODEV;
> +
> snprintf(applespi->tp_dim_val, sizeof(applespi->tp_dim_val),
> "0x%.4x %dx%d+%u+%u\n",
> - applespi->touchpad_input_dev->id.product,
> + touchpad->id.product,
> applespi->tp_dim_min_x, applespi->tp_dim_min_y,
> applespi->tp_dim_max_x - applespi->tp_dim_min_x,
> applespi->tp_dim_max_y - applespi->tp_dim_min_y);
[Severity: High]
This isn't a bug introduced by this patch, but can the early return paths in
applespi_got_data() cause a deadlock on device suspend or removal?
In drivers/input/keyboard/applespi.c:applespi_got_data(), if a packet arrives
with a CRC error or as a partial multi-packet receipt, the function returns
early without clearing applespi->read_active:
if (applespi->drain) {
applespi->read_active = false;
applespi->write_active = false;
wake_up_all(&applespi->drain_complete);
}
return;
If the device is then suspended, applespi_drain_reads() is called, which waits
indefinitely:
wait_event_lock_irq(applespi->drain_complete, !applespi->read_active,
applespi->cmd_msg_lock);
Since GPE interrupts are disabled during suspend and no new reads are queued,
does read_active remain true forever, deadlocking the system?
[Severity: High]
This is a pre-existing issue, but does the timeout logic in
applespi_send_cmd_msg() cancel the active SPI message before resubmitting it?
When a timeout occurs, the internal state is cleared:
if (ktime_ms_delta(ktime_get(), applespi->cmd_msg_queued) < 1000)
return 0;
dev_warn(&applespi->spi->dev, "Command %d timed out\n",
applespi->cmd_evt_type);
applespi->cmd_msg_queued = 0;
applespi->write_active = false;
But then the exact same spi_message (&applespi->wr_m) is resubmitted:
sts = applespi_async(applespi, &applespi->wr_m,
applespi_async_write_complete);
If the original message is still actively linked in the SPI core's queue,
will passing the same spi_message to spi_async() again cause list corruption
and a kernel panic?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260711114937.16670-1-fourdollars@debian.org?part=2
^ permalink raw reply
* Re: [PATCH v4 3/3] spi: pxa2xx: disable DMA for Apple MacBook8,1
From: sashiko-bot @ 2026-07-11 11:58 UTC (permalink / raw)
To: Shih-Yuan Lee; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260711114937.16670-4-fourdollars@debian.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly introduced `force_pio` module parameter is ignored on Merrifield (MRFLD) SPI controllers.
--
--- Patch [3]: [PATCH v4 3/3] spi: pxa2xx: disable DMA for Apple MacBook8,1 ---
commit 0c8e6fc35fa52622b2ece57fb64858693816478b
Author: Shih-Yuan Lee <fourdollars@debian.org>
spi: pxa2xx: disable DMA for Apple MacBook8,1
On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller's DMA
handshake and interrupt routing frequently fail or time out on boot,
causing the keyboard and trackpad to become unresponsive.
Avoid this architectural bug by disabling DMA and forcing the SPI
controller to use PIO mode. Move this platform/motherboard-level quirk
to the SPI host controller driver (spi-pxa2xx-pci.c) where LPSS setup
occurs, preventing layering violations, TOCTOU races, or execute-after-free
bugs in the client driver.
Additionally, introduce a force_pio module parameter in the PCI
host controller driver to allow other users to force PIO mode for
debugging.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=108331
> diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
> index cae77ac185206..96bbc7a7c3817 100644
> --- a/drivers/spi/spi-pxa2xx-pci.c
> +++ b/drivers/spi/spi-pxa2xx-pci.c
[ ... ]
> @@ -166,7 +197,7 @@ static int lpss_spi_setup(struct pci_dev *dev, struct pxa2xx_spi_controller *c)
>
> c->dma_filter = lpss_dma_filter;
> c->dma_burst_size = 1;
> - c->enable_dma = 1;
> + c->enable_dma = pxa2xx_spi_pci_can_dma(dev);
> return 0;
> }
>
[Severity: Medium]
What about mrfld_spi_setup()? It looks like the force_pio module parameter
introduced in this patch is only respected for LPSS devices.
If a user boots a Merrifield (MRFLD) system and passes
spi_pxa2xx_pci.force_pio=1, the parameter will be ignored since the driver
still hardcodes DMA enablement in mrfld_spi_setup():
drivers/spi/spi-pxa2xx-pci.c:mrfld_spi_setup() {
...
c->dma_filter = lpss_dma_filter;
c->dma_burst_size = 8;
c->enable_dma = 1;
return 0;
}
Could mrfld_spi_setup() also use pxa2xx_spi_pci_can_dma(dev) to ensure
the parameter works consistently across all devices supported by this driver?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260711114937.16670-1-fourdollars@debian.org?part=3
^ permalink raw reply
* [PATCH v4 3/3] spi: pxa2xx: disable DMA for Apple MacBook8,1
From: Shih-Yuan Lee @ 2026-07-11 11:49 UTC (permalink / raw)
To: Dmitry Torokhov, Mark Brown
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Shih-Yuan Lee,
linux-input, linux-spi, linux-kernel, linux-arm-kernel
In-Reply-To: <20260711114937.16670-1-fourdollars@debian.org>
On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller's DMA
handshake and interrupt routing frequently fail or time out on boot,
causing the keyboard and trackpad to become unresponsive.
Avoid this architectural bug by disabling DMA and forcing the SPI
controller to use PIO mode. Move this platform/motherboard-level quirk
to the SPI host controller driver (spi-pxa2xx-pci.c) where LPSS setup
occurs, preventing layering violations, TOCTOU races, or execute-after-free
bugs in the client driver.
Additionally, introduce a `force_pio` module parameter in the PCI
host controller driver to allow other users to force PIO mode for
debugging.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=108331
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/spi/spi-pxa2xx-pci.c | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index cae77ac18520..96bbc7a7c381 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -18,9 +18,14 @@
#include <linux/dmaengine.h>
#include <linux/platform_data/dma-dw.h>
+#include <linux/dmi.h>
#include "spi-pxa2xx.h"
+static bool spi_pxa2xx_force_pio;
+module_param_named(force_pio, spi_pxa2xx_force_pio, bool, 0444);
+MODULE_PARM_DESC(force_pio, "Force PIO mode (disables DMA) for SPI transfers. ([0] = disabled, 1 = enabled)");
+
#define PCI_DEVICE_ID_INTEL_QUARK_X1000 0x0935
#define PCI_DEVICE_ID_INTEL_BYT 0x0f0e
#define PCI_DEVICE_ID_INTEL_MRFLD 0x1194
@@ -93,6 +98,32 @@ static void lpss_dma_put_device(void *dma_dev)
pci_dev_put(dma_dev);
}
+static const struct dmi_system_id pxa2xx_spi_pci_dmi_table[] = {
+ {
+ .ident = "Apple MacBook8,1",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBook8,1"),
+ },
+ },
+ { }
+};
+
+static bool pxa2xx_spi_pci_can_dma(struct pci_dev *dev)
+{
+ if (spi_pxa2xx_force_pio) {
+ pci_info(dev, "Forcing PIO mode (disabling DMA)\n");
+ return false;
+ }
+
+ if (dmi_check_system(pxa2xx_spi_pci_dmi_table)) {
+ pci_info(dev, "MacBook8,1 detected: disabling DMA to force PIO mode\n");
+ return false;
+ }
+
+ return true;
+}
+
static int lpss_spi_setup(struct pci_dev *dev, struct pxa2xx_spi_controller *c)
{
struct ssp_device *ssp = &c->ssp;
@@ -166,7 +197,7 @@ static int lpss_spi_setup(struct pci_dev *dev, struct pxa2xx_spi_controller *c)
c->dma_filter = lpss_dma_filter;
c->dma_burst_size = 1;
- c->enable_dma = 1;
+ c->enable_dma = pxa2xx_spi_pci_can_dma(dev);
return 0;
}
--
2.39.5
^ permalink raw reply related
* [PATCH v4 2/3] Input: applespi - fix NULL pointer dereference in tp_dim open
From: Shih-Yuan Lee @ 2026-07-11 11:49 UTC (permalink / raw)
To: Dmitry Torokhov, Mark Brown
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Shih-Yuan Lee,
linux-input, linux-spi, linux-kernel, linux-arm-kernel
In-Reply-To: <20260711114937.16670-1-fourdollars@debian.org>
The tp_dim debugfs file is registered synchronously during driver probe
in applespi_probe(). However, the applespi->touchpad_input_dev is
initialized and registered asynchronously in the driver's worker thread.
If a userspace process opens the debugfs file before the worker thread
has completed initialization, applespi_tp_dim_open() will dereference
the NULL applespi->touchpad_input_dev pointer, causing a kernel panic.
Fix this by using smp_load_acquire() to safely load touchpad_input_dev
and return -ENODEV if it is not yet initialized.
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/input/keyboard/applespi.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
index 3bdb9e7cfb8b..4d339445e9c7 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -963,12 +963,18 @@ static void applespi_debug_update_dimensions(struct applespi_data *applespi,
static int applespi_tp_dim_open(struct inode *inode, struct file *file)
{
struct applespi_data *applespi = inode->i_private;
+ struct input_dev *touchpad;
file->private_data = applespi;
+ /* Pairs with smp_store_release in applespi_register_touchpad_device() */
+ touchpad = smp_load_acquire(&applespi->touchpad_input_dev);
+ if (!touchpad)
+ return -ENODEV;
+
snprintf(applespi->tp_dim_val, sizeof(applespi->tp_dim_val),
"0x%.4x %dx%d+%u+%u\n",
- applespi->touchpad_input_dev->id.product,
+ touchpad->id.product,
applespi->tp_dim_min_x, applespi->tp_dim_min_y,
applespi->tp_dim_max_x - applespi->tp_dim_min_x,
applespi->tp_dim_max_y - applespi->tp_dim_min_y);
--
2.39.5
^ permalink raw reply related
* [PATCH v4 1/3] Input: applespi - cancel pending work on driver remove
From: Shih-Yuan Lee @ 2026-07-11 11:49 UTC (permalink / raw)
To: Dmitry Torokhov, Mark Brown
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Shih-Yuan Lee,
linux-input, linux-spi, linux-kernel, linux-arm-kernel
In-Reply-To: <20260711114937.16670-1-fourdollars@debian.org>
During driver removal in applespi_remove(), the managed private data
structure is freed by devres. However, the driver does not cancel the
asynchronous work applespi->work, which registers the touchpad input
device.
This creates a use-after-free (UAF) vulnerability if a pending or
running worker thread attempts to access the private data after the
remove function returns.
Fix this by explicitly calling cancel_work_sync(&applespi->work) in
applespi_remove() before cleanups.
Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
drivers/input/keyboard/applespi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
index b5ff71cd5a70..3bdb9e7cfb8b 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -1822,6 +1822,8 @@ static void applespi_remove(struct spi_device *spi)
applespi_drain_reads(applespi);
+ cancel_work_sync(&applespi->work);
+
debugfs_remove_recursive(applespi->debugfs_root);
}
--
2.39.5
^ permalink raw reply related
* [PATCH v4 0/3] Input/SPI: fixes for MacBook8,1 DMA timeout, UAF, and NULL pointer dereference
From: Shih-Yuan Lee @ 2026-07-11 11:49 UTC (permalink / raw)
To: Dmitry Torokhov, Mark Brown
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Shih-Yuan Lee,
linux-input, linux-spi, linux-kernel, linux-arm-kernel
In-Reply-To: <20260711055247.5412-1-fourdollars@debian.org>
Hi Dmitry, Mark, and the linux-input/linux-spi community,
This patch series addresses a long-standing DMA initialization timeout on the
early 2015 12" MacBook (MacBook8,1) on any boot (including cold boot), as well
as two pre-existing, high-severity UAF/NULL-pointer bugs in the applespi driver.
Changes in v4:
- Reverted the runtime `can_dma` callback override from `applespi.c` to avoid
architectural layering violation, data races (TOCTOU) with concurrent SPI
transfers, and execute-after-free vulnerability upon module unload.
- Moved the DMI quirk forcing PIO mode for MacBook8,1 to the host PCI glue
driver (spi-pxa2xx-pci.c) where LPSS setup occurs.
- Formatted the DMI match using a structured `pxa2xx_spi_pci_dmi_table` and
helper function `pxa2xx_spi_pci_can_dma()`.
- Added a `force_pio` module parameter in spi-pxa2xx-pci.c to allow other
users to manually force PIO mode for debugging.
Changes in v3:
- Added a `force_pio` module parameter to applespi to allow users to manually
disable DMA for SPI transfers.
- Resolved the execute-after-free vulnerability by unconditionally restoring
the original can_dma callback (even if NULL) in the driver remove path.
- Fixed the probe timing issue by applying the can_dma override at the very
beginning of applespi_probe() so that all early initialization transfers
safely use PIO mode, and properly restoring it in all probe error paths.
- Documented the Bugzilla link in the commit message of Patch 1.
Changes in v2:
- Fixed an unbind/remove execute-after-free vulnerability by storing and
restoring the host controller's original can_dma callback in applespi_probe()
and applespi_remove().
- Split the fixes into a 3-patch logical series.
Patch 1 fixes a pre-existing UAF vulnerability in the driver unbind path by
explicitly calling cancel_work_sync() on the asynchronous registration worker
work struct before devres frees the driver private data.
Patch 2 fixes a pre-existing race condition in the debugfs interface where
userspace could open the tp_dim file before the asynchronous worker has
finished initializing applespi->touchpad_input_dev, leading to a NULL
pointer dereference. We resolve this using smp_load_acquire() and checking
for NULL.
Patch 3 introduces a structured DMI quirk and a `force_pio` module parameter
in spi-pxa2xx-pci.c to disable DMA on MacBook8,1. This forces the controller
to use the rock-solid PIO mode from the very beginning.
Best regards,
Shih-Yuan Lee
Shih-Yuan Lee (3):
Input: applespi - cancel pending work on driver remove
Input: applespi - fix NULL pointer dereference in tp_dim open
spi: pxa2xx: disable DMA for Apple MacBook8,1
drivers/input/keyboard/applespi.c | 10 +++++++++-
drivers/spi/spi-pxa2xx-pci.c | 33 ++++++++++++++++++++++++++++++-
2 files changed, 41 insertions(+), 2 deletions(-)
--
2.39.5
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox