On Thu, May 05, 2022 at 01:29:15PM +0300, Dan Carpenter wrote:
> If we iterate through a loop using list_for_each_entry() without
> hitting a break, then the iterator points to bogus memory. The
> if (tst->name != test_fw_config->upload_name) { will likely still work
> but technically it's an out of bounds read.
>
> Fixes: a31ad463b72d ("test_firmware: Add test support for firmware upload")
> Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
> ---
> lib/test_firmware.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/lib/test_firmware.c b/lib/test_firmware.c
> index 76115c1a2629..c82b65947ce6 100644
> --- a/lib/test_firmware.c
> +++ b/lib/test_firmware.c
> @@ -1392,7 +1392,8 @@ static ssize_t upload_read_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> {
> - struct test_firmware_upload *tst;
> + struct test_firmware_upload *tst = NULL;
> + struct test_firmware_upload *tst_iter;
> int ret = -EINVAL;
>
> if (!test_fw_config->upload_name) {
> @@ -1401,11 +1402,13 @@ static ssize_t upload_read_show(struct device *dev,
> }
>
> mutex_lock(&test_fw_mutex);
Note the mutex lock.
> - list_for_each_entry(tst, &test_upload_list, node)
> - if (tst->name == test_fw_config->upload_name)
> + list_for_each_entry(tst_iter, &test_upload_list, node)
If a lock is held I can't see how the premise of this patch is
correct and we ensure we don't remove entries while holdingg
the lock.
Generalizing this problem seems like a bigger issue, no?
Additionally this patch doesn't apply at all on linux-next.
Luis
> + if (tst_iter->name == test_fw_config->upload_name) {
> + tst = tst_iter;
> break;
> + }
>
> - if (tst->name != test_fw_config->upload_name) {
> + if (!tst) {
> pr_err("Firmware name not found: %s\n",
> test_fw_config->upload_name);
> goto out;
> --
> 2.35.1
>
