Re: [PATCH v4 1/2] hwmon: (powerz) Fix use-after-free on USB disconnect

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [High] Unsafe DMA Buffer Cacheline Sharing (Pre-existing Bug)
--

commit f830fe65a5d61278ed5e2ee2dbcd0c937471cfd4
Author: Sanman Pradhan <psanman@juniper.net>
hwmon: (powerz) Fix use-after-free on USB disconnect

This commit prevents a use-after-free by setting the URB pointer to NULL on
device disconnect, and checking for it before starting any read operations. It
also moves the hardware monitoring registration after the private data is set.

> diff --git a/drivers/hwmon/powerz.c b/drivers/hwmon/powerz.c
> --- a/drivers/hwmon/powerz.c
> +++ b/drivers/hwmon/powerz.c
> @@ -108,6 +108,9 @@ static int powerz_read_data(struct usb_device *udev, struct powerz_priv *priv)
>  {
>  	int ret;
>  
> +	if (!priv->urb)
> +		return -ENODEV;
> +
>  	priv->status = -ETIMEDOUT;
>  	reinit_completion(&priv->completion);

This isn't a bug introduced by this patch, but looking at the structure being
modified here:

struct powerz_priv {
        char transfer_buffer[64];
        struct mutex mutex;
        struct completion completion;
        struct urb *urb;
        int status;
};

Can this layout cause memory corruption during DMA?

The transfer_buffer is embedded at the start of the structure and is exactly 64
bytes long. On architectures where the CPU cacheline size or DMA minimum
alignment exceeds 64 bytes (such as 128 bytes on many arm64 platforms),
transfer_buffer will share a cacheline with the mutex and completion members.

When the USB core unmaps the buffer after an inbound transfer, the cache
invalidation operates on the entire cacheline. If the CPU concurrently modifies
the mutex or completion structures (for example, when a thread is placed on
the wait queue via wait_for_completion_interruptible_timeout), will those CPU
writes be destroyed by the DMA cache invalidation, or conversely corrupt the
inbound DMA data?

Should transfer_buffer be allocated separately, or forced to an explicit
alignment to ensure safe DMA?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260410002521.422645-1-sanman.pradhan@hpe.com?part=1