linux-kernel - [BUG] mei: a possible use-after-free caused by concurrency execution

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

Message-ID: <bebacc37-c203-4d1a-a7e5-e51016805e9b@gmail.com>
Date: Thu, 16 Jan 2025 17:26:33 +0800
From: Tuo Li <islituo@...il.com>
To: tomas.winkler@...el.com, arnd@...db.de, gregkh@...uxfoundation.org
Cc: LKML <linux-kernel@...r.kernel.org>, Jia-Ju Bai <baijiaju1990@...il.com>
Subject: [BUG] mei: a possible use-after-free caused by concurrency execution

Hello,

Our static analysis tool has identified a potential use-after-free caused
by concurrency execution in drivers/misc/mei/main.c.

Consider the following execution scenario:
(The line numbers can be referred to
https://elixir.bootlin.com/linux/v6.12/source/drivers/misc/mei/main.c)

  mei_release()                            //Line 112
    cl = file->private_data;               //Line 114
    mutex_lock(&dev->device_lock);         //Line 123
    kfree(cl);                             //Line 149
    file->private_data = NULL;             //Line 152
    mutex_unlock(&dev->device_lock);       //Line 154

  mei_read()                               //Line 169
    cl = file->private_data;               //Line 172
    mutex_lock(&dev->device_lock);         //Line 184
    cb = mei_cl_read_cb(cl, file);         //Line 200
    cl_dbg(dev, cl, ...);                  //Line 275
    mutex_unlock(&dev->device_lock);       //Line 276

If mei_release() and mei_read() can execute concurrently and the execution
order is 114, 172, 123, 149 (free), 152, 154, 184, 200 (use), 275 (use),
276, a possible use-after-free can occur.

Our static analysis tool reports this use-after-free when analyzing Linux
6.12. The tool deduces lock() and unlock() pairs with alias analysis. It
then applies data flow analysis to detect use-after-free across
synchronization points.

I am not quite sure whether this possible use-after-free is real and how to
fix it if it is real.
Any feedback would be appreciated. Thanks!

Sincerely,
Tuo Li