Re: [PATCH net 1/7] can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled: manual merge

[Matthieu Baerts <matttbe@kernel.org>]

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

Hello,

On 23/09/2025 08:32, Marc Kleine-Budde wrote:
> From: Chen Yufeng <chenyufeng@iie.ac.cn>
> 
> This issue is similar to the vulnerability in the `mcp251x` driver,
> which was fixed in commit 03c427147b2d ("can: mcp251x: fix resume from
> sleep before interface was brought up").
> 
> In the `hi311x` driver, when the device resumes from sleep, the driver
> schedules `priv->restart_work`. However, if the network interface was
> not previously enabled, the `priv->wq` (workqueue) is not allocated and
> initialized, leading to a null pointer dereference.
> 
> To fix this, we move the allocation and initialization of the workqueue
> from the `hi3110_open` function to the `hi3110_can_probe` function.
> This ensures that the workqueue is properly initialized before it is
> used during device resume. And added logic to destroy the workqueue
> in the error handling paths of `hi3110_can_probe` and in the
> `hi3110_can_remove` function to prevent resource leaks.

FYI, we got a small conflict when merging 'net' in 'net-next' in the
MPTCP tree due to this patch applied in 'net':

  6b6968084721 ("can: hi311x: fix null pointer dereference when resuming
from sleep before interface was enabled")

and this one from 'net-next':

  27ce71e1ce81 ("net: WQ_PERCPU added to alloc_workqueue users")

----- Generic Message -----
The best is to avoid conflicts between 'net' and 'net-next' trees but if
they cannot be avoided when preparing patches, a note about how to fix
them is much appreciated.
The conflict has been resolved on our side[1] and the resolution we
suggest is attached to this email. Please report any issues linked to
this conflict resolution as it might be used by others. If you worked on
the mentioned patches, don't hesitate to ACK this conflict resolution.
---------------------------

Regarding this conflict, I simply added "WQ_PERCPU" flag to
alloc_workqueue() in hi3110_can_probe() -- the new location after the
modification in 'net' -- instead of in hi3110_open().

Rerere cache is available in [2].

Cheers,
Matt

1: https://github.com/multipath-tcp/mptcp_net-next/commit/4ef39a01f1f0
2: https://github.com/multipath-tcp/mptcp-upstream-rr-cache/commit/1a8b8
-- 
Sponsored by the NGI0 Core fund.

[-- Attachment #2: 4ef39a01f1f0d195d0d4daae6312d1ae71d59188.patch --]
[-- Type: text/x-patch, Size: 682 bytes --]

diff --cc drivers/net/can/spi/hi311x.c
index 96f23311b4ee,963ea8510dd9..6d4b643e135f
--- a/drivers/net/can/spi/hi311x.c
+++ b/drivers/net/can/spi/hi311x.c
@@@ -909,6 -896,15 +896,16 @@@ static int hi3110_can_probe(struct spi_
  	if (ret)
  		goto out_clk;
  
 -	priv->wq = alloc_workqueue("hi3110_wq", WQ_FREEZABLE | WQ_MEM_RECLAIM,
++	priv->wq = alloc_workqueue("hi3110_wq",
++				   WQ_FREEZABLE | WQ_MEM_RECLAIM | WQ_PERCPU,
+ 				   0);
+ 	if (!priv->wq) {
+ 		ret = -ENOMEM;
+ 		goto out_clk;
+ 	}
+ 	INIT_WORK(&priv->tx_work, hi3110_tx_work_handler);
+ 	INIT_WORK(&priv->restart_work, hi3110_restart_work_handler);
+ 
  	priv->spi = spi;
  	mutex_init(&priv->hi3110_lock);