[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0f20cd6a-d9aa-4837-a120-1e2e7dbdc954@redhat.com>
Date: Mon, 13 Oct 2025 09:37:29 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jason Wang <jasowang@...hat.com>,
syzbot <syzbot+ac856b8b866cca41352c@...kaller.appspotmail.com>
Cc: eperezma@...hat.com, linux-kernel@...r.kernel.org, mst@...hat.com,
syzkaller-bugs@...glegroups.com, virtualization@...ts.linux.dev,
xuanzhuo@...ux.alibaba.com
Subject: Re: [syzbot] [virt?] upstream test error: KMSAN: use-after-free in
vring_map_one_sg
On 10/13/25 9:20 AM, Jason Wang wrote:
> On Mon, Oct 13, 2025 at 1:29 PM Jason Wang <jasowang@...hat.com> wrote:
>> On Sat, Oct 11, 2025 at 3:40 PM Jason Wang <jasowang@...hat.com> wrote:
>>>
>>> #syz test
>>>
>>> On Sat, Oct 11, 2025 at 4:38 AM syzbot
>>> <syzbot+ac856b8b866cca41352c@...kaller.appspotmail.com> wrote:
>>
>> Paolo, it looks like the GSO tunnel features will leave uninitialized
>> vnet header field which trigger KMSAN warning.
>>
>> Please have a look at the patch (which has been tested by syzbot) or
>> propose another one.
>
> Forget the attachment.
I have a few questions. The report mentions both UaF and uninit; the
patch addresses "just" the uninit access. It's not clear to me if and
how the UaF is addressed, and why/if it's related to the uninit access.
Do you know better?
It looks like the uninit root cause is on "the other side"? i.e. the
device not initializing properly the header. Would unconditionally
clearing the hash info implicitly disable such feature?
The syzbot dashboard mentions a (no more available) reproducer. Do you
have it cached somewhere?
Thanks,
Paolo
Powered by blists - more mailing lists