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