Re: [PATCH v3 1/2] vhost: check for nr_vec == 0 in desc_to_mbuf, mbuf_to_desc

[Thomas Monjalon <thomas@monjalon.net>]

28/09/2022 17:21, Claudio Fontana:
> On 9/28/22 16:37, Maxime Coquelin wrote:
> > The title should be reworded, maybe something like below?
> > "vhost: fix possible out of bound access in buffer vectors"
> 
> possible, I leave it to you and other maintainers here now to figure out.

Maxime is suggesting a reword to you for your next version.

> > On 8/2/22 02:49, Claudio Fontana wrote:
[...]
> >> This should fix errors that have been reported in multiple occasions
> >> from telcos to the DPDK, OVS and QEMU projects, as this affects in
> >> particular the openvswitch/DPDK, QEMU vhost-user setup when the
> >> guest DPDK application abruptly goes away via SIGKILL and then
> >> reconnects.

What are the "multiple occasions"? Is there an entry in bugs.dpdk.org?

[...]
> > I'm going to try to reproduce the issue, but I'm not sure I will
> > succeed. Could you please share the Vhost logs when the issue is 
> > reproduced and you face the crash?
> 
> With vacations and lab work it's unlikely anything can be done from my side for the next 2-3 weeks.

We can probably wait 3 more weeks.

> This issue has been reported multiple times from multiple telco customers for about a year, it's all over the mailing lists
> between ovs, dpdk and qemu, with all the details.

What was the reply on the DPDK mailing list? Any link?

> Something in the governance of these Open Source projects is clearly not working right, probably too much inward-focus between a small number of companies, but I digress.

Contributors to DPDK are from multiple companies,
but I agree we may need more help.
Thank you for bringing your help with this fix.

> I think Chenbo Xia already knows the context, and I suspect this is now considered a "security issue". The problem is, the information about all of this has been public already for a year.

OK

> I will again repost how to reproduce here:

Thanks it helps to have all infos in the same place.

[...]

> > It is a fix, so it should contains the Fixes tag, and also cc
> > stable@dpdk.org.
> 
> After one year, it is time for Redhat and Intel or whatever the governance of this project is,

The DPDK governance is not owned by any company.
If you think there is an issue in a decision,
you can alert the Technical Board at techboard@dpdk.org.

> to mention if there is any intention to fix this or not,
> before I or anyone else at SUSE will invest any more of our time and efforts here.

I don't understand why we would not fix any issue.
I think the project is quite dynamic and fixing issues,
I am sorry if you have a different opinion.

> Any tags you need you can add as required.

It would be nice to add the tags as suggested in the next version.
The most important would be to know where the issue comes from.
If you can identify the original commit introducing the bug,
you can mark it with:
	Fixes: <commit-sha1> ("<commit-title>")
This way, maintainers and users know where it should be backported.

If any question, feel free to ask, we are here to help.
Thanks for the effort