From: Jonathan Cameron <jic23@kernel.org>
To: Joshua Crofts via B4 Relay <devnull+joshua.crofts1.gmail.com@kernel.org>
Cc: joshua.crofts1@gmail.com, "David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Gregor Boirie" <gregor.boirie@parrot.com>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
Sashiko <sashiko-bot@kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH v2] iio: magnetometer: ak8975: fix potential kernel stack memory leak
Date: Fri, 15 May 2026 12:58:21 +0100 [thread overview]
Message-ID: <20260515125821.520fe56f@jic23-huawei> (raw)
In-Reply-To: <20260515-magnetometer-kernel-mem-leak-v2-1-320e1ad4843d@gmail.com>
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,
next prev parent reply other threads:[~2026-05-15 11:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-15 10:28 [PATCH v2] iio: magnetometer: ak8975: fix potential kernel stack memory leak Joshua Crofts via B4 Relay
2026-05-15 11:58 ` Jonathan Cameron [this message]
2026-05-15 12:06 ` Joshua Crofts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260515125821.520fe56f@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy@kernel.org \
--cc=devnull+joshua.crofts1.gmail.com@kernel.org \
--cc=dlechner@baylibre.com \
--cc=gregor.boirie@parrot.com \
--cc=joshua.crofts1@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=sashiko-bot@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox