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

[Maxime Coquelin]

On 9/28/22 18:03, Thomas Monjalon wrote:
> 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.

Yes please, because I fail to reproduce it (Fc35 on host, Ubuntu 18.05
in guest).

What I can see is that on guest testpmd crash, the host backend receives
VHOST_USER_GET_VRING_BASE requests that stop the vring processing. on
reconnect, the rings start to be processed only when it received all the
configuration requests from QEMU.

Note that I have tested it with VFIO in the guest because I could not
find the uio_pci_generic module in Ubuntu 18.04 cloud image.

>> 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?

Please provide the links, it may help to understand the root cause if
these mail threads contain logs.

> 
>> 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 at 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 at 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
> 
>