linux-kernel - Re: [PATCH] staging: typec: Fix sparse warnings about incorrect types

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 May 2017 08:23:15 -0700
From:   Guenter Roeck <groeck@...gle.com>
To:     Guru Das Srinagesh <gurooodas@...il.com>,
        Yueyao Zhu <yueyao@...gle.com>
Cc:     Guenter Roeck <groeck@...omium.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        devel@...verdev.osuosl.org,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] staging: typec: Fix sparse warnings about incorrect types

On Tue, May 9, 2017 at 9:39 PM, Guru Das Srinagesh <gurooodas@...il.com> wrote:
> Fix the following sparse warnings about incorrect type usage:
>
> tcpci.c:290:38: warning: incorrect type in argument 1 (different base types)
> tcpci.c:290:38:    expected unsigned short [unsigned] [usertype] header
> tcpci.c:290:38:    got restricted __le16 const [usertype] header
> tcpci.c:295:16: warning: incorrect type in assignment (different base types)
> tcpci.c:295:16:    expected unsigned int [unsigned] header
> tcpci.c:295:16:    got restricted __le16
> tcpci.c:393:28: warning: incorrect type in assignment (different base types)
> tcpci.c:393:28:    expected restricted __le16 [usertype] header
> tcpci.c:393:28:    got unsigned int [unsigned] [addressable] reg
>
> fusb302.c:1028:32: warning: incorrect type in argument 1 (different base types)
> fusb302.c:1028:32:    expected unsigned short [unsigned] [usertype] header
> fusb302.c:1028:32:    got restricted __le16 const [usertype] header
> fusb302.c:1484:32: warning: incorrect type in argument 1 (different base types)
> fusb302.c:1484:32:    expected unsigned short [unsigned] [usertype] header
> fusb302.c:1484:32:    got restricted __le16 [usertype] header
>

Please the patch into two parts, one per file; the required changes
for endianness support in tcpci.c are much more complex.

> Signed-off-by: Guru Das Srinagesh <gurooodas@...il.com>
> ---
>  drivers/staging/typec/fusb302/fusb302.c | 4 ++--
>  drivers/staging/typec/tcpci.c           | 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c
> index 2cee9a9..9612ef1 100644
> --- a/drivers/staging/typec/fusb302/fusb302.c
> +++ b/drivers/staging/typec/fusb302/fusb302.c
> @@ -1025,7 +1025,7 @@ static int fusb302_pd_send_message(struct fusb302_chip *chip,
>         buf[pos++] = FUSB302_TKN_SYNC1;
>         buf[pos++] = FUSB302_TKN_SYNC2;
>
> -       len = pd_header_cnt(msg->header) * 4;
> +       len = pd_header_cnt(le16_to_cpu(msg->header)) * 4;

We have pd_header_cnt_le() for this purpose.

Yueyao, can you have a look into those changes for the fusb302 driver
? Is it safe to assume that we didn't hit a problem because the
hardware is little endian ?

>         /* plug 2 for header */
>         len += 2;
>         if (len > 0x1F) {
> @@ -1481,7 +1481,7 @@ static int fusb302_pd_read_message(struct fusb302_chip *chip,
>                                      (u8 *)&msg->header);
>         if (ret < 0)
>                 return ret;
> -       len = pd_header_cnt(msg->header) * 4;
> +       len = pd_header_cnt(le16_to_cpu(msg->header)) * 4;
>         /* add 4 to length to include the CRC */
>         if (len > PD_MAX_PAYLOAD * 4) {
>                 fusb302_log(chip, "PD message too long %d", len);
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 5e5be74..d0c22a7 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -287,12 +287,12 @@ static int tcpci_pd_transmit(struct tcpc_dev *tcpc,
>         unsigned int reg, cnt, header;
>         int ret;
>
> -       cnt = msg ? pd_header_cnt(msg->header) * 4 : 0;
> +       cnt = msg ? pd_header_cnt(le16_to_cpu(msg->header)) * 4 : 0;

pd_header_cnt_le()

>         ret = regmap_write(tcpci->regmap, TCPC_TX_BYTE_CNT, cnt + 2);
>         if (ret < 0)
>                 return ret;
>
> -       header = msg ? msg->header : 0;
> +       header = msg ? le16_to_cpu(msg->header) : 0;

Excellent catch, but the fix is wrong. We don't want to change the
endianness here, since the data is sent to the chip. This will require
a (much) more comprehensive fix - header should probably be le16, the
second parameter to tcpci_write16() needs to be le16, plus everything
that comes with it (currently the code is just not endianness clean).
tcpci_read16() is also incorrect and has the same problem (it is
really a bad idea to read 16 bit into an unsigned int pointer).

Let me know if you want to try to fix this; otherwise I'll do it.

Thanks,
Guenter

>         ret = tcpci_write16(tcpci, TCPC_TX_HDR, header);
>         if (ret < 0)
>                 return ret;
> @@ -390,7 +390,7 @@ static irqreturn_t tcpci_irq(int irq, void *dev_id)
>                 regmap_read(tcpci->regmap, TCPC_RX_BYTE_CNT, &cnt);
>
>                 tcpci_read16(tcpci, TCPC_RX_HDR, &reg);
> -               msg.header = reg;
> +               msg.header = cpu_to_le16(reg);
>
>                 if (WARN_ON(cnt > sizeof(msg.payload)))
>                         cnt = sizeof(msg.payload);
> --
> 2.7.4
>