On 12/1/20 12:47 AM, Martin Hundebøll wrote:
> Hi Russ,
>
> On 01/12/2020 00.54, Russ Weight wrote:
>> Thanks Martin. I'll work on a fix for this.
>
> Attached is my in-house fix.
>
> // Martin
>
>> On 11/26/20 6:02 AM, Martin Hundebøll wrote:
>>> Hi Russ,
>>>
>>> I found another thing while testing this...
>>>
>>> On 06/11/2020 02.09, Russ Weight wrote:
>>>
>>> <snip>
>>>
>>>> +static ssize_t filename_store(struct device *dev, struct device_attribute *attr,
>>>> + const char *buf, size_t count)
>>>> +{
>>>> + struct fpga_sec_mgr *smgr = to_sec_mgr(dev);
>>>> + int ret = count;
>>>> +
>>>> + if (count == 0 || count >= PATH_MAX)
>>>> + return -EINVAL;
>>>> +
>>>> + mutex_lock(&smgr->lock);
>>>> + if (smgr->driver_unload || smgr->progress != FPGA_SEC_PROG_IDLE) {
>>>> + ret = -EBUSY;
>>>> + goto unlock_exit;
>>>> + }
>>>> +
>>>> + smgr->filename = kstrndup(buf, count - 1, GFP_KERNEL);
>>>
>>> The `count - 1` is meant to remove a trailing newline, but opae-sdk writes the filename without newline, so better do it conditionally...
After looking at how kstrndup() is used elsewhere, and after
doing some experimentation, I think the best fix may be to just
remove the "- 1":
smgr->filename = kstrndup(buf, count, GFP_KERNEL);
The code shouldn't have assumed a "\n", and I don't think the
kernel should be required to do white-space cleanup.
Does this fix seem OK to you?
- Russ
>>>
>>>> + if (!smgr->filename) {
>>>> + ret = -ENOMEM;
>>>> + goto unlock_exit;
>>>> + }
>>>> +
>>>> + smgr->err_code = FPGA_SEC_ERR_NONE;
>>>> + smgr->progress = FPGA_SEC_PROG_READING;
>>>> + reinit_completion(&smgr->update_done);
>>>> + schedule_work(&smgr->work);
>>>> +
>>>> +unlock_exit:
>>>> + mutex_unlock(&smgr->lock);
>>>> + return ret;
>>>> +}
>>>> +static DEVICE_ATTR_WO(filename);
>>>> +
>>>> +static struct attribute *sec_mgr_update_attrs[] = {
>>>> + &dev_attr_filename.attr,
>>>> + NULL,
>>>> +};
>>>
>>> Thanks,
>>> Martin
>>
