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: <Z+LA/GASTPMMcVpC@lizhi-Precision-Tower-5810>
Date: Tue, 25 Mar 2025 10:43:08 -0400
From: Frank Li <Frank.li@....com>
To: 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()

Subject should be

i3c: Add NULL pointer check in i3c_master_queue_ibi()

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;
> +
>  	atomic_inc(&dev->ibi->pending_ibis);
>  	queue_work(dev->ibi->wq, &slot->work);
>  }
> --
> 2.46.1
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ