linux-kernel - Re: [PATCH] fbdev: fbmem: Fix the implicit type casting

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]

Date:   Wed, 2 Feb 2022 18:36:10 +0100
From:   Helge Deller <deller@....de>
To:     Sam Ravnborg <sam@...nborg.org>
Cc:     Yizhuo Zhai <yzhai003@....edu>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Matthew Wilcox <willy@...radead.org>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Alex Deucher <alexander.deucher@....com>,
        Zhen Lei <thunder.leizhen@...wei.com>,
        Zheyu Ma <zheyuma97@...il.com>,
        Xiyu Yang <xiyuyang19@...an.edu.cn>,
        linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fbdev: fbmem: Fix the implicit type casting

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