linux-kernel - Re: [PATCH] net: ieee802154: fix error return code of dgram

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: <44ee06c9-b99c-8758-a045-ea7d17a6dbf3@gmail.com>
Date:   Mon, 8 Mar 2021 14:33:47 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Jia-Ju Bai <baijiaju1990@...il.com>
Cc:     linux-wpan@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, alex.aring@...il.com,
        davem@...emloft.net, kuba@...nel.org, stefan@...enfreihafen.org
Subject: Re: [PATCH] net: ieee802154: fix error return code of dgram_sendmsg()

On 08.03.2021 13:18, Jia-Ju Bai wrote:
> 
> 
> On 2021/3/8 18:19, Heiner Kallweit wrote:
>> On 08.03.2021 10:31, Jia-Ju Bai wrote:
>>> When sock_alloc_send_skb() returns NULL to skb, no error return code of
>>> dgram_sendmsg() is assigned.
>>> To fix this bug, err is assigned with -ENOMEM in this case.
>>>
>> Please stop sending such nonsense. Basically all such patches you
>> sent so far are false positives. You have to start thinking,
>> don't blindly trust your robot.
>> In the case here the err variable is populated by sock_alloc_send_skb().
> 
> Ah, sorry, it is my fault :(
> I did not notice that the err variable is populated by sock_alloc_send_skb().
> I will think more carefully before sending patches.
> 
> By the way, I wonder how to report and discuss possible bugs that I am not quite sure of?
> Some people told me that sending patches is better than reporting bugs via Bugzilla, so I write the patches of these possible bugs...
> Do you have any advice?
> 

If you're quite sure that something is a bug then sending a patch is fine.
Your submissions more or less all being false positives shows that this
takes more than just forwarding bot findings, especially if you have no
idea yet regarding the quality of the bot.
Alternatively you can contact the maintainer and respective mailing list.
But again, maintainers typically are very busy and you should have done
all you can to analyze the suspected bug.

What I'd do being in your shoes:
Take the first 10 findings of a new bot and analyze in detail whether
findings are correct or false positives. Of course this means you
need to get familiar with the affected code in the respective driver.
If false positive ratio is > 5% I wouldn't send out patches w/o more
detailed analysis per finding.

Worst case a maintainer is busy and can't review your submission in time,
and the incorrect fix is applied and breaks the driver.
Typically this shouldn't happen however because Dave/Jakub won't apply
a patch w/o Ack from the respective maintainer.

Disclaimer:
I can only speak for myself. Other maintainers may see this differently.

> Thanks a lot!
> 
> 
> Best wishes,
> Jia-Ju Bai
>>
>>> Fixes: 78f821b64826 ("ieee802154: socket: put handling into one file")
>>> Reported-by: TOTE Robot <oslab@...nghua.edu.cn>
>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@...il.com>
>>> ---
>>>   net/ieee802154/socket.c | 4 +++-
>>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
>>> index a45a0401adc5..a750b37c7e73 100644
>>> --- a/net/ieee802154/socket.c
>>> +++ b/net/ieee802154/socket.c
>>> @@ -642,8 +642,10 @@ static int dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
>>>       skb = sock_alloc_send_skb(sk, hlen + tlen + size,
>>>                     msg->msg_flags & MSG_DONTWAIT,
>>>                     &err);
>>> -    if (!skb)
>>> +    if (!skb) {
>>> +        err = -ENOMEM;
>>>           goto out_dev;
>>> +    }
>>>         skb_reserve(skb, hlen);
>>>  
>