netdev - Re: [benet] possible endianness bug in be_cmd_txq

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, 29 Jan 2018 13:03:49 +0530
From:   Sathya Perla <sathya.perla@...adcom.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Netdev <netdev@...r.kernel.org>,
        Vasundhara Volam <vasundhara.volam@...lex.com>,
        Sathya Perla <sathya.perla@...lex.com>,
        Suresh Kumar Reddy Reddygari <suresh.reddy@...adcom.com>
Subject: Re: [benet] possible endianness bug in be_cmd_txq_create()

On Sun, Dec 10, 2017 at 10:11 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> In be_cmd_txq_create() we have
>         if (req->hdr.version > 0)
>                 req->if_id = cpu_to_le16(adapter->if_handle);
>         req->num_pages = PAGES_4K_SPANNED(q_mem->va, q_mem->size);
>         req->ulp_num = BE_ULP1_NUM;
>         req->type = BE_ETH_TX_RING_TYPE_STANDARD;
>         req->cq_id = cpu_to_le16(cq->id);
>         req->queue_size = be_encoded_q_len(txq->len);
>         be_cmd_page_addrs_prepare(req->pages, ARRAY_SIZE(req->pages), q_mem);
>         ver = req->hdr.version;
>
...
>
> Everything appears to be consistent with little-endian data - direct
> assignments to u8 fields, cpu_to_le16 for cq_id and if_id, phys_addr
> array is also filled with little-endian data, so's ->hdr (several
> lines prior, by be_wrb_cmd_hdr_prepare()).
>
> The only exception is
>         req->type = BE_ETH_TX_RING_TYPE_STANDARD;
> where we set a 16bit field with host-endian constant (2).
>
..
>
> So it really smells like this line should've been
>         req->type = cpu_to_le16(BE_ETH_TX_RING_TYPE_STANDARD);
>
Sorry for replying late...I missed this mail. I guess the old
@emulex.com email ids don't work anymore -- it's @broadcom.com now!
Yes, this does look like a bug; we'll send a patch to fix this.

Thanks!