similar to: [PATCH] drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes

> In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() > is assigned to mode, which will lead to a possible NULL pointer > dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. A) Can a wording approach (like the following) be a better change description? A null pointer is stored in the local variable ?mode? after a call of the function

Ma Ke - I assume you already know but you can just ignore this message from Markus as it is just spam. Sorry about the trouble! Markus, you've already been asked by Greg so I will ask a bit more sternly in case there is actually a person on the other end: you've already been asked to stop by Greg and are being ignored by multiple kernel maintainers. If I keep seeing messages like this

On Wed, 26 Jun 2024, Ma Ke <make24 at iscas.ac.cn> wrote: > In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() > is assigned to mode, which will lead to a possible NULL pointer > dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. > > Signed-off-by: Ma Ke <make24 at iscas.ac.cn> > --- >

Reviewed-by: Lyude Paul <lyude at redhat.com> Will push this upstream in just a moment, thanks! On Thu, 2024-06-27 at 10:27 +0800, Ma Ke wrote: > In nouveau_connector_get_modes(), the return value of > drm_mode_duplicate() > is assigned to mode, which will lead to a possible NULL pointer > dereference on failure of drm_mode_duplicate(). Add a check to avoid > npd. > >

> In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is > assigned to mode, which will lead to a possible NULL pointer dereference > on failure of drm_mode_duplicate(). Add a check to avoid npd. Can a wording approach (like the following) be a better change description? A null pointer is stored in the local variable ?mode? after a call of the function

In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Signed-off-by: Ma Ke <make_ruc2021 at 163.com> --- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c

https://bugs.freedesktop.org/show_bug.cgi?id=28626 Summary: Oops: kernel NULL pointer dereference in nouveau_connector_get_modes Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau

Reviewed-by: Lyude Paul <lyude at redhat.com> On Tue, 2024-06-25 at 16:18 +0800, Ma Ke wrote: > In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() > is > assigned to mode, which will lead to a possible NULL pointer > dereference > on failure of drm_mode_duplicate(). Add a check to avoid npd. > > Cc: stable at vger.kernel.org > Signed-off-by: Ma Ke

> In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is > assigned to mode, which will lead to a possible NULL pointer dereference > on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). > Add a check to avoid null pointer dereference. Can a wording approach (like the following) be a better change description? A null pointer is stored in the local

> (...I doubt I'll get a response from Markus, Why? > but I certainly want to > make sure they are a bot Can I ever adjust your views into more desirable directions (as it occasionally happened with other contributors)? > and not an actual person before removing them I hope still that affected development

On Fri, 2024-06-28 at 20:42 +0200, Markus Elfring wrote: > > (...I doubt I'll get a response from Markus, > > Why? Because the responses you have been given read like a bot, and numerous actual contributors and kernel maintainers like myself and Greg have asked you to stop leaving messages like this and you continue sending them. I promise you, maintainers are more then capable

> Because the responses you have been given read like a bot, I find it interesting that you interpret provided information in such a direction. > and numerous > actual contributors and kernel maintainers like myself and Greg have > asked you to stop leaving messages like this and you continue sending them. I hope still that

In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference. Signed-off-by: Ma Ke <make_ruc2021 at 163.com> --- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++++ 1 file changed, 4 insertions(+)

Reviewed-by: Lyude Paul <lyude at redhat.com> I will push this and the other patch that you sent upstream in just a moment, thanks! On Tue, 2024-06-25 at 16:10 +0800, Ma Ke wrote: > In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() > is > assigned to mode, which will lead to a possible NULL pointer > dereference > on failure of drm_mode_duplicate(). The

The original commit adding that check tried to protect the kenrel against a potential invalid NULL pointer access. However we call nouveau_connector_detect_depth once without a native_mode set on purpose for non LVDS connectors and this broke DP support in a few cases. Cc: Olaf Skibbe <news at kravcenko.com> Cc: Lyude Paul <lyude at redhat.com> Closes:

https://bugs.freedesktop.org/show_bug.cgi?id=105173 Pierre Moreau <pierre.morrow at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|With kernel >=4.15 nouveau |[MCP79][Regression] |- artefacts and freezes |Unhandled NULL pointer

https://bugs.freedesktop.org/show_bug.cgi?id=105173 Pierre Moreau <pierre.morrow at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[MCP79][Regression] |[MCP79][Regression] |Unhandled NULL pointer |Unhandled NULL pointer

If output is NULL it is not permissable to dereference it. So we should leave the respective function in this case. The inconsistency was indicated by cppcheck. No actual NULL pointer dereference was observed. Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

If output is NULL it is not permissable to dereference it. So we should leave the respective function in this case. The inconsistency was indicated by cppcheck. No actual NULL pointer dereference was observed. Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

https://bugs.freedesktop.org/show_bug.cgi?id=105173 --- Comment #12 from Nick Lee <nvlbox at gmail.com> --- > The NULL pointer dereference, or the “trapped read at 0080000000 on channel 1 > [0fbb0000 DRM] engine 00 [PGRAPH] client 03 [DISPATCH] subclient 04 [M2M_IN] > reason 00000006 [NULL_DMAOBJ]” one? "NULL pointer dereference" AND "trapped read" after