linux-kernel - Re: [PATCH v2] cdx: Fix possible UAF error in driver_override

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] [day] [month] [year] [list]

Message-ID: <2024111230-snowdrop-haven-3a54@gregkh>
Date: Tue, 12 Nov 2024 19:13:04 +0100
From: Greg KH <greg@...ah.com>
To: Qiu-ji Chen <chenqiuji666@...il.com>
Cc: nipun.gupta@....com, nikhil.agarwal@....com,
	linux-kernel@...r.kernel.org, baijiaju1990@...il.com,
	stable@...r.kernel.org
Subject: Re: [PATCH v2] cdx: Fix possible UAF error in driver_override_show()

On Wed, Nov 13, 2024 at 12:23:38AM +0800, Qiu-ji Chen wrote:
> There is a data race between the functions driver_override_show() and
> driver_override_store(). In the driver_override_store() function, the
> assignment to ret calls driver_set_override(), which frees the old value
> while writing the new value to dev. If a race occurs, it may cause a
> use-after-free (UAF) error in driver_override_show().
> 
> To fix this issue, we adopt a logic similar to the driver_override_show()
> function in vmbus_drv.c, protecting dev within a lock to ensure its value
> remains unchanged.
> 
> This possible bug is found by an experimental static analysis tool
> developed by our team. This tool analyzes the locking APIs to extract
> function pairs that can be concurrently executed, and then analyzes the
> instructions in the paired functions to identify possible concurrency bugs
> including data races and atomicity violations.
> 
> Fixes: 48a6c7bced2a ("cdx: add device attributes")
> Cc: stable@...r.kernel.org
> Signed-off-by: Qiu-ji Chen <chenqiuji666@...il.com>
> ---
> V2:
> Modified the title and description.
> Removed the changes to cdx_bus_match().
> ---
>  drivers/cdx/cdx.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cdx/cdx.c b/drivers/cdx/cdx.c
> index 07371cb653d3..4af1901c9d52 100644
> --- a/drivers/cdx/cdx.c
> +++ b/drivers/cdx/cdx.c
> @@ -470,8 +470,12 @@ static ssize_t driver_override_show(struct device *dev,
>  				    struct device_attribute *attr, char *buf)
>  {
>  	struct cdx_device *cdx_dev = to_cdx_device(dev);
> +	ssize_t len;
>  
> -	return sysfs_emit(buf, "%s\n", cdx_dev->driver_override);
> +	device_lock(dev);
> +	len = sysfs_emit(buf, "%s\n", cdx_dev->driver_override);
> +	device_unlock(dev);

No, you should not need to lock a device in a sysfs callback like this,
especially for just printing out a string.

greg k-h