linux-kernel - Re: [PATCH] drm/meson: add check to prevent dereference of NULL

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAFBinCCW6E46+cMUC0M+n_4d7A6AhoJkQT=EHBxOD5wjn9O1hw@mail.gmail.com>
Date: Fri, 16 Aug 2024 21:55:37 +0200
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: Anastasia Belova <abelova@...ralinux.ru>
Cc: Neil Armstrong <neil.armstrong@...aro.org>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>, 
	Kevin Hilman <khilman@...libre.com>, Jerome Brunet <jbrunet@...libre.com>, 
	dri-devel@...ts.freedesktop.org, linux-amlogic@...ts.infradead.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	lvc-project@...uxtesting.org
Subject: Re: [PATCH] drm/meson: add check to prevent dereference of NULL

Hello Anastasia,

On Mon, Aug 12, 2024 at 11:32 AM Anastasia Belova <abelova@...ralinux.ru> wrote:
[...]
> > As an alternative to your suggested approach: could you please look
> > into whether devm_drm_dev_alloc() is a suitable replacement (if not:
> > just explain why - then this patch is good to be merged)?
>
> If I understood correctly, devm_drm_dev_alloc allows to delete drm_dev_put
> from error path in meson_drv_bind_master and in meson_drv_unbind.
Correct, that's the idea.

> Then the proposed check may be ommited and function may just return
> instead of jumping to free_drm.
That's right

> And would it be better to rename free_drm to remove_encoders?
That free_drm label is very confusing anyways.
The short answer is: yes
The longer answer is: we'll need to work on the removal order again:
- encoders are probed *after* afbcd
- removal should happen in opposite order of probe, so encoders should
be freed *before* afbcd
- however, this order is not implemented

There's no harm for you to rename the label now. It just means that we
need to do some more cleanups.

Looking forward to v2 of the patch!


Best regards,
Martin