linux-kernel - Re: [PATCH v5] i3c: Fix read from unreadable memory at i3c_master_queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8c624cf0-febc-4ab9-8141-2372bfe4d577@quicinc.com>
Date: Wed, 26 Mar 2025 12:15:00 +0530
From: Mukesh Kumar Savaliya <quic_msavaliy@...cinc.com>
To: Frank Li <Frank.li@....com>,
        Manjunatha Venkatesh
	<manjunatha.venkatesh@....com>
CC: <alexandre.belloni@...tlin.com>, <arnd@...db.de>,
        <gregkh@...uxfoundation.org>, <bbrezillon@...nel.org>,
        <linux-i3c@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <rvmanjumce@...il.com>, <stable@...r.kernel.org>
Subject: Re: [PATCH v5] i3c: Fix read from unreadable memory at
 i3c_master_queue_ibi()



On 3/25/2025 8:13 PM, Frank Li wrote:
> Subject should be
> 
> i3c: Add NULL pointer check in i3c_master_queue_ibi()
> 
yes, Aligned.
> On Tue, Mar 25, 2025 at 03:53:32PM +0530, Manjunatha Venkatesh wrote:
>> As part of I3C driver probing sequence for particular device instance,
>> While adding to queue it is trying to access ibi variable of dev which is
>> not yet initialized causing "Unable to handle kernel read from unreadable
>> memory" resulting in kernel panic.
>>
>> Below is the sequence where this issue happened.
>> 1. During boot up sequence IBI is received at host  from the slave device
>>     before requesting for IBI, Usually will request IBI by calling
>>     i3c_device_request_ibi() during probe of slave driver.
>> 2. Since master code trying to access IBI Variable for the particular
>>     device instance before actually it initialized by slave driver,
>>     due to this randomly accessing the address and causing kernel panic.
>> 3. i3c_device_request_ibi() function invoked by the slave driver where
>>     dev->ibi = ibi; assigned as part of function call
>>     i3c_dev_request_ibi_locked().
>> 4. But when IBI request sent by slave device, master code  trying to access
>>     this variable before its initialized due to this race condition
>>     situation kernel panic happened.
> 
> How about commit message as:
> 
> The I3C master driver may receive an IBI from a target device that has not
> been probed yet. In such cases, the master calls `i3c_master_queue_ibi()`
> to queue an IBI work task, leading to "Unable to handle kernel read from
> unreadable memory" and resulting in a kernel panic.
> 
> Typical IBI handling flow:
> 1. The I3C master scans target devices and probes their respective drivers.
> 2. The target device driver calls `i3c_device_request_ibi()` to enable IBI
>     and assigns `dev->ibi = ibi`.
> 3. The I3C master receives an IBI from the target device and calls
>     `i3c_master_queue_ibi()` to queue the target device driver’s IBI handler
>     task.
> 
> However, since target device events are asynchronous to the I3C probe
> sequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`,
> leading to a kernel panic.
> 
> Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing
> an uninitialized `dev->ibi`, ensuring stability.
> 
>>
>> Fixes: 3a379bbcea0af ("i3c: Add core I3C infrastructure")
>> Cc: stable@...r.kernel.org
>> Link: https://lore.kernel.org/lkml/Z9gjGYudiYyl3bSe@lizhi-Precision-Tower-5810/
>> Signed-off-by: Manjunatha Venkatesh <manjunatha.venkatesh@....com>
>> ---
>> Changes since v4:
>>    - Fix added at generic places master.c which is applicable for all platforms
>>
>>   drivers/i3c/master.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
>> index d5dc4180afbc..c65006aa0684 100644
>> --- a/drivers/i3c/master.c
>> +++ b/drivers/i3c/master.c
>> @@ -2561,6 +2561,9 @@ static void i3c_master_unregister_i3c_devs(struct i3c_master_controller *master)
>>    */
>>   void i3c_master_queue_ibi(struct i3c_dev_desc *dev, struct i3c_ibi_slot *slot)
>>   {
>> +	if (!dev->ibi || !slot)
>> +		return;
>> +
1. Shouldn't this be a Logical AND ? what if slot is non NULL but the 
IBI is NULL ?

2. This being void function, it doesn't say anything to caller if it's 
successful or failed ? Should we make this non void function ?
if not, i am thinking it may run into multiple attempts, no log too.
>>   	atomic_inc(&dev->ibi->pending_ibis);
>>   	queue_work(dev->ibi->wq, &slot->work);
>>   }
>> --
>> 2.46.1
>>
>