linux-kernel - RE: ASoC: sh: Add RZ/G2L SSIF-2 driver

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]

Date:   Mon, 16 Aug 2021 17:05:16 +0000
From:   Biju Das <biju.das.jz@...renesas.com>
To:     Colin Ian King <colin.king@...onical.com>
CC:     Liam Girdwood <lgirdwood@...il.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>
Subject: RE: ASoC: sh: Add RZ/G2L SSIF-2 driver

Hi Colin,

Thanks for the report.

> Subject: re: ASoC: sh: Add RZ/G2L SSIF-2 driver
> 
> Hi,
> 
> Static analysis on linux-next with Coverity has detected an issue in
> rz_ssi_stop, sound/soc/sh/rz-ssi.c with the following commit:
> 
> commit 03e786bd43410fa93e5d2459f7a43e90ff0ae801
> Author: Biju Das <biju.das.jz@...renesas.com>
> Date:   Fri Aug 13 10:11:54 2021 +0100
> 
>     ASoC: sh: Add RZ/G2L SSIF-2 driver
> 
> 
> The analysis is as follows:
> 
> 367
> 368        /* Wait for idle */
> 369        timeout = 100;
> 370        while (--timeout) {
> 
> Wrong operator used (CONSTANT_EXPRESSION_RESULT)
> 
> operator_confusion: rz_ssi_reg_readl(ssi, 4) | (33554432UL /* 1UL << 25
> */) is always 1/true regardless of the values of its operand. This occurs
> as the logical operand of if.

> 
> 371                if (rz_ssi_reg_readl(ssi, SSISR) | SSISR_IIRQ)
> 372                        break;
> 373                udelay(1);
> 374        }
> 
> I suspect the & operator was intended to mask the specific bit. 
However
> I'm not sure if the intent is to detect if the SSISR_IIRQ bit should be
> zero or one at the point where the break should occur, hence I'm reporting
> this issue.

You are correct, it is supposed to be &. 
The idle condition is set by hw on the BIT(25) of this register.
So it should be &.

I will add your Reported-by tag, when I send the patch.

Thanks,
Biju