linux-kernel - Re: [PATCH 1/2] i2c: designware: Only check the first byte for SMBus block read 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200615171508.GA2663@sultan-book.localdomain>
Date:   Mon, 15 Jun 2020 10:15:08 -0700
From:   Sultan Alsawaf <sultan@...neltoast.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Aaron Ma <aaron.ma@...onical.com>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Hans de Goede <hdegoede@...hat.com>,
        HungNien Chen <hn.chen@...dahitech.com>,
        Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
        Jiri Kosina <jikos@...nel.org>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>,
        linux-i2c <linux-i2c@...r.kernel.org>,
        linux-input <linux-input@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Pavel Balan <admin@...ma.net>, Tin Huynh <tnhuynh@....com>,
        Wolfram Sang <wsa@...nel.org>,
        You-Sheng Yang <vicamo.yang@...onical.com>
Subject: Re: [PATCH 1/2] i2c: designware: Only check the first byte for SMBus
 block read length

On Mon, Jun 15, 2020 at 07:07:42PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 15, 2020 at 7:06 PM Sultan Alsawaf <sultan@...neltoast.com> wrote:
> > On Mon, Jun 15, 2020 at 12:40:19PM +0300, Andy Shevchenko wrote:
> > > On Sun, Jun 14, 2020 at 02:02:54PM -0700, Sultan Alsawaf wrote:
> > > > From: Sultan Alsawaf <sultan@...neltoast.com>
> > > >
> > > > SMBus block reads can be broken because the read function will just skip
> > > > over bytes it doesn't like until reaching a byte that conforms to the
> > > > length restrictions for block reads. This is problematic when it isn't
> > > > known if the incoming payload is indeed a conforming block read.
> > > >
> > > > According to the SMBus specification, block reads will only send the
> > > > payload length in the first byte, so we can fix this by only considering
> > > > the first byte in a sequence for block read length purposes.
> > >
> > > I'm wondering if this overlaps with [1]. AFAIU that one is also makes sure that
> > > the length is not a garbage.
> > >
> > > [1]: https://lore.kernel.org/linux-i2c/20200613104109.2989-1-mans@mansr.com/T/#u
> >
> > No overlap.
> 
> Thanks for clarifying.
> 
> > That looks like a similar bug for a different driver. In my case,
> > the adapter provides native SMBus support, so emulation is never used. This is
> > clear to see by looking at i2c_transfer_buffer_flags(), which only uses the
> > master_xfer functions provided by the adapter; it doesn't call the emulation
> > path at all.
> 
> But do we get an advantage if this can be done in the i2c core instead
> (once for all)?

We can't, because the adapter driver needs to know mid-transfer to look for the
payload length in the first byte, and then alter the transfer size on-the-fly.
That can't be done in the i2c core, sadly. The problem is that we don't know if
a transfer is going to be a block read or not beforehand. And altering the
transfer size mid-transfer is definitely a controller specific task.

Sultan