linux-kernel - Re: [PATCH v1] i2c: designware: Handle invalid SMBus block data response length

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: <d560c9b0-d2cf-18da-3470-a51468413955@linux.intel.com>
Date:   Mon, 5 Jun 2023 10:41:18 +0300
From:   Jarkko Nikula <jarkko.nikula@...ux.intel.com>
To:     Tam Chi Nguyen <tamnguyenchi@...eremail.onmicrosoft.com>,
        Tam Nguyen <tamnguyenchi@...amperecomputing.com>,
        linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org
Cc:     patches@...erecomputing.com, andriy.shevchenko@...ux.intel.com,
        mika.westerberg@...ux.intel.com, jsd@...ihalf.com,
        chuong@...amperecomputing.com, darren@...amperecomputing.com,
        stable@...r.kernel.org
Subject: Re: [PATCH v1] i2c: designware: Handle invalid SMBus block data
 response length

Hi

On 6/2/23 07:30, Tam Chi Nguyen wrote:
> Hi Jarkko,
> 
> Before pushing the v2 patch, I have one more question to ask.
> 
> The commit f53f15ba5a85 ("i2c: designware: Get right data length"), you 
> mentioned,
> does not handle bit 11 set (on a HW where it's supported) correctly.
> "tmp" was not marked with DW_IC_DATA_CMD_DAT when passing to 
> i2c_dw_recv_len function.
> 
> So I plan to update it in the v2 patch by adding this
>      regmap_read(dev->map, DW_IC_DATA_CMD, &tmp);
>      tmp &= DW_IC_DATA_CMD_DAT;
> 
> My question is: does it need a separate patch for this change?
> 
I think for now bit 11 gets masked since tmp variable is assigned to u8 
variables when calling i2c_dw_recv_len() and writing to *buf pointer but 
your proposal indeed makes code more robust both your patch point of 
view or any other future change. So separate patch makes sense in my 
opinion.