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]
Date:   Thu, 24 Nov 2022 10:57:34 +0100
From:   Guillermo Rodriguez Garcia <guille.rodriguez@...il.com>
To:     linux-kernel@...r.kernel.org
Cc:     Tan Nayır <tannayir@...il.com>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Banajit Goswami <bgoswami@...eaurora.org>,
        Richard Fitzgerald <rf@...nsource.cirrus.com>,
        Lucas Tanure <tanureal@...nsource.cirrus.com>,
        David Rhodes <david.rhodes@...rus.com>,
        James Schulman <james.schulman@...rus.com>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        patches@...nsource.cirrus.com, alsa-devel@...a-project.org,
        Mark Brown <broonie@...nel.org>
Subject: SOC_DOUBLE_R_SX_TLV controls broken in cs24l51 driver

Hi all,

I am using a dev board with a Cirrus Logic cs24l51 codec.

This used to work fine prior to kernel version 5.x, however after 5.x
it is not possible to set certain values for ALSA controls from
userspace.

I believe this is related to the input validation that is mentioned in
this thread: https://lore.kernel.org/all/Yph8C3bRxcr6ogW7@sirena.org.uk/T/,
and possibly in this commit: 4f1e50d6a9cf9c1b8c859d449b5031cacfa8404e
("ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()")

For the cs24l51, all the controls that fail are using the
SOC_DOUBLE_R_SX_TLV macro.

I have traced this to the checks in snd_soc_put_volsw_sx, specifically
the (val > max - min) check:

pr_warn("Max: %d, Min: %d, Value: %d", max, min, val);
pr_warn("platform_max: %d", mc->platform_max);
if (mc->platform_max && val > mc->platform_max)
{
    return -EINVAL;
}
if (val > max - min){
    pr_warn("(val > max - min) check failed");
    return -EINVAL;
}
if (val < 0)
    return -EINVAL;

According to the datasheet of the CS24L51, section 6.13, page 61, the
PCMMIXX_VOL registers accept the following range of values:

Binary Code / Volume Setting
001 1000 / +12.0 dB
··· ···
000 0000 / 0 dB
111 1111 / -0.5 dB
111 1110 / -1.0 dB
··· ···
001 1001 / -51.5 dB

Minimum value is 0x19 (001 1001) corresponding to -51.5 dB, then there
are 127 possible gain settings from -51.5 dB to +12.0 dB, in 0.5 dB
steps.

This is declared in the driver as follows:

SOC_DOUBLE_R_SX_TLV("PCM Playback Volume",
CS42L51_PCMA_VOL, CS42L51_PCMB_VOL,
0, 0x19, 0x7F, adc_pcm_tlv),

0x19 = min value
0x7F = number of gain settings

This seems to be correct according to the semantics of the
SOC_DOUBLE_R_SX_TLV macro as described in commit
34198710f55b5f359f43e67d9a08fe5aadfbca1b ("ASoC: Add info callback for
SX_TLV controls").

However, the (val > max - min) check in snd_soc_put_volsw_sx fails in
the above example because val = 127, max - min = 127 - 25 = 102.

So I am not sure how this should be fixed. Is the SX_TLV macro being
used incorrectly here? Is the check in snd_soc_put_volsw_sx wrong?

Any pointers are welcome.

Thanks,

(If possible, please CC me in any replies)

Guillermo Rodriguez Garcia
guille.rodriguez@...il.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ