linux-kernel - Re: [Intel-gfx] [PATCH] drm/i915/display: Check source height is

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] [day] [month] [year] [list]

Message-ID: <cb28a1e1-b9fb-a4a2-9b03-47bb34b16aa1@gmail.com>
Date:   Fri, 13 Jan 2023 13:06:18 +0200
From:   Juha-Pekka Heikkila <juhapekka.heikkila@...il.com>
To:     Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        Drew Davenport <ddavenport@...omium.org>
Cc:     dri-devel@...ts.freedesktop.org,
        Thomas Zimmermann <tzimmermann@...e.de>,
        intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Daniel Vetter <daniel@...ll.ch>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        David Airlie <airlied@...il.com>,
        Juha-Pekka Heikkilä 
        <juha-pekka.heikkila@...el.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Check source height is > 0

On 12.1.2023 20.28, Ville Syrjälä wrote:
> On Mon, Dec 26, 2022 at 10:53:24PM -0700, Drew Davenport wrote:
>> The error message suggests that the height of the src rect must be at
>> least 1. Reject source with height of 0.
>>
>> Signed-off-by: Drew Davenport <ddavenport@...omium.org>
>>
>> ---
>> I was investigating some divide-by-zero crash reports on ChromeOS which
>> pointed to the intel_adjusted_rate function. Further prodding showed
>> that I could reproduce this in a simple test program if I made src_h
>> some value less than 1 but greater than 0.
>>
>> This seemed to be a sensible place to check that the source height is at
>> least 1. I tried to repro this issue on an amd device I had on hand, and
>> the configuration was rejected.
>>
>> Would it make sense to add a check that source dimensions are at least 1
>> somewhere in core, like in drm_atomic_plane_check? Or is that a valid
>> use case on some devices, and thus any such check should be done on a
>> per-driver basis?
>>
>> Thanks.
>>
>>   drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c
>> index 4b79c2d2d6177..9b172a1e90deb 100644
>> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
>> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
>> @@ -1627,7 +1627,7 @@ static int skl_check_main_surface(struct intel_plane_state *plane_state)
>>   	u32 offset;
>>   	int ret;
>>   
>> -	if (w > max_width || w < min_width || h > max_height) {
>> +	if (w > max_width || w < min_width || h > max_height || h < 1) {
> 
> I liked this one best so pushed to drm-intel-next with cc:stable. Thanks.
> 
> In the future we might want to move some of these checks to an earlier
> spot to make sure we don't hit any other weird issues in some other
> code, but for the moment I think this will do.
> 

Look ok to me. Tests which I had written to try different ways to cause 
this issue are now returning einval as expected. I'll polish my igt test 
for this issue and send it out bit later.

/Juha-pekka

>>   		drm_dbg_kms(&dev_priv->drm,
>>   			    "requested Y/RGB source size %dx%d outside limits (min: %dx1 max: %dx%d)\n",
>>   			    w, h, min_width, max_width, max_height);
>> -- 
>> 2.39.0.314.g84b9a713c41-goog
>