linux-kernel - Re: [PATCH 2/2] i2c: virtio: fix completion handling

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: <a6cb9ae7-eee3-74aa-87de-a2be3fdc7a76@intel.com>
Date:   Thu, 21 Oct 2021 13:55:31 +0800
From:   Jie Deng <jie.deng@...el.com>
To:     Vincent Whitchurch <vincent.whitchurch@...s.com>, wsa@...nel.org,
        viresh.kumar@...aro.org
Cc:     virtualization@...ts.linux-foundation.org,
        linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel@...s.com
Subject: Re: [PATCH 2/2] i2c: virtio: fix completion handling


On 2021/10/19 15:46, Vincent Whitchurch wrote:
> The driver currently assumes that the notify callback is only received
> when the device is done with all the queued buffers.
>
> However, this is not true, since the notify callback could be called
> without any of the queued buffers being completed (for example, with
> virtio-pci and shared interrupts) or with only some of the buffers being
> completed (since the driver makes them available to the device in
> multiple separate virtqueue_add_sgs() calls).


Can the backend driver control the time point of interrupt injection ? I 
can't think of

why the backend has to send an early interrupt. This operation should be 
avoided

in the backend driver if possible. However, this change make sense if 
early interrupt

can't be avoid.


>
> This can lead to incorrect data on the I2C bus or memory corruption in
> the guest if the device operates on buffers which are have been freed by
> the driver.  (The WARN_ON in the driver is also triggered.)
>