[PATCH v2] iio: magnetometer: ak8975: fix potential kernel stack memory leak

[PATCH v2] iio: magnetometer: ak8975: fix potential kernel stack memory leak

[Joshua Crofts via B4 Relay]

From: Joshua Crofts <joshua.crofts1@gmail.com>

Currently in the AK8975 driver there are four instances where potential
uninitialized kernel stack memory leaks can occur. If
i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than
the size of the buffer, uninitialized bytes are retained in the buffer
and later the buffer is passed on to IIO buffers, potentially leaking
memory to userspace.

Fix this by adding checks whether the return value of the function is
equal to the size of the buffer and subsequently if the value is
lesser than zero to distinguish from a returned error code.

Fixes: bc11ca4a0b84 ("iio:magnetometer:ak8975: triggered buffer support")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260513-ak8975-fix-v1-1-104ea605dd54%40gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
---
Changes in v2:
- Added 2 additional checks
- Removed nested if statements
- Link to v1: https://lore.kernel.org/r/20260514-magnetometer-kernel-mem-leak-v1-1-35b48d699faf@gmail.com
---
 drivers/iio/magnetometer/ak8975.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
index b648b0afa5733fd7a54bdf2b8f92f00e924c074b..e085c5a6583dfe40c653abf4936594a5acd08f51 100644
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@ -495,6 +495,10 @@ static int ak8975_who_i_am(struct i2c_client *client,
 		dev_err(&client->dev, "Error reading WIA\n");
 		return ret;
 	}
+	if (ret != sizeof(wia_val)) {
+		dev_err(&client->dev, "Error reading WIA\n");
+		return -EIO;
+	}
 
 	if (wia_val[0] != AK8975_DEVICE_ID)
 		return -ENODEV;
@@ -619,6 +623,10 @@ static int ak8975_setup(struct i2c_client *client)
 		dev_err(&client->dev, "Not able to read asa data\n");
 		return ret;
 	}
+	if (ret != sizeof(data->asa)) {
+		dev_err(&client->dev, "Error reading asa data\n");
+		return -EIO;
+	}
 
 	/* After reading fuse ROM data set power-down mode */
 	ret = ak8975_set_mode(data, POWER_DOWN);
@@ -758,6 +766,10 @@ static int ak8975_read_axis(struct iio_dev *indio_dev, int index, int *val)
 			sizeof(rval), (u8*)&rval);
 	if (ret < 0)
 		goto exit;
+	if (ret != sizeof(rval)) {
+		ret = -EIO;
+		goto exit;
+	}
 
 	/* Read out ST2 for release lock on measurement data. */
 	ret = i2c_smbus_read_byte_data(client, data->def->ctrl_regs[ST2]);
@@ -873,6 +885,8 @@ static void ak8975_fill_buffer(struct iio_dev *indio_dev)
 							(u8 *)fval);
 	if (ret < 0)
 		goto unlock;
+	if (ret != sizeof(fval))
+		goto unlock;
 
 	mutex_unlock(&data->lock);
 

---
base-commit: 86138b484d6367a57312f69af4ec958806c2673c
change-id: 20260514-magnetometer-kernel-mem-leak-d88a85d28a60

Best regards,
-- 
Joshua Crofts <joshua.crofts1@gmail.com>

Re: [PATCH v2] iio: magnetometer: ak8975: fix potential kernel stack memory leak

[Jonathan Cameron]

On Fri, 15 May 2026 12:28:23 +0200
Joshua Crofts via B4 Relay <devnull+joshua.crofts1.gmail.com@kernel.org> wrote:

> From: Joshua Crofts <joshua.crofts1@gmail.com>
> 
> Currently in the AK8975 driver there are four instances where potential
> uninitialized kernel stack memory leaks can occur. If
> i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than
> the size of the buffer, uninitialized bytes are retained in the buffer
> and later the buffer is passed on to IIO buffers, potentially leaking
> memory to userspace.
> 
> Fix this by adding checks whether the return value of the function is
> equal to the size of the buffer and subsequently if the value is
> lesser than zero to distinguish from a returned error code.
> 
> Fixes: bc11ca4a0b84 ("iio:magnetometer:ak8975: triggered buffer support")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260513-ak8975-fix-v1-1-104ea605dd54%40gmail.com
> Cc: stable@vger.kernel.org

I'm doubtful about a stable marking for the patch.

Personally I've never seen an i2c response that was short (yet correct
enough not to trigger an error return).  There are specific devices
that will do this because they are not ready for instance, but not on
a general read.

Whilst I know in theory they can occur, has anyone else ever seen one?

I don't mind hardening against it but not something I'd rush
to backport or even necessarily to take as a fix.

Patch looks fine to me and the thing sashiko is moaning about is already
fixed on my tree.  Note this is going the slow way at least partly because
of all the other work on the driver!

So picked up by stable tag dropped.  Applied to the togreg branch of iio.git

Thanks,

Jonathan

> Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
> ---
> Changes in v2:
> - Added 2 additional checks
> - Removed nested if statements
> - Link to v1: https://lore.kernel.org/r/20260514-magnetometer-kernel-mem-leak-v1-1-35b48d699faf@gmail.com
> ---
>  drivers/iio/magnetometer/ak8975.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
> index b648b0afa5733fd7a54bdf2b8f92f00e924c074b..e085c5a6583dfe40c653abf4936594a5acd08f51 100644
> --- a/drivers/iio/magnetometer/ak8975.c
> +++ b/drivers/iio/magnetometer/ak8975.c
> @@ -495,6 +495,10 @@ static int ak8975_who_i_am(struct i2c_client *client,
>  		dev_err(&client->dev, "Error reading WIA\n");
>  		return ret;
>  	}
> +	if (ret != sizeof(wia_val)) {
> +		dev_err(&client->dev, "Error reading WIA\n");
> +		return -EIO;
> +	}
>  
>  	if (wia_val[0] != AK8975_DEVICE_ID)
>  		return -ENODEV;
> @@ -619,6 +623,10 @@ static int ak8975_setup(struct i2c_client *client)
>  		dev_err(&client->dev, "Not able to read asa data\n");
>  		return ret;
>  	}
> +	if (ret != sizeof(data->asa)) {
> +		dev_err(&client->dev, "Error reading asa data\n");
> +		return -EIO;
> +	}
>  
>  	/* After reading fuse ROM data set power-down mode */
>  	ret = ak8975_set_mode(data, POWER_DOWN);
> @@ -758,6 +766,10 @@ static int ak8975_read_axis(struct iio_dev *indio_dev, int index, int *val)
>  			sizeof(rval), (u8*)&rval);
>  	if (ret < 0)
>  		goto exit;
> +	if (ret != sizeof(rval)) {
> +		ret = -EIO;
> +		goto exit;
> +	}
>  
>  	/* Read out ST2 for release lock on measurement data. */
>  	ret = i2c_smbus_read_byte_data(client, data->def->ctrl_regs[ST2]);
> @@ -873,6 +885,8 @@ static void ak8975_fill_buffer(struct iio_dev *indio_dev)
>  							(u8 *)fval);
>  	if (ret < 0)
>  		goto unlock;
> +	if (ret != sizeof(fval))
> +		goto unlock;
>  
>  	mutex_unlock(&data->lock);
>  
> 
> ---
> base-commit: 86138b484d6367a57312f69af4ec958806c2673c
> change-id: 20260514-magnetometer-kernel-mem-leak-d88a85d28a60
> 
> Best regards,

Re: [PATCH v2] iio: magnetometer: ak8975: fix potential kernel stack memory leak

[Joshua Crofts]

On Fri, 15 May 2026 at 13:58, Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Fri, 15 May 2026 12:28:23 +0200
> Joshua Crofts via B4 Relay <devnull+joshua.crofts1.gmail.com@kernel.org> wrote:
>
> > From: Joshua Crofts <joshua.crofts1@gmail.com>
> >
> > Currently in the AK8975 driver there are four instances where potential
> > uninitialized kernel stack memory leaks can occur. If
> > i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than
> > the size of the buffer, uninitialized bytes are retained in the buffer
> > and later the buffer is passed on to IIO buffers, potentially leaking
> > memory to userspace.
> >
> > Fix this by adding checks whether the return value of the function is
> > equal to the size of the buffer and subsequently if the value is
> > lesser than zero to distinguish from a returned error code.
> >
> > Fixes: bc11ca4a0b84 ("iio:magnetometer:ak8975: triggered buffer support")
> > Reported-by: Sashiko <sashiko-bot@kernel.org>
> > Closes: https://sashiko.dev/#/patchset/20260513-ak8975-fix-v1-1-104ea605dd54%40gmail.com
> > Cc: stable@vger.kernel.org
>
> I'm doubtful about a stable marking for the patch.
>
> Personally I've never seen an i2c response that was short (yet correct
> enough not to trigger an error return).  There are specific devices
> that will do this because they are not ready for instance, but not on
> a general read.
>
> Whilst I know in theory they can occur, has anyone else ever seen one?
>
> I don't mind hardening against it but not something I'd rush
> to backport or even necessarily to take as a fix.
>
> Patch looks fine to me and the thing sashiko is moaning about is already
> fixed on my tree.  Note this is going the slow way at least partly because
> of all the other work on the driver!
>
> So picked up by stable tag dropped.  Applied to the togreg branch of iio.git

Hi Jonathan,

Wasn't really sure whether to CC stable, but added it just in case. Yes, short
reads are pretty rare, however I do agree with the hardening angle.

Thanks

--
Kind regards

CJD