[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d17eeb0f-a46e-2515-43a6-36c16002928a@linuxfoundation.org>
Date: Thu, 15 Jul 2021 16:46:24 -0600
From: Shuah Khan <skhan@...uxfoundation.org>
To: Luis Chamberlain <mcgrof@...nel.org>,
Anirudh Rayabharam <mail@...rudhrb.com>
Cc: Hillf Danton <hdanton@...a.com>, gregkh@...uxfoundation.org,
rafael@...nel.org, linux-kernel@...r.kernel.org,
syzbot+77cea49e091776a57689@...kaller.appspotmail.com,
Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH] firmware_loader: Fix use-after-free Read in
firmware_loading_store
On 7/15/21 4:28 PM, Luis Chamberlain wrote:
> On Fri, Jul 09, 2021 at 10:38:12AM -0600, Shuah Khan wrote:
>> However I am seeing the following over and over again in the
>> log - hence I think it is safer to check the aborted status
>> in __fw_load_abort().
>>
>> ? __list_del_entry_valid+0xe0/0xf0
>> [ 348.604808][T12994] __list_del_entry_valid+0xe0/0xf0
>> [ 348.610020][T12994] firmware_loading_store+0x141/0x650
>> [ 348.615761][T12994] ? firmware_data_write+0x4e0/0x4e0
>> [ 348.621064][T12994] ? sysfs_file_ops+0x1c0/0x1c0
>> [ 348.625921][T12994] dev_attr_store+0x50/0x80
>>
>> Also the fallback logic takes actions based on errors as in
>> fw_load_sysfs_fallback() that returns -EAGAIN which would
>> trigger request_firmware() again.
>>
>> Based on all of this I think this fix is needed, if only I can
>> test for sure.
>
> Shuah, curious if you had read this patch from Anirudh Rayabharam
> and my response to that v4 patch iteration?
>
> https://lkml.kernel.org/r/20210518155921.4181-1-mail@anirudhrb.com
>
Yes. I realized I am trying to fix the same problem we have been
discussing. :) Sorry for the noise.
Ignore my patch. I will follow the thread.
thanks,
-- Shuah
Powered by blists - more mailing lists