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]
Date:	Wed, 21 Jul 2010 11:06:15 +0400
From:	"Alexander Y. Fomichev" <git.user@...il.com>
To:	Alex Deucher <alexdeucher@...il.com>
Cc:	Dave Airlie <airlied@...hat.com>, Robert Noland <rnoland@...p.net>,
	Matt Turner <mattst88@...il.com>,
	Jerome Glisse <jglisse@...hat.com>, akpm@...ux-foundation.org,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: drivers/gpu/drm/radeon/r600_blit.c: fix possible NULL pointer 
	derefernce

On Wed, Jul 21, 2010 at 1:29 AM, Alex Deucher <alexdeucher@...il.com> wrote:
> On Tue, Jul 20, 2010 at 5:07 PM, Alexander Y. Fomichev
> <git.user@...il.com> wrote:
>> On Wed, Jul 21, 2010 at 1:00 AM, Alex Deucher <alexdeucher@...il.com> wrote:
>>> On Tue, Jul 20, 2010 at 4:13 PM, Alexander Y. Fomichev
>>> <git.user@...il.com> wrote:
>>>> On Tue, Jul 20, 2010 at 9:37 PM, Alex Deucher <alexdeucher@...il.com> wrote:
>>>>> On Mon, Jul 19, 2010 at 5:42 PM, Alexander Y. Fomichev
>>>>> <git.user@...il.com> wrote:
>>>>>> This patch fix possible NULL pointer dereference when
>>>>>> r600_prepare_blit_copy tries to fill dev_priv->blit_vb->file_priv
>>>>>> without check of dev_priv->blit_vb. dev_priv->blit_vb should be
>>>>>> filled by r600_nomm_get_vb but latest can fail with EAGAIN.
>>>>>> Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=16375
>>>>>>
>>>>>> ---
>>>>>>  drivers/gpu/drm/radeon/r600_blit.c |    2 ++
>>>>>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/radeon/r600_blit.c b/drivers/gpu/drm/radeon/r600_blit.c
>>>>>> index f4fb88e..0df4a2b 100644
>>>>>> --- a/drivers/gpu/drm/radeon/r600_blit.c
>>>>>> +++ b/drivers/gpu/drm/radeon/r600_blit.c
>>>>>> @@ -541,6 +541,8 @@ r600_prepare_blit_copy(struct drm_device *dev, struct drm_file *file_priv)
>>>>>>        DRM_DEBUG("\n");
>>>>>>
>>>>>>        r600_nomm_get_vb(dev);
>>>>>> +       if (!dev_priv->blit_vb)
>>>>>> +               return;
>>>>>
>>>>> r600_prepare_blit_copy returns an int so something like this would be better:
>>>>> --- a/drivers/gpu/drm/radeon/r600_blit.c
>>>>> +++ b/drivers/gpu/drm/radeon/r600_blit.c
>>>>> @@ -539,8 +539,10 @@ r600_prepare_blit_copy(struct drm_device *dev,
>>>>> struct drm_file *file_priv)
>>>>>  {
>>>>>        drm_radeon_private_t *dev_priv = dev->dev_private;
>>>>>        DRM_DEBUG("\n");
>>>>> +       int ret = r600_nomm_get_vb(dev);
>>>>>
>>>>> -       r600_nomm_get_vb(dev);
>>>>> +       if (ret)
>>>>> +               return ret;
>>>>>
>>>>>        dev_priv->blit_vb->file_priv = file_priv;
>>>>>
>>>>>
>>>>> Alex
>>>>>
>>>>>>
>>>>>>        dev_priv->blit_vb->file_priv = file_priv;
>>>>>>
>>>>>> --
>>>>>> 1.7.1.1
>>>>>>
>>>>>
>>>>
>>>> i haven't any preferneces, the only thing is - it would be logical
>>>> to have every check in common style, so other cases
>>>> (r600_blit_copy, r600_blit_swap) should be fixed, nop?
>>>
>>> Those are void functions so there's nothing to return.
>>
>> i mean both of them call r600_nomm_get_vb and both of them
>> check if (!dev_priv->blit_vb), not return  value.I mean would be
>> logical to check it the same way everytime r600_nomm_get_vb
>> gets called.
>
> yeah, either way.  You just need to return an error in r600_prepare_blit_copy.
uh-huh, i've missed

> Alex
>
>>
>>> Alex
>>>
>>>>
>>>> --
>>>> Best regards.
>>>>        Alexander Y. Fomichev <git.user@...il.com>
>>>>
>>>
>>
>>
>>
>> --
>> Best regards.
>>        Alexander Y. Fomichev <git.user@...il.com>
>>
>


-- 
Best regards.
       Alexander Y. Fomichev <git.user@...il.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ