Dan Carpenter<dan.carpenter@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ -- Regards, Ma Ke
