在 2021/4/20 下午8:35, Xuan Zhuo 写道:
I realize this has been merged to net-next already, but I'm getting a
use-after-free with KASAN in page_to_skb() with this patch. Reverting this
change fixes the UAF. I've included the KASAN dump below, and a couple of
comments inline.
I think something went wr
For split virtqueue, we used to depend on the address, length and
flags stored in the descriptor ring for DMA unmapping. This is unsafe
for the case when we don't trust the device since the device can tries
to manipulate the behavior of virtio driver and swiotlb.
For safety, maintain the DMA addre
Using error label for unwind in __vring_new_virtqueue. This is useful
for future refacotring.
Signed-off-by: Jason Wang
---
drivers/virtio/virtio_ring.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
inde
This patch introduces a helper for storing descriptor in the
descriptor table for split virtqueue.
Signed-off-by: Jason Wang
---
drivers/virtio/virtio_ring.c | 39 ++--
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/
We should not depend on the DMA address, length and flag of descriptor
table since they could be wrote with arbitrary value by the device. So
this patch switches to use the stored one in desc_extra.
Note that the indirect descriptors are fine since they are read-only
streaming mappings.
Signed-of
A helper is introduced for the logic of allocating the descriptor
extra data. This will be reused by split virtqueue.
Signed-off-by: Jason Wang
---
drivers/virtio/virtio_ring.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/virtio/vir
Rename vring_desc_extra_packed to vring_desc_extra since the structure
are pretty generic which could be reused by split virtqueue as well.
Signed-off-by: Jason Wang
---
drivers/virtio/virtio_ring.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/virtio/vir
This patch moves next from vring_desc_state_packed to
vring_desc_desc_extra_packed. This makes it simpler to let extra state
to be reused by split virtqueue.
Signed-off-by: Jason Wang
---
drivers/virtio/virtio_ring.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --g
Hi All:
Sometimes, the driver doesn't trust the device. This is usually
happens for the encrtpyed VM or VDUSE[1]. In both cases, technology
like swiotlb is used to prevent the poking/mangling of memory from the
device. But this is not sufficient since current virtio driver may
trust what is stored
在 2021/4/21 上午4:01, Eric Dumazet 写道:
From: Eric Dumazet
build_skb() is supposed to be followed by
skb_reserve(skb, NET_IP_ALIGN), so that IP headers are word-aligned.
(Best practice is to reserve NET_IP_ALIGN+NET_SKB_PAD, but the NET_SKB_PAD
part is only a performance optimization if tunnel en
在 2021/4/20 下午5:43, Eric Dumazet 写道:
From: Eric Dumazet
KASAN/syzbot had 4 reports, one of them being:
BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191
[inline]
BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70
drivers/net/virtio_net.c:480
Read of size 12
On Tue, Apr 20, 2021 at 01:01:44PM -0700, Eric Dumazet wrote:
> From: Eric Dumazet
>
> build_skb() is supposed to be followed by
> skb_reserve(skb, NET_IP_ALIGN), so that IP headers are word-aligned.
> (Best practice is to reserve NET_IP_ALIGN+NET_SKB_PAD, but the NET_SKB_PAD
> part is only a per
From: Eric Dumazet
build_skb() is supposed to be followed by
skb_reserve(skb, NET_IP_ALIGN), so that IP headers are word-aligned.
(Best practice is to reserve NET_IP_ALIGN+NET_SKB_PAD, but the NET_SKB_PAD
part is only a performance optimization if tunnel encaps are added.)
Unfortunately virtio_n
On Mon, Apr 19, 2021 at 05:08:48PM +0200, Greg Kurz wrote:
> Even if POSIX doesn't mandate it, linux users legitimately expect
> sync() to flush all data and metadata to physical storage when it
> is located on the same system. This isn't happening with virtiofs
> though : sync() inside the guest r
On 4/20/21 7:51 PM, Guenter Roeck wrote:
>
> sh does indeed fail, with the same symptoms as before, but so far I was not
> able to track it down to a specific commit. The alpha failure is different,
> though. It is a NULL pointer access.
>
> Anyway, testing ...
>
> The patch below does indee
On 4/20/21 9:31 AM, Eric Dumazet wrote:
> On Tue, Apr 20, 2021 at 5:42 PM Guenter Roeck wrote:
>>
>> On Tue, Apr 20, 2021 at 04:00:07PM +0200, Eric Dumazet wrote:
>>> On Tue, Apr 20, 2021 at 3:48 PM Guenter Roeck wrote:
On 4/20/21 2:43 AM, Eric Dumazet wrote:
>>>
>
Unfortu
Hi
Am 20.04.21 um 18:56 schrieb Takashi Iwai:
On bochs DRM driver, the execution of "setterm --blank force" results
in a frozen screen instead of a blank screen. It's due to the lack of
the screen blanking support in its code.
Actually, the QEMU bochs vga side can switch to the blanking mode w
On Tue, 20 Apr 2021 06:08:29 -0400
"Michael S. Tsirkin" wrote:
> On Tue, Apr 20, 2021 at 08:01:29AM +0100, Christoph Hellwig wrote:
> > Just to despit my 2 cents again: I think the way this is specified
> > in the virtio spec is actively harmful and we should not suport it in
> > Linux.
> >
> >
On Tue, Apr 20, 2021 at 04:00:07PM +0200, Eric Dumazet wrote:
> On Tue, Apr 20, 2021 at 3:48 PM Guenter Roeck wrote:
> >
> > On 4/20/21 2:43 AM, Eric Dumazet wrote:
>
> > >
> >
> > Unfortunately that doesn't fix the problem for me. With this patch applied
> > on top of next-20210419, I still get
On 4/20/21 2:43 AM, Eric Dumazet wrote:
> From: Eric Dumazet
>
> KASAN/syzbot had 4 reports, one of them being:
>
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191
> [inline]
> BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70
> drivers/net/virtio_net.c:480
On Tue, Apr 20, 2021 at 11:16:09AM +0200, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> On Tue, Apr 20, 2021 at 10:46 AM Daniel Vetter wrote:
> > On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote:
> > > On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann
> > > wrote:
> > > > This p
As reported by syzbot [1], there is a memory leak while closing the
socket. We partially solved this issue with commit ac03046ece2b
("vsock/virtio: free packets during the socket release"), but we
forgot to drain the RX queue when the socket is definitely closed by
the scheduled work.
To avoid fut
On Tue, Apr 20, 2021 at 08:01:29AM +0100, Christoph Hellwig wrote:
> Just to despit my 2 cents again: I think the way this is specified
> in the virtio spec is actively harmful and we should not suport it in
> Linux.
>
> If others override me we at least need to require a detailed
> documentation
On Tue, Apr 20, 2021 at 02:43:41AM -0700, Eric Dumazet wrote:
> From: Eric Dumazet
>
> KASAN/syzbot had 4 reports, one of them being:
>
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191
> [inline]
> BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70
> drivers
From: Eric Dumazet
KASAN/syzbot had 4 reports, one of them being:
BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191
[inline]
BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70
drivers/net/virtio_net.c:480
Read of size 12 at addr 888014a5f800 by task systemd
On 4/20/21 6:46 AM, Guenter Roeck wrote:
> On Wed, Apr 14, 2021 at 09:52:21AM +0800, Xuan Zhuo wrote:
>> In page_to_skb(), if we have enough tailroom to save skb_shared_info, we
>> can use build_skb to create skb directly. No need to alloc for
>> additional space. And it can save a 'frags slot',
On 4/16/21 11:16 AM, Xuan Zhuo wrote:
> In page_to_skb(), if we have enough tailroom to save skb_shared_info, we
> can use build_skb to create skb directly. No need to alloc for
> additional space. And it can save a 'frags slot', which is very friendly
> to GRO.
>
> Here, if the payload of the
Hi Gerd,
On Tue, Apr 20, 2021 at 11:22 AM Gerd Hoffmann wrote:
> > > > Patches 4 to 8 add the simpledrm driver. It's build on simple DRM
> > > > helpers
> > > > and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers.
> > > > During
> > >
> > > if support for 8-bit frame buffers
Hi,
> > > Patches 4 to 8 add the simpledrm driver. It's build on simple DRM helpers
> > > and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During
> >
> > if support for 8-bit frame buffers would be added?
>
> Is that 8-bit greyscale or 8-bit indexed with 256 entry palett
Hi Daniel,
On Tue, Apr 20, 2021 at 10:46 AM Daniel Vetter wrote:
> On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote:
> > On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann
> > wrote:
> > > This patchset adds support for simple-framebuffer platform devices and
> > > a handover
On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote:
> Hi Thomas,
>
> On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann
> wrote:
> > This patchset adds support for simple-framebuffer platform devices and
> > a handover mechanism for native drivers to take-over control of the
> >
Just to despit my 2 cents again: I think the way this is specified
in the virtio spec is actively harmful and we should not suport it in
Linux.
If others override me we at least need to require a detailed
documentation of these fields as the virto spec does not provide it.
Please also do not add
32 matches
Mail list logo