linux-kernel - Re: [PATCH 2/3] drm/tests: edid: Update CTA-861 HDMI Vendor Specific Data Block

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: <94c88860a39219dc29075d4c8f2ec351c7ce25f6@intel.com>
Date: Mon, 28 Jul 2025 11:37:18 +0300
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Thomas Zimmermann <tzimmermann@...e.de>, Maxime Ripard <mripard@...nel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, David Airlie
 <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Dmitry Baryshkov
 <lumag@...nel.org>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] drm/tests: edid: Update CTA-861 HDMI Vendor
 Specific Data Block

On Wed, 16 Jul 2025, Thomas Zimmermann <tzimmermann@...e.de> wrote:
> Hi
>
> Am 16.07.25 um 17:06 schrieb Maxime Ripard:
>> Hi Thomas,
>>
>> On Mon, Jul 14, 2025 at 01:02:33PM +0200, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 25.06.25 um 17:14 schrieb Maxime Ripard:
>>>> For some reason, the HDMI VSDBs in our kunit EDIDs had a length longer
>>>> than expected.
>>>>
>>>> While this was harmless, we should get rid of it to make it somewhat
>>>> predictable.
>>> Dump question: should these errors be kept in another test specifically for
>>> detecting this problem?
>> I'm not entirely sure what you mean here, sorry. Did you mean that we
>> should get some tests to prevent that kind of EDIDs from being accepted
>> by the kernel?
>>
>> If so, I guess it would mean getting a test suite for the EDID parser
>> itself, which is definitely something that should happen at some point
>> but seems a little out of scope to me.
>
> OK. I meant that these are ill-formed EDIDs and the kernel's EDID 
> processing should handle them gracefully. A test could verify this. Not 
> a blocker for this series, of course.

Going through old mails... I'll note that EDIDs in general contain so
much garbage that we simply can't reject them if there are issues. They
do need to be handled gracefully, of course.

BR,
Jani.


-- 
Jani Nikula, Intel