[PATCH 0/1] Input: applespi - force PIO mode on MacBook8,1

[PATCH 0/1] Input: applespi - force PIO mode on MacBook8,1

[Shih-Yuan Lee]

Hi Dmitry and the linux-input community,

This patch addresses a long-standing issue on the early 2015 12" MacBook
(MacBook8,1) where the SPI-connected keyboard and trackpad intermittently
fail to initialize on boot, and consistently fail to initialize after warm
reboots (soft restarts).

The issue stems from a race condition between the Intel LPSS DMA controller
(dw_dmac) and the host SPI controller (spi-pxa2xx-pci). When DMA mode is
active on this controller, transfers consistently time out (taking exactly
200ms per transfer), leaving the applespi client device in an uninitialized
and unresponsive state.

When the host controller probes before the DMA controller, it gracefully
falls back to PIO mode, which operates flawlessly.

To resolve this reliably without introducing platform-level DMI quirks into
the generic Intel LPSS PCI driver (which might affect non-Apple systems),
this patch introduces a targeted DMI quirk directly within applespi.c. On
MacBook8,1, it overrides the SPI controller's can_dma callback to a custom
helper that always returns false. This forces the controller to use the
rock-solid PIO mode specifically for this device.

Testing shows 100% reliable initialization of the keyboard and trackpad
across multiple soft and hard reboots.

Shih-Yuan Lee (1):
  Input: applespi - force PIO mode on MacBook8,1

 drivers/input/keyboard/applespi.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

-- 
2.39.5

[PATCH 1/1] Input: applespi - force PIO mode on MacBook8,1

[Shih-Yuan Lee]

On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller's DMA
handshake and interrupt routing frequently fail or time out after warm
reboots, causing the keyboard and trackpad to become unresponsive and
spamming "SPI transfer timed out" (-110) errors to dmesg.

Address this by introducing a DMI quirk inside the probe function that
detects the MacBook8,1 model and overrides the controller's can_dma
callback to a custom helper that always returns false. This forces the
host controller to fall back to the rock-solid PIO mode.

This is a self-contained device quirk that completely solves the DMA
race condition on MacBook8,1 systems without impacting other MacBooks or
generic Intel platforms.

Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
 drivers/input/keyboard/applespi.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
index b5ff71cd5a70..edf81e383612 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -45,6 +45,7 @@
 #include <linux/crc16.h>
 #include <linux/debugfs.h>
 #include <linux/delay.h>
+#include <linux/dmi.h>
 #include <linux/efi.h>
 #include <linux/input.h>
 #include <linux/input/mt.h>
@@ -1605,6 +1606,13 @@ static void applespi_save_bl_level(struct applespi_data *applespi,
 			 "Error saving backlight level to EFI vars: 0x%lx\n", sts);
 }
 
+static bool applespi_can_not_dma(struct spi_controller *controller,
+				 struct spi_device *spi,
+				 struct spi_transfer *xfer)
+{
+	return false;
+}
+
 static int applespi_probe(struct spi_device *spi)
 {
 	struct applespi_data *applespi;
@@ -1613,6 +1621,15 @@ static int applespi_probe(struct spi_device *spi)
 	int sts, i;
 	unsigned long long gpe, usb_status;
 
+	/*
+	 * MacBook8,1's SPI host controller DMA is broken (timeout errors).
+	 * Force PIO mode by overriding the controller's can_dma callback.
+	 */
+	if (dmi_match(DMI_PRODUCT_NAME, "MacBook8,1")) {
+		dev_info(&spi->dev, "Disabling DMA for MacBook8,1 SPI to force PIO mode\n");
+		spi->controller->can_dma = applespi_can_not_dma;
+	}
+
 	/* check if the USB interface is present and enabled already */
 	acpi_sts = acpi_evaluate_integer(spi_handle, "UIST", NULL, &usb_status);
 	if (ACPI_SUCCESS(acpi_sts) && usb_status) {
-- 
2.39.5

Re: [PATCH 1/1] Input: applespi - force PIO mode on MacBook8,1

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] The client driver improperly modifies the shared SPI host controller's `can_dma` callback, causing an execute-after-free vulnerability upon driver unbind or probe failure.

Pre-existing issues:
- [High] Missing `cancel_work_sync(&applespi->work)` during driver removal leads to a Use-After-Free of the managed private data structure.
- [High] The `tp_dim` debugfs file can be opened by userspace before the touchpad input device is fully initialized, causing a NULL pointer dereference.
--

--- Patch [1]: [PATCH 1/1] Input: applespi - force PIO mode on MacBook8,1 ---
commit e15d04076e4b2b62df355b30d858accad86794ac
Author: Shih-Yuan Lee <fourdollars@debian.org>

Input: applespi - force PIO mode on MacBook8,1

On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller's DMA
handshake and interrupt routing frequently fail or time out after warm
reboots. Address this by introducing a DMI quirk inside the probe function
that detects the MacBook8,1 model and overrides the controller's can_dma
callback to a custom helper that always returns false.

> diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
> index b5ff71cd5a701..edf81e3836122 100644
> --- a/drivers/input/keyboard/applespi.c
> +++ b/drivers/input/keyboard/applespi.c
> @@ -1605,6 +1606,13 @@ static void applespi_save_bl_level(struct applespi_data *applespi,

[ ... ]

> +static bool applespi_can_not_dma(struct spi_controller *controller,
> +				 struct spi_device *spi,
> +				 struct spi_transfer *xfer)
> +{
> +	return false;
> +}
> +
>  static int applespi_probe(struct spi_device *spi)
>  {
>  	struct applespi_data *applespi;
> @@ -1613,6 +1621,15 @@ static int applespi_probe(struct spi_device *spi)
>  	int sts, i;
>  	unsigned long long gpe, usb_status;
>  
> +	/*
> +	 * MacBook8,1's SPI host controller DMA is broken (timeout errors).
> +	 * Force PIO mode by overriding the controller's can_dma callback.
> +	 */
> +	if (dmi_match(DMI_PRODUCT_NAME, "MacBook8,1")) {
> +		dev_info(&spi->dev, "Disabling DMA for MacBook8,1 SPI to force PIO mode\n");
> +		spi->controller->can_dma = applespi_can_not_dma;

[Severity: High]
Could this overwrite of the shared SPI host controller's can_dma callback
cause a regression by leaving a dangling pointer if the applespi module is
unloaded?

Since applespi_can_not_dma() is a local function inside this driver, won't
subsequent SPI transfers by other devices on this bus attempt to execute
unmapped memory after this module is removed?

> +	}
> +

This isn't a bug introduced by this patch, but looking at applespi_remove():

drivers/input/keyboard/applespi.c:applespi_remove() {
    ...
    applespi_drain_reads(applespi);

    debugfs_remove_recursive(applespi->debugfs_root);
}

[Severity: High]
Does this teardown path miss a call to cancel_work_sync(&applespi->work)?

Because devres will free the applespi structure when applespi_remove()
returns, could an already pending or running applespi_worker cause a
use-after-free here?

This is also a pre-existing issue, but looking at applespi_tp_dim_open():

drivers/input/keyboard/applespi.c: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,
    ...
}

[Severity: High]
Can userspace open the tp_dim debugfs file before the asynchronous worker
has finished initializing applespi->touchpad_input_dev?

Since the debugfs file is registered synchronously during applespi_probe(),
could an early read trigger a NULL pointer dereference here?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260711055247.5412-2-fourdollars@debian.org?part=1

[PATCH v2 0/3] Input: applespi - fixes for DMA timeout, UAF, and NULL pointer dereference

[Shih-Yuan Lee]

Hi Dmitry and the linux-input community,

This patch series addresses a long-standing DMA initialization timeout on the 
early 2015 12" MacBook (MacBook8,1) as well as two pre-existing, high-severity 
UAF/NULL-pointer bugs in the applespi driver.

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 introduces the 
    MacBook8,1 DMI quirk and its unbind safety, Patch 2 cancels pending work 
    synchronously on remove (UAF fix), and Patch 3 protects the debugfs open 
    handler (NULL pointer fix).

Patch 1 introduces a DMI quirk inside applespi.c that overrides the SPI 
controller's can_dma callback to a custom helper that always returns false 
for MacBook8,1. This forces the controller to use the rock-solid PIO mode 
specifically for this device. To prevent an execute-after-free vulnerability 
upon module unload or unbind, it preserves and restores the original can_dma 
callback.

Patch 2 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 3 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.

Best regards,
Shih-Yuan Lee

Shih-Yuan Lee (3):
  Input: applespi - force PIO mode on MacBook8,1
  Input: applespi - cancel pending work on driver remove
  Input: applespi - fix NULL pointer dereference in tp_dim open

 drivers/input/keyboard/applespi.c | 38 ++++++++++++++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

-- 
2.39.5

[PATCH v2 1/3] Input: applespi - force PIO mode on MacBook8,1

[Shih-Yuan Lee]

On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller's DMA
handshake and interrupt routing frequently fail or time out after warm
reboots, causing the keyboard and trackpad to become unresponsive and
spamming "SPI transfer timed out" (-110) errors to dmesg.

Address this by introducing a DMI quirk inside the probe function that
detects the MacBook8,1 model and overrides the controller's can_dma
callback to a custom helper that always returns false. This forces the
host controller to fall back to the rock-solid PIO mode.

Since we overwrite the shared host controller's can_dma callback, save
the original callback pointer during probe and restore it in the unbind
(remove) path to prevent an execute-after-free vulnerability when the
applespi driver is unloaded.

Signed-off-by: Shih-Yuan Lee <fourdollars@debian.org>
---
 drivers/input/keyboard/applespi.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
index b5ff71cd5a70..07a910cb8459 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -45,6 +45,7 @@
 #include <linux/crc16.h>
 #include <linux/debugfs.h>
 #include <linux/delay.h>
+#include <linux/dmi.h>
 #include <linux/efi.h>
 #include <linux/input.h>
 #include <linux/input/mt.h>
@@ -431,6 +432,10 @@ struct applespi_data {
 	int				tp_dim_max_x;
 	int				tp_dim_min_y;
 	int				tp_dim_max_y;
+
+	bool				(*original_can_dma)(struct spi_controller *controller,
+							    struct spi_device *spi,
+							    struct spi_transfer *xfer);
 };
 
 static const unsigned char applespi_scancodes[] = {
@@ -1605,6 +1610,13 @@ static void applespi_save_bl_level(struct applespi_data *applespi,
 			 "Error saving backlight level to EFI vars: 0x%lx\n", sts);
 }
 
+static bool applespi_can_not_dma(struct spi_controller *controller,
+				 struct spi_device *spi,
+				 struct spi_transfer *xfer)
+{
+	return false;
+}
+
 static int applespi_probe(struct spi_device *spi)
 {
 	struct applespi_data *applespi;
@@ -1788,6 +1800,19 @@ static int applespi_probe(struct spi_device *spi)
 	debugfs_create_file("tp_dim", 0400, applespi->debugfs_root, applespi,
 			    &applespi_tp_dim_fops);
 
+	/*
+	 * MacBook8,1's SPI host controller DMA is broken (timeout errors).
+	 * Force PIO mode by overriding the controller's can_dma callback.
+	 *
+	 * Since we modify the shared controller's callback, we save the
+	 * original pointer and restore it in applespi_remove().
+	 */
+	applespi->original_can_dma = spi->controller->can_dma;
+	if (dmi_match(DMI_PRODUCT_NAME, "MacBook8,1")) {
+		dev_info(&spi->dev, "Disabling DMA for MacBook8,1 SPI to force PIO mode\n");
+		spi->controller->can_dma = applespi_can_not_dma;
+	}
+
 	return 0;
 }
 
@@ -1822,6 +1847,9 @@ static void applespi_remove(struct spi_device *spi)
 
 	applespi_drain_reads(applespi);
 
+	if (applespi->original_can_dma)
+		spi->controller->can_dma = applespi->original_can_dma;
+
 	debugfs_remove_recursive(applespi->debugfs_root);
 }
 
-- 
2.39.5

[PATCH v2 2/3] Input: applespi - cancel pending work on driver remove

[Shih-Yuan Lee]

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 07a910cb8459..b6b4d258d0dd 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -1847,6 +1847,8 @@ static void applespi_remove(struct spi_device *spi)
 
 	applespi_drain_reads(applespi);
 
+	cancel_work_sync(&applespi->work);
+
 	if (applespi->original_can_dma)
 		spi->controller->can_dma = applespi->original_can_dma;
 
-- 
2.39.5

[PATCH v2 3/3] Input: applespi - fix NULL pointer dereference in tp_dim open

[Shih-Yuan Lee]

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 b6b4d258d0dd..1f8e4ae90285 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -968,12 +968,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

Re: [PATCH v2 1/3] Input: applespi - force PIO mode on MacBook8,1

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incomplete restoration of `spi->controller->can_dma` leads to an execute-after-free on module unload if the original callback was NULL.
- [High] Architectural violation and data race due to mutating shared SPI host controller, which is applied too late to prevent DMA timeouts.
--

--- Patch [1]: [PATCH v2 1/3] Input: applespi - force PIO mode on MacBook8,1 ---
commit c3d66aabf4cd47b8a9f7af8039fad4fc085aef5f
Author: Shih-Yuan Lee <fourdollars@debian.org>

Input: applespi - force PIO mode on MacBook8,1

This patch introduces a DMI quirk to force PIO mode on MacBook8,1 laptops.
It overrides the shared SPI controller's can_dma callback to avoid timeout
errors during DMA handshakes, and attempts to restore the original callback
when the driver is removed.

[ ... ]
> --- a/drivers/input/keyboard/applespi.c
> +++ b/drivers/input/keyboard/applespi.c
[ ... ]
> @@ -1788,6 +1800,19 @@ static int applespi_probe(struct spi_device *spi)
>  	debugfs_create_file("tp_dim", 0400, applespi->debugfs_root, applespi,
>  			    &applespi_tp_dim_fops);
>  
> +	/*
> +	 * MacBook8,1's SPI host controller DMA is broken (timeout errors).
> +	 * Force PIO mode by overriding the controller's can_dma callback.
> +	 *
> +	 * Since we modify the shared controller's callback, we save the
> +	 * original pointer and restore it in applespi_remove().
> +	 */
> +	applespi->original_can_dma = spi->controller->can_dma;
> +	if (dmi_match(DMI_PRODUCT_NAME, "MacBook8,1")) {
> +		dev_info(&spi->dev, "Disabling DMA for MacBook8,1 SPI to force PIO mode\n");
> +		spi->controller->can_dma = applespi_can_not_dma;
> +	}
> +
>  	return 0;
>  }

[Severity: High]
Is this too late to prevent the DMA timeouts?

The override occurs at the very end of applespi_probe(). However, early SPI
transfers triggered earlier in the function via applespi_setup_spi() and
applespi_init(), as well as any reads triggered by ACPI GPE interrupts that
were already enabled, will still attempt to use DMA and fail.

Furthermore, does mutating the shared SPI host controller's method table from
a peripheral client driver cause data races with concurrent SPI core
operations? Typically, controller-level hardware quirks need to be implemented
in the SPI host controller driver itself rather than the client driver to
maintain encapsulation and prevent races.

[ ... ]
> @@ -1822,6 +1847,9 @@ static void applespi_remove(struct spi_device *spi)
>  
>  	applespi_drain_reads(applespi);
>  
> +	if (applespi->original_can_dma)
> +		spi->controller->can_dma = applespi->original_can_dma;
> +
>  	debugfs_remove_recursive(applespi->debugfs_root);
>  }

[Severity: High]
Will this leave a dangling pointer in the host controller if the original
callback was NULL?

If the host controller does not natively provide a can_dma callback,
applespi->original_can_dma will be NULL. In that scenario, this conditional
check evaluates to false and skips the restoration entirely. 

Once the applespi module is unloaded and unmapped from memory, the shared
host controller will be left pointing to the freed applespi_can_not_dma
function. Any subsequent SPI transfers on the host controller would then
dereference this freed pointer, resulting in an execute-after-free and kernel
panic.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260711065415.7396-1-fourdollars@debian.org?part=1

Re: [PATCH v2 3/3] Input: applespi - fix NULL pointer dereference in tp_dim open

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Unbounded allocations of touchpad input devices triggered by repeated PACKET_DEV_INFO SPI messages.
- [High] Deadlock in `applespi_drain_reads` during module unload or system suspend after a CRC error.
--

--- Patch [3]: [PATCH v2 3/3] Input: applespi - fix NULL pointer dereference in tp_dim open ---
commit 54174cce6bfb0203a63026dc8e54eb65b7ee620c
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.
If a userspace process opens the debugfs file before the worker thread
has completed initialization, it will dereference the NULL pointer.
This commit uses smp_load_acquire to safely load the pointer and returns
-ENODEV if not initialized.

> diff --git a/drivers/input/keyboard/applespi.c b/drivers/input/keyboard/applespi.c
> index b6b4d258d0dd5..1f8e4ae902855 100644
> --- a/drivers/input/keyboard/applespi.c
> +++ b/drivers/input/keyboard/applespi.c
> @@ -968,12 +968,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 could this lead to an unbounded
allocation of touchpad input devices?

When the SPI device sends a PACKET_DEV_INFO message,
applespi_handle_cmd_response() unconditionally queues applespi->work:

	applespi->rcvd_tp_info = message->tp_info;
	schedule_work(&applespi->work);
	return;

The worker function applespi_worker() then calls
applespi_register_touchpad_device(), which unconditionally allocates and
registers a new touchpad device:

	/* create touchpad input device */
	touchpad_input_dev = devm_input_allocate_device(&applespi->spi->dev);
	...
	/* register input device */
	sts = input_register_device(touchpad_input_dev);

This appears to overwrite the applespi->touchpad_input_dev pointer without
freeing or unregistering the previous one. 

If the hardware sends multiple info packets, does this cause a resource leak 
of devm-managed memory and input devices?

[Severity: High]
This is a pre-existing issue, but is there a potential deadlock during module
unload or system suspend after a CRC error?

In applespi_got_data(), if a SPI packet fails the CRC check and the driver
is not currently draining, the function returns early without clearing
applespi->read_active:

	if (!applespi_verify_crc(applespi, applespi->rx_buffer,
				 APPLESPI_PACKET_SIZE)) {
		guard(spinlock_irqsave)(&applespi->cmd_msg_lock);

		if (applespi->drain) {
			applespi->read_active = false;
			applespi->write_active = false;
			wake_up_all(&applespi->drain_complete);
		}
		return;
	}

If no further SPI interrupts arrive before a system suspend or rmmod,
applespi_remove() and applespi_suspend() disable GPE interrupts and then call
applespi_drain_reads():

	/* disable GPE interrupt */
	acpi_disable_gpe(NULL, applespi->gpe);
	applespi_drain_reads(applespi);

applespi_drain_reads() will then wait for !applespi->read_active:

	wait_event_lock_irq(applespi->drain_complete, !applespi->read_active,
			    applespi->cmd_msg_lock);

Since interrupts are disabled, no new read can arrive to clear the flag. 

Can this result in an unrecoverable deadlock waiting for read_active to clear?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260711065415.7396-1-fourdollars@debian.org?part=3

Re: [PATCH v2 2/3] Input: applespi - cancel pending work on driver remove

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 7 potential issue(s) to consider:

Pre-existing issues:
- [High] Use-after-free of the applespi structure inside the SPI asynchronous read completion callback during driver removal.
- [High] Deadlock/Hang on driver unbind or suspend due to un-cleared read_active flag on CRC error.
- [High] Missing payload length validation leads to reading uninitialized heap memory or old packet data.
- [High] Unbounded allocation and registration of touchpad input devices triggered by untrusted device input.
- [High] Use-after-free if probe fails after input device registration while async SPI writes are in-flight.
- [High] NULL pointer dereference when opening the tp_dim debugfs file before touchpad initialization.
- [Low] Redundant manual assignment of input_dev->dev.parent when using devm_input_allocate_device().
--

--- Patch [2]: [PATCH v2 2/3] Input: applespi - cancel pending work on driver remove ---
commit fee01b08b7f49cc284abe2da246718c6d357db23
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
> index 07a910cb8459f..b6b4d258d0dd5 100644
> --- a/drivers/input/keyboard/applespi.c
> +++ b/drivers/input/keyboard/applespi.c
> @@ -1847,6 +1847,8 @@ static void applespi_remove(struct spi_device *spi)
>  
>  	applespi_drain_reads(applespi);
>  

[Severity: High]
This isn't a bug introduced by this patch, but does the read completion callback
access the private data structure after it has been freed during driver removal?

applespi_drain_reads() unblocks when applespi_msg_complete() clears read_active:

applespi_msg_complete()
{
...
	if (is_read_compl)
		applespi->read_active = false;
...
	if (applespi->drain && !applespi->write_active)
		wake_up_all(&applespi->drain_complete);
}

However, applespi_msg_complete() is called by applespi_async_read_complete()
before it finishes using the applespi structure:

applespi_async_read_complete(void *context)
{
	struct applespi_data *applespi = context;
...
		applespi_msg_complete(applespi, true, true);
	} else {
		applespi_got_data(applespi);
	}

	acpi_finish_gpe(NULL, applespi->gpe);
}

Once wake_up_all() returns, applespi_remove() can finish, which allows devres
to free the applespi structure. Does the final acpi_finish_gpe() call then
dereference a freed applespi->gpe?


[Severity: High]
This is a pre-existing issue, but can the kernel hang indefinitely during
driver unbind if an SPI read packet fails the CRC check?

In applespi_got_data(), if the CRC check fails and drain is false, it returns
early without clearing read_active:

applespi_got_data()
{
...
	if (!applespi_verify_crc(applespi, applespi->rx_buffer,
				 APPLESPI_PACKET_SIZE)) {
		guard(spinlock_irqsave)(&applespi->cmd_msg_lock);

		if (applespi->drain) {
			applespi->read_active = false;
...
		}

		return;
	}

Since read_active remains true, when applespi_remove() later calls
applespi_drain_reads(), will wait_event_lock_irq() wait indefinitely for
read_active to be cleared, resulting in a deadlock?

> +	cancel_work_sync(&applespi->work);
> +

[Severity: High]
This is a pre-existing issue, but can the device trigger unbounded memory
allocations and input device registrations?

In applespi_handle_cmd_response(), whenever an INFO packet is received,
it unconditionally schedules the initialization worker:

applespi_handle_cmd_response()
{
	if (packet->device == PACKET_DEV_INFO &&
	    le16_to_cpu(message->type) == 0x1020) {
...
		applespi->rcvd_tp_info = message->tp_info;
		schedule_work(&applespi->work);
		return;
	}
...

The worker then allocates and registers a new touchpad input device
using devm_input_allocate_device():

applespi_worker()
  -> applespi_register_touchpad_device()
  {
	touchpad_input_dev = devm_input_allocate_device(&applespi->spi->dev);
...
	sts = input_register_device(touchpad_input_dev);
...

If the device repeatedly sends 0x1020 INFO responses, won't this continually
allocate new managed devices and leak the previous ones?

>  	if (applespi->original_can_dma)
>  		spi->controller->can_dma = applespi->original_can_dma;
>  

[Severity: Low]
This isn't a bug introduced by this patch, but is the manual assignment of
input_dev->dev.parent redundant here?

Looking at applespi_probe(), it uses devm_input_allocate_device(), which
automatically sets the parent to the device passed to it:

applespi_probe()
{
...
	applespi->keyboard_input_dev = devm_input_allocate_device(&spi->dev);
...
	applespi->keyboard_input_dev->dev.parent = &spi->dev;
...

The same applies to touchpad_input_dev in applespi_register_touchpad_device().


[Severity: High]
This is a pre-existing issue, but do applespi_got_data() and
applespi_handle_cmd_response() read out-of-bounds memory when processing
messages?

applespi_got_data() checks the packet length against sizeof(packet->data):

	if (len > sizeof(packet->data)) {
...
		goto msg_complete;
	}

But when handling the message payload, it casts the data and processes it
without checking if the packet actually contains the full struct:

	if (packet->flags == PACKET_TYPE_READ &&
	    packet->device == PACKET_DEV_KEYB) {
		applespi_handle_keyboard_event(applespi, &message->keyboard);

And similarly in applespi_handle_cmd_response():

	if (packet->device == PACKET_DEV_INFO &&
	    le16_to_cpu(message->type) == 0x1020) {
...
		applespi->rcvd_tp_info = message->tp_info;

If an undersized packet is received, does this lead to reading uninitialized
buffer memory (stale data) or out-of-bounds memory?


[Severity: High]
This is a pre-existing issue, but is there a use-after-free risk if
applespi_probe() fails after the keyboard input device is registered?

In applespi_probe(), the keyboard input device is registered:

	sts = input_register_device(applespi->keyboard_input_dev);
	if (sts) {
...

Later in probe, ACPI GPE setup can fail, returning an error:

	acpi_sts = acpi_install_gpe_handler(...);
	if (ACPI_FAILURE(acpi_sts)) {
...
		return -ENODEV;
	}

Because the input device was already visible to userspace, an LED event might
have queued an asynchronous SPI write. If probe returns an error, devres will
free the applespi structure, but the in-flight SPI write is not cancelled.

Will the completion callback then access the freed applespi structure?

applespi_async_write_complete()
{
...
	if (!applespi_check_write_status(applespi, applespi->wr_m.status)) {
...


[Severity: High]
This is a pre-existing issue, but is there a risk of a NULL pointer dereference
if the tp_dim debugfs file is opened before the touchpad is initialized?

In applespi_probe(), the tp_dim debugfs file is created synchronously:

	debugfs_create_file("tp_dim", 0400, applespi->debugfs_root, applespi,
			    &applespi_tp_dim_fops);

However, applespi->touchpad_input_dev is allocated asynchronously in
applespi_worker(). If userspace opens the file before the worker executes
(or if the hardware never responds), applespi_tp_dim_open() will dereference
a NULL touchpad_input_dev:

static int applespi_tp_dim_open(struct inode *inode, struct file *file)
{
...
	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 result in a kernel panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260711065415.7396-1-fourdollars@debian.org?part=2

[PATCH v4 0/3] Input/SPI: fixes for MacBook8,1 DMA timeout, UAF, and NULL pointer dereference

[Shih-Yuan Lee]

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

[PATCH v4 1/3] Input: applespi - cancel pending work on driver remove

[Shih-Yuan Lee]

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

[PATCH v4 2/3] Input: applespi - fix NULL pointer dereference in tp_dim open

[Shih-Yuan Lee]

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

[PATCH v4 3/3] spi: pxa2xx: disable DMA for Apple MacBook8,1

[Shih-Yuan Lee]

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

Re: [PATCH v4 3/3] spi: pxa2xx: disable DMA for Apple MacBook8,1

[sashiko-bot]

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

Re: [PATCH v4 2/3] Input: applespi - fix NULL pointer dereference in tp_dim open

[sashiko-bot]

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

Re: [PATCH v4 1/3] Input: applespi - cancel pending work on driver remove

[sashiko-bot]

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

[PATCH v5 0/3] Input/SPI: fixes for MacBook8,1 DMA timeout, UAF, and NULL pointer dereference

[Shih-Yuan Lee]

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

[PATCH v5 1/3] Input: applespi - cancel pending work on driver remove

[Shih-Yuan Lee]

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

[PATCH v5 2/3] Input: applespi - fix NULL pointer dereference in tp_dim open

[Shih-Yuan Lee]

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

[PATCH v5 3/3] spi: pxa2xx: disable DMA for Apple MacBook8,1

[Shih-Yuan Lee]

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

Re: [PATCH v5 1/3] Input: applespi - cancel pending work on driver remove

[sashiko-bot]

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

Re: [PATCH v5 2/3] Input: applespi - fix NULL pointer dereference in tp_dim open

[sashiko-bot]

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

Re: [PATCH v5 1/3] Input: applespi - cancel pending work on driver remove

[Dmitry Torokhov]

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/

Re: [PATCH v5 0/3] Input/SPI: fixes for MacBook8,1 DMA timeout, UAF, and NULL pointer dereference

[Shih-Yuan Lee]

Hi Dmitry, Mark, and the linux-input/linux-spi community,

Thank you for all the feedback across v1 through v5 of this series.

During further testing on the MacBook8,1 hardware, I discovered two
additional issues that change the scope of the fix:

1. The LPSS SPI controller (00:15.4) loses all private register state
   across S3 suspend/resume.  Restoring only the SSP clock on resume,
   without de-asserting LPSS_PRIV_RESETS (0x204) first, causes a PCIe
   Completion Timeout and a watchdog-triggered system reset.  Additionally,
   the IDMA block (which shares the SPI interrupt line) needs its registers
   restored to prevent spurious interrupts from masking real SPI transfers.
   This is a generic LPSS fix in spi-pxa2xx.c, not specific to MacBook8,1.

2. The applespi_remove() teardown has a use-after-free race between the
   drain_writes/drain_reads calls and the GPE handler removal.

Given these changes, the patch series has grown and now spans two
subsystems more cleanly than before:

  [input] Input: applespi - register touchpad device synchronously in probe
  [input] Input: applespi - fix use-after-free in applespi_remove()
  [spi]   spi: pxa2xx: disable DMA and fix runtime PM for Apple MacBook8,1
  [spi]   spi: pxa2xx: restore LPSS private and IDMA registers on S3 resume

I will submit these as two separate series to linux-input and linux-spi
respectively rather than continuing this thread, to keep subsystem
boundaries clean.

Thanks again for your patience and review.

Shih-Yuan Lee

-- 
2.39.5

Re: [PATCH v5 0/3] Input/SPI: fixes for MacBook8,1 DMA timeout, UAF, and NULL pointer dereference

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

On Sat, Jul 11, 2026 at 09:11:37PM +0800, Shih-Yuan Lee wrote:
> 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.

Are there any dependencies between the SPI and input parts of the
series?  There's nothing visible...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]