linux-kernel - Re: [PATCH 09/12] i2c: qup: fix buffer overflow for multiple msg of maximum xfer len

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Mar 2018 17:58:11 +0530
From:   Abhishek Sahu <absahu@...eaurora.org>
To:     Andy Gross <andy.gross@...aro.org>
Cc:     Wolfram Sang <wsa@...-dreams.de>,
        David Brown <david.brown@...aro.org>,
        Sricharan R <sricharan@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/12] i2c: qup: fix buffer overflow for multiple msg of
 maximum xfer len

On 2018-02-28 04:45, Andy Gross wrote:
> On Sat, Feb 03, 2018 at 01:28:14PM +0530, Abhishek Sahu wrote:
>> The BAM mode requires buffer for start tag data and tx, rx SG
>> list. Currently, this is being taken for maximum transfer length
>> (65K). But an I2C transfer can have multiple messages and each
>> message can be of this maximum length so the buffer overflow will
>> happen in this case. Since increasing buffer length won’t be
>> feasible since an I2C transfer can contain any number of messages
>> so this patch does following changes to make i2c transfers working
>> for multiple messages case.
>> 
>> 1. Calculate the required buffers for 2 maximum length messages
>>    (65K * 2).
>> 2. Split the descriptor formation and descriptor scheduling.
>>    The idea is to fit as many messages in one DMA transfers for 65K
>>    threshold value (max_xfer_sg_len). Whenever the sg_cnt is
>>    crossing this, then schedule the BAM transfer and subsequent
>>    transfer will again start from zero.
>> 
>> Signed-off-by: Abhishek Sahu <absahu@...eaurora.org>
> 
> I'm ok with this patch.  I find the idea of a > 64k size message to be 
> something
> that usually wouldn't be encountered, but... with some eeproms and 
> maybe TPMs
> perhaps this could happen?
> 
> Reviewed-by: Andy Gross <andy.gross@...aro.org>

  Thanks Andy for reviewing this patch.

  There are EEPROM available with 1MB size like AT24CM01 in which we can 
read
  complete flash (128 KB) in single go by one transfer with 2 read 
messages of
  64KB.

  Thanks,
  Abhishek