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: <87wmk7vl38.fsf@kernel.org>
Date: Fri, 23 Aug 2024 08:56:11 +0300
From: Kalle Valo <kvalo@...nel.org>
To: Ma Ke <make24@...as.ac.cn>
Cc: dan.carpenter@...aro.org,  benjamin.berg@...el.com,
  daniel.gabay@...el.com,  gregory.greenman@...el.com,
  johannes.berg@...el.com,  linux-kernel@...r.kernel.org,
  linux-wireless@...r.kernel.org,  miriam.rachel.korenblit@...el.com
Subject: Re: [PATCH RESEND] wifi: iwlwifi: mvm: fix an error code in
 iwl_mvm_alloc_sta_after_restart()

Ma Ke <make24@...as.ac.cn> writes:

> Dan Carpenter<dan.carpenter@...aro.org> wrote:.
>> The Subject says RESEND but doesn't explain why you are resending..
>> You probably meant v2, but again it needs an explanation..
>> .
>> On Fri, Aug 02, 2024 at 12:27:40PM +0800, Ma Ke wrote:.
>> > This error path should return -EINVAL instead of success..
>> .
>> Why do you feel that way?  Have you tested it?  What is the user visible.
>> effect of this bug?.
>> .
>> I slightly feel hypocritical because I have send lots of commit messages.
>> with exactly this commit message.  The difference is that I only send.
>> really easy patches where it's obvious what the intent was.  A normal.
>> kernel developer wouldn't need to leave their email client or view any.
>> outside information to see that my patch is correct.  If a patch is not.
>> dead easy, I normally just report it.  (Sometimes I report dead easy.
>> bugs as well because I am lazy and maybe it's the end of my work day.
>> or whatever)..
>> .
>> This patch on the other hand is more subtle and it's not clear why the.
>> continue statements changed into returns..
>> .
>> regards,.
>> dan carpenter.
> Thank you for your response to the vulnerability I submitted. Yes, we .
> believe there is a similar issue. As described in [1], it gets pointers .
> which are handled under the protection mechanism. If the path is error, it .
> should return -EINVAL directly instead of success.

The commit message should explain _why_ it should return an error.
Currently there's no explanation neither in the commit message or in
your email.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
https://docs.kernel.org/process/submitting-patches.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ