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]
Message-ID: <87lhgcix4s.fsf@intel.com>
Date:	Mon, 25 May 2015 16:50:59 +0300
From:	Jani Nikula <jani.nikula@...ux.intel.com>
To:	Andrey Ryabinin <a.ryabinin@...sung.com>,
	David Airlie <airlied@...ux.ie>
Cc:	Ander Conselvan de Oliveira 
	<ander.conselvan.de.oliveira@...el.com>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] drm/atomic: fix out of bounds read in for_each_*_in_state helpers

On Mon, 25 May 2015, Andrey Ryabinin <a.ryabinin@...sung.com> wrote:
> On 05/25/2015 04:12 PM, Jani Nikula wrote:
>> On Mon, 25 May 2015, Andrey Ryabinin <a.ryabinin@...sung.com> wrote:
>>> for_each_*_in_state validate array index after
>>> access to array elements, thus perform out of bounds read.
>>>
>>> Fix this by validating index in the first place and read
>>> array element iff validation was successful.
>>>
>>> Fixes: df63b9994eaf ("drm/atomic: Add for_each_{connector,crtc,plane}_in_state helper macros")
>>> Signed-off-by: Andrey Ryabinin <a.ryabinin@...sung.com>
>>> ---
>>>  include/drm/drm_atomic.h | 24 ++++++++++++------------
>>>  1 file changed, 12 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
>>> index c1571034..3f13b91 100644
>>> --- a/include/drm/drm_atomic.h
>>> +++ b/include/drm/drm_atomic.h
>>> @@ -77,26 +77,26 @@ int __must_check drm_atomic_async_commit(struct drm_atomic_state *state);
>>>  
>>>  #define for_each_connector_in_state(state, connector, connector_state, __i) \
>>>  	for ((__i) = 0;							\
>>> -	     (connector) = (state)->connectors[__i],			\
>>> -	     (connector_state) = (state)->connector_states[__i],	\
>>> -	     (__i) < (state)->num_connector;				\
>>> +	     (__i) < (state)->num_connector &&				\
>>> +	     ((connector) = (state)->connectors[__i],			\
>>> +	     (connector_state) = (state)->connector_states[__i], 1); 	\
>> 
>> This will stop at the first NULL connector/connector_state. Similarly
>> for the loops below.
>> 
>
> This will stop iff (__i) >= (state)->num_connector, because the result of expression:
> 	 ((connector) = (state)->connectors[__i], (connector_state) = (state)->connector_states[__i], 1)
> is always 1.

Why do you think it'll always be 1?

BR,
Jani.


>
>

-- 
Jani Nikula, Intel Open Source Technology Center
--
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