Not at all, I can draft the new patch and resend. Thanks for all the useful discussion : ) On Wed, Feb 2, 2022 at 9:36 AM Helge Deller wrote: > On 2/2/22 18:27, Sam Ravnborg wrote: > > Hi Helge, > > > > On Tue, Feb 01, 2022 at 04:02:40PM +0100, Helge Deller wrote: > >> On 1/31/22 07:57, Yizhuo Zhai wrote: > >>> In function do_fb_ioctl(), the "arg" is the type of unsigned long, > >> > >> yes, because it comes from the ioctl framework... > >> > >>> and in "case FBIOBLANK:" this argument is casted into an int before > >>> passig to fb_blank(). > >> > >> which makes sense IMHO. > >> > >>> In fb_blank(), the comparision if (blank > FB_BLANK_POWERDOWN) would > >>> be bypass if the original "arg" is a large number, which is possible > >>> because it comes from the user input. > >> > >> The main problem I see with your patch is that you change the behaviour. > >> Let's assume someone passes in -1UL. > >> With your patch applied, this means the -1 (which is e.g. 0xffffffff on > 32bit) > >> is converted to a positive integer and will be capped to > FB_BLANK_POWERDOWN. > >> Since most blank functions just check and react on specific values, you > changed > >> the behaviour that the screen now gets blanked at -1, while it wasn't > before. > >> > >> One could now argue, that it's undefined behaviour if people > >> pass in wrong values, but anyway, it's different now. > > > > We should just plug this hole and in case an illegal value is passed > > then return -EINVAL. > > > > Acceptable values are FB_BLANK_UNBLANK..FB_BLANK_POWERDOWN, > > anything less than or greater than should result in -EINVAL. > > Yes, that's the best solution. > Yizhuo Zhai, would you mind to resend with that solution? > > Helge > > > We miss this kind or early checks in many places, and we see the effect > > of this in some drivers where they do it locally for no good. > > > > Sam > -- Kind Regards, *Yizhuo Zhai* *Computer Science, Graduate Student* *University of California, Riverside *