linux-kernel - Re: ALSA: drivers: opl3: assignment of a pointer that is not used, probable bug

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:   Sun, 12 Dec 2021 10:00:33 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     "Colin King (gmail)" <colin.i.king@...il.com>
Cc:     Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
        alsa-devel@...a-project.org,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: ALSA: drivers: opl3: assignment of a pointer that is not used, probable bug

On Sat, 11 Dec 2021 19:19:30 +0100,
Colin King (gmail) wrote:
> 
> Hi,
> 
> static analysis with scan-build has found an assignment to vp2 that is
> never used in function snd_opl3_note_on(),
> sound/drivers/opl3/opl3_midi.c as follows:
> 
>         if (instr_4op) {
>                 vp2 = &opl3->voices[voice + 3];
>                 if (vp->state > 0) {
>                         opl3_reg = reg_side | (OPL3_REG_KEYON_BLOCK +
>                                                voice_offset + 3);
>                         reg_val = vp->keyon_reg & ~OPL3_KEYON_BIT;
>                         opl3->command(opl3, opl3_reg, reg_val);
>                 }
>         }
> 
> sound/drivers/opl3/opl3_midi.c:399:3: warning: Value stored to 'vp2'
> is never read [deadcode.DeadStores]
>                 vp2 = &opl3->voices[voice + 3];
>                 ^     ~~~~~~~~~~~~~~~~~~~~~~~~
> 
> I suspect that references to vp in this if block should be to vp2, but
> I'm unsure if that is for all references or not, hence I'm reporting
> this issue.

Yes, the next vp->state > 0 check must be vp2->state > 0.
Care to submit a proper fix patch?


Thanks!

Takashi