netdev - 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] [day] [month] [year] [list]

Date:   Mon, 8 Mar 2021 21:49:32 +0800
From:   Jia-Ju Bai <baijiaju1990@...il.com>
To:     Heiner Kallweit <hkallweit1@...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 2021/3/8 21:33, Heiner Kallweit wrote:
> 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.

Okay, thanks a lot for the very helpful advice :)
I will carefully check the bug report and try my best to write correct 
patches.


Best wishes,
Jia-Ju Bai