netdev - Re: [PATCH] nfc: virtual_ncidev: Add variable to check if ndev is running

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: <9db5e25f-9fe1-45d9-9a3b-91c45c6cdddf@linaro.org>
Date: Mon, 20 Nov 2023 19:29:47 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Phi Nguyen <phind.uet@...il.com>, bongsu.jeon@...sung.com
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "syzbot+6eb09d75211863f15e3e@...kaller.appspotmail.com"
 <syzbot+6eb09d75211863f15e3e@...kaller.appspotmail.com>
Subject: Re: [PATCH] nfc: virtual_ncidev: Add variable to check if ndev is
 running

On 20/11/2023 19:23, Phi Nguyen wrote:
> On 11/20/2023 6:45 PM, Krzysztof Kozlowski wrote:
>> On 20/11/2023 11:39, Nguyen Dinh Phi wrote:
>>>>>>            mutex_lock(&vdev->mtx);
>>>>>>            kfree_skb(vdev->send_buff);
>>>>>>            vdev->send_buff = NULL;
>>>>>> +        vdev->running = false;
>>>>>>            mutex_unlock(&vdev->mtx);
>>>>>>    
>>>>>>            return 0;
>>>>>> @@ -50,7 +55,7 @@ static int virtual_nci_send(struct nci_dev *ndev, struct sk_buff *skb)
>>>>>>            struct virtual_nci_dev *vdev = nci_get_drvdata(ndev);
>>>>>>    
>>>>>>            mutex_lock(&vdev->mtx);
>>>>>> -        if (vdev->send_buff) {
>>>>>> +        if (vdev->send_buff || !vdev->running) {
>>>>>
>>>>> Dear Krzysztof,
>>>>>
>>>>> I agree this defensive code.
>>>>> But i think NFC submodule has to avoid this situation.(calling send function of closed nci_dev)
>>>>> Could you check this?
>>>>
>>>> This code looks not effective. At this point vdev->send_buff is always
>>>> false, so the additional check would not bring any value.
>>>>
>>>> I don't see this fixing anything. Syzbot also does not seem to agree.
>>>>
>>>> Nguyen, please test your patches against syzbot *before* sending them.
>>>> If you claim this fixes the report, please provide me the link to syzbot
>>>> test results confirming it is fixed.
>>>>
>>>> I looked at syzbot dashboard and do not see this issue fixed with this
>>>> patch.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>> Hi Krzysztof,
>>>
>>> I've submitted it to syzbot, it is the test request that created at
>>> [2023/11/20 09:39] in dashboard link
>>> https://syzkaller.appspot.com/bug?extid=6eb09d75211863f15e3e
>>
>> ...and I see there two errors.
>>
> These are because I sent email wrongly and syzbot truncates the patch 
> and can not compile
> 
>> I don't know, maybe I miss something obvious (our brains like to do it
>> sometimes), but please explain me how this could fix anything?
>>
>> Best regards,
>> Krzysztof
>>
> 
> The issue arises when an skb is added to the send_buff after invoking 
> ndev->ops->close() but before unregistering the device. In such cases, 
> the virtual device will generate a copy of skb, but with no consumer 
> thereafter. Consequently, this object persists indefinitely.
> 
> This problem seems to stem from the existence of time gaps between 
> ops->close() and the destruction of the workqueue. During this interval, 
> incoming requests continue to trigger the send function.

I asked how this could fix anything. Can you respond to my original comment?

Look:

>>>> This code looks not effective. At this point vdev->send_buff is always
>>>> false, so the additional check would not bring any value.

Best regards,
Krzysztof