[PATCH v2 3/4] fbmem: Fix input parameter checks for user-provided screen resolution changes

Helge Deller deller at gmx.de
Sat Jun 25 15:19:28 UTC 2022


On 6/25/22 14:56, Daniel Vetter wrote:
> On Sat, Jun 25, 2022 at 02:25:01PM +0200, Helge Deller wrote:
>> Enhance the checks in the FBIOPUT_VSCREENINFO ioctl handler to verify
>> the user-provided new screen size for:
>>
>> a) virtual screen size >= physical screen size, and
>>
>> b) new screen size is bigger than currently configured console font size.
>>
>> Return -EINVAL on invalid input.
>>
>> Signed-off-by: Helge Deller <deller at gmx.de>
>> Cc: stable at vger.kernel.org # v5.4+
>
> Imo squash this into the previous one please. Doesn't make sense to split
> the patch which adds a function from it's callsite.

I do disagree on this.
In my experience it's often much easier for backporting to have a patch which
provides a new generic function and the patches with the callers of it in seperate patches.

I'm not religious about this opinion here, so if you REALLY want it, I'll change
it. But personally I think this isn't a good idea and would prefer to leave it in seperate patches.

Helge


> -Daniel
>
>> ---
>>  drivers/video/fbdev/core/fbmem.c | 8 +++++++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
>> index afa2863670f3..50fb66b954d6 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -1106,7 +1106,13 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
>>  			return -EFAULT;
>>  		console_lock();
>>  		lock_fb_info(info);
>> -		ret = fb_set_var(info, &var);
>> +		if (var.xres_virtual < var.xres ||
>> +		    var.yres_virtual < var.yres)
>> +			ret = -EINVAL;
>> +		if (!ret)
>> +			ret = fbcon_modechange_possible(info, &var);
>> +		if (!ret)
>> +			ret = fb_set_var(info, &var);
>>  		if (!ret)
>>  			fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
>>  		unlock_fb_info(info);
>> --
>> 2.35.3
>>
>



More information about the dri-devel mailing list