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>] [day] [month] [year] [list]
Message-ID: <496af9e1-4a25-e68a-da80-ec11126b6dc2@gmail.com>
Date:   Mon, 26 Jun 2023 23:30:20 +0800
From:   Tuo Li <islituo@...il.com>
To:     shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de,
        festevam@...il.com, linux-imx@....com,
        alexander.stein@...tq-group.com, quic_mojha@...cinc.com
Cc:     linux-arm-kernel@...ts.infradead.org,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        baijiaju1990@...look.com
Subject: [BUG] firmware: imx: possible null-pointer dereferences and
 data-inconsistency due to data races in imx_scu_rx_callback()

Hello,

Our static analysis tool finds some possible data races in the IMX
firmware in Linux 6.4.0.

In the function imx_scu_call_rpc(), the variable sc_ipc->msg is
accessed with holding the lock sc_ipc->lock:

   imx_scu_call_rpc()  --> Line 203
     mutex_lock(&sc_ipc->lock);  --> Line 212 (Lock sc_ipc->lock)
     sc_ipc->msg = msg;  --> Line 216 (Access sc_ipc->msg)
     sc_ipc->msg = NULL;  --> Line 251 (Access sc_ipc->msg)

However, in the function imx_scu_rx_callback(), the variable
sc_ipc->msg is accessed without holding the lock sc_ipc->lock:

   imx_scu_rx_callback()  --> Line 112
     sc_ipc->msg[0] = *data++;  --> Line 129 (Access sc_ipc->msg)
     sc_ipc->msg[sc_chan->idx] = *data;  --> Line 148 (Access sc_ipc->msg)

I am not sure whether the functions imx_scu_call_rpc() and
imx_scu_rx_callback() can be executed concurrently and whether
the variables sc_ipc in the two functions can be the same. If so,
harmful data races can occur because:
1. If the variable sc_ipc->msg is set to NULL after the if check at
Line 120, null-pointer dereferences may occur at Lines 129 and 148;
2. If sc_ipc->msg is changed by imx_scu_call_rpc() when updating
sc_ipc->msg with data. The values in data can be written to different
msgs and cause data-inconsistency.

I am not quite sure whether these possible data races are real and
how to fix them if they are real.

Any feedback would be appreciated, thanks!

Reported-by: BassCheck <bass@...a.edu.cn>

Best wishes,
Tuo Li

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ