linux-kernel - Re: [PATCH RESEND] wifi: iwlwifi: mvm: fix an error code in iwl_mvm_alloc_sta_after

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

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 discovery of this 
problem was confirmed through manual review of the code and compilation 
testing. And by the way, I resent the patch because I hadn’t received a 
reply for a long time, so I resent it.

[1] https://lore.kernel.org/all/MW5PR11MB58102E1897D7437CD8E1DF27A3DDA@MW5PR11MB5810.namprd11.prod.outlook.com/

--
Regards,

Ma Ke