From: sashiko-bot@kernel.org
To: "Abdurrahman Hussain" <abdurrahman@nexthop.ai>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v3 2/5] hwmon: (pmbus/adm1266) add clear_blackbox debugfs entry
Date: Thu, 14 May 2026 00:47:49 +0000 [thread overview]
Message-ID: <20260514004750.10B3FC19425@smtp.kernel.org> (raw)
In-Reply-To: <20260512-adm1266-v3-2-a81a479b0bb0@nexthop.ai>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [Critical] The shared buffer `data->dev_mem` is modified and accessed in `adm1266_nvmem_read()` outside of any lock, leading to data corruption on concurrent nvmem reads.
- [Critical] Stack buffer overflow in `adm1266_nvmem_read_blackbox()` caused by an undersized buffer passed to `i2c_smbus_read_block_data()`.
- [Critical] Heap buffer overflow in `adm1266_nvmem_read_blackbox()` due to blindly trusting the hardware-provided `record_count`.
- [Critical] Out-of-bounds write in `adm1266_pmbus_block_xfer()` due to unsafe `memcpy` using an untrusted length from the I2C device.
- [High] DMA read buffer bounds mismatch in `adm1266_pmbus_block_xfer()` exposes an out-of-bounds write vulnerability.
--
commit 2afefd44ddcfcdd2fe5f8721e42653261b4e9ff0
Author: Abdurrahman Hussain <abdurrahman@nexthop.ai>
hwmon: (pmbus/adm1266) add clear_blackbox debugfs entry
This commit adds a write-only debugfs file to clear the ADM1266 blackbox
buffer. Writing to the file issues a 2-byte block-write command to the
device. It also adds a pmbus_lock guard to adm1266_nvmem_read_blackbox()
to prevent concurrent read/write operations from interleaving.
> diff --git a/drivers/hwmon/pmbus/adm1266.c b/drivers/hwmon/pmbus/adm1266.c
> index 7b8433226176f..bd3784d59a7c8 100644
> --- a/drivers/hwmon/pmbus/adm1266.c
> +++ b/drivers/hwmon/pmbus/adm1266.c
[ ... ]
> @@ -379,10 +415,11 @@ static int adm1266_nvmem_read_blackbox(struct adm1266_data *data, u8 *read_buff)
> u8 buf[5];
> int ret;
>
> + guard(pmbus_lock)(data->client);
> +
While this patch adds a guard here, does adm1266_nvmem_read() also modify
and access data->dev_mem without taking this lock?
If two threads read the nvmem device concurrently, could one thread's
memset() execute during another thread's memcpy(), causing corrupted data
to be copied to userspace?
> ret = i2c_smbus_read_block_data(data->client, ADM1266_BLACKBOX_INFO, buf);
Can this call overflow the buf array?
Looking at i2c_smbus_read_block_data(), it blindly copies up to
I2C_SMBUS_BLOCK_MAX (32) bytes into the provided buffer based on the
length byte returned by the hardware:
drivers/i2c/i2c-core-smbus.c:i2c_smbus_read_block_data() {
...
status = i2c_smbus_xfer(...);
if (status)
return status;
memcpy(values, &data.block[1], data.block[0]);
return data.block[0];
}
If the I2C device returns a block length greater than 5, would this
memcpy() overflow the 5-byte buf array?
> if (ret < 0)
> return ret;
> -
> if (ret != 4)
> return -EIO;
>
> @@ -392,7 +429,6 @@ static int adm1266_nvmem_read_blackbox(struct adm1266_data *data, u8 *read_buff)
> ret = adm1266_pmbus_block_xfer(data, ADM1266_READ_BLACKBOX, 1, &index, read_buff);
Does this loop have a bounds checking issue?
The record_count loop limit is read directly from buf[3]. If the device
returns a record_count greater than 32, will the loop advance read_buff
past the end of the 2048-byte allocation for data->dev_mem?
Also, could this call to adm1266_pmbus_block_xfer() cause an
out-of-bounds write?
In adm1266_pmbus_block_xfer(), the memcpy() uses a length from the I2C
device:
drivers/hwmon/pmbus/adm1266.c:adm1266_pmbus_block_xfer() {
...
memcpy(data_r, &msgs[1].buf[1], msgs[1].buf[0]);
...
}
If the device returns a length up to 255, could this write past the
expected 64 bytes (ADM1266_BLACKBOX_SIZE) allocated for read_buff?
Additionally, does the DMA read buffer size in adm1266_pmbus_block_xfer()
expose an overflow regression?
The read_buf array in struct adm1266_data is sized
ADM1266_PMBUS_BLOCK_MAX + 1 (256 bytes). However, the i2c_msg length is
set to 257:
drivers/hwmon/pmbus/adm1266.c:adm1266_pmbus_block_xfer() {
...
{
.addr = client->addr,
.flags = I2C_M_RD | I2C_M_DMA_SAFE,
.buf = data->read_buf,
.len = ADM1266_PMBUS_BLOCK_MAX + 2,
}
...
}
If the hardware sends a full 257-byte response, will the controller
write 1 byte past the end of data->read_buf?
> if (ret < 0)
> return ret;
> -
> if (ret != ADM1266_BLACKBOX_SIZE)
> return -EIO;
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512-adm1266-v3-0-a81a479b0bb0@nexthop.ai?part=2
next prev parent reply other threads:[~2026-05-14 0:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 18:56 [PATCH v3 0/5] hwmon: (pmbus/adm1266) blackbox, FW rev, rtc_class, GPIO label Abdurrahman Hussain
2026-05-12 18:56 ` [PATCH v3 1/5] hwmon: (pmbus/adm1266) add firmware_revision debugfs entry Abdurrahman Hussain
2026-05-15 1:42 ` Guenter Roeck
2026-05-15 3:35 ` Abdurrahman Hussain
2026-05-15 4:48 ` Guenter Roeck
2026-05-15 5:57 ` Abdurrahman Hussain
2026-05-12 18:56 ` [PATCH v3 2/5] hwmon: (pmbus/adm1266) add clear_blackbox " Abdurrahman Hussain
2026-05-14 0:47 ` sashiko-bot [this message]
2026-05-14 4:58 ` Abdurrahman Hussain
2026-05-12 18:56 ` [PATCH v3 3/5] hwmon: (pmbus/adm1266) add powerup_counter " Abdurrahman Hussain
2026-05-14 1:17 ` sashiko-bot
2026-05-12 18:56 ` [PATCH v3 4/5] hwmon: (pmbus/adm1266) replace probe-time RTC seed with rtc_class device Abdurrahman Hussain
2026-05-14 1:57 ` sashiko-bot
2026-05-14 2:14 ` Guenter Roeck
2026-05-14 2:14 ` Guenter Roeck
2026-05-14 4:25 ` Abdurrahman Hussain
2026-05-12 18:56 ` [PATCH v3 5/5] hwmon: (pmbus/adm1266) include adapter number in GPIO line label Abdurrahman Hussain
2026-05-15 1:45 ` Guenter Roeck
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=20260514004750.10B3FC19425@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=abdurrahman@nexthop.ai \
--cc=linux-hwmon@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.