linux-kernel - Re: [PATCH] usb: dvb: check status of mxl111sf_read

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]

Message-ID: <CAOcJUbzr+cQ-Dk4HrYEgkRhgRPMeXAc_ZrXkp1ChKHAW5Rw+Tg@mail.gmail.com>
Date:   Wed, 26 Dec 2018 22:47:46 -0500
From:   Michael Ira Krufky <mkrufky@...uxtv.org>
To:     Kangjie Lu <kjlu@....edu>
Cc:     pakki001@....edu, Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media <linux-media@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: dvb: check status of mxl111sf_read_reg

Kangjie,

On Wed, Dec 26, 2018 at 12:59 AM Kangjie Lu <kjlu@....edu> wrote:
>
> When mxl111sf_read_reg fails, we shouldn't use "mode". The fix checks
> its return value using mxl_fail
>
> Signed-off-by: Kangjie Lu <kjlu@....edu>
> ---
>  drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c b/drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c
> index ffb6e7c72f57..aecc3d02fc1e 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c
> @@ -130,7 +130,8 @@ int mxl111sf_config_mpeg_in(struct mxl111sf_state *state,
>         mxl_fail(ret);
>
>         /* Configure MPEG Clock phase */
> -       mxl111sf_read_reg(state, V6_MPEG_IN_CLK_INV_REG, &mode);
> +       ret = mxl111sf_read_reg(state, V6_MPEG_IN_CLK_INV_REG, &mode);
> +       mxl_fail(ret);
>
>         if (clock_phase == TSIF_NORMAL)
>                 mode &= ~V6_INVERTED_CLK_PHASE;
> --
> 2.17.2 (Apple Git-113)

It *looks* correct, however....

If I recall correctly, this chip will often fail when reading
registers.   Notice, `mode` is initialized to zero at first, and not
again touched before being passed to the readreg function - this is on
purpose.   The value remains untouched if the read fails. ....and the
read _wil_ fail.  Maybe not always, but sometimes.

When you run with the patch applied, does it just spew errors?

-Mike