| Message ID | 20161123105213.27674-1-Liviu.Dudau@arm.com |
|---|---|
| State | New |
| Headers | show |
On Wed, 23 Nov 2016, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > drm_get_format_name() de-references the buf parameter without checking > if the pointer was not NULL. Given that the function is EXPORT-ed, lets > sanitise the parameters before proceeding. > > v2: Use BUG_ON() to annoy users that did not pass valid parameters to function. > > Fixes: b3c11ac267d461d3d5 ("drm: move allocation out of drm_get_format_name()) > Cc: Eric Engestrom <eric@engestrom.ch> > Cc: Rob Clark <robdclark@gmail.com> > Cc: Jani Nikula <jani.nikula@intel.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> > --- > I still think sanity checking the parameters of an exported function is worth > doing, even if the way one triggers the NULL pointer crash is priviledged. Not > a big fan of the verbosity of BUG_ON() and would rather silently reject NULL buf > pointer, but that is a matter of taste. There really is no meaningful difference between doing BUG_ON(!bug) vs. just letting buf->str oops. The kernel is full of functions that expect sensible pointers, and I don't see why this one in particular should be so special to warrant a BUG_ON(). BR, Jani. > > > drivers/gpu/drm/drm_fourcc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c > index 90d2cc8..6d80239 100644 > --- a/drivers/gpu/drm/drm_fourcc.c > +++ b/drivers/gpu/drm/drm_fourcc.c > @@ -85,6 +85,8 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format); > */ > const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf) > { > + BUG_ON(!buf); > + > snprintf(buf->str, sizeof(buf->str), > "%c%c%c%c %s-endian (0x%08x)", > printable_char(format & 0xff),
On Wed, Nov 23, 2016 at 01:00:07PM +0200, Jani Nikula wrote: > On Wed, 23 Nov 2016, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > > drm_get_format_name() de-references the buf parameter without checking > > if the pointer was not NULL. Given that the function is EXPORT-ed, lets > > sanitise the parameters before proceeding. > > > > v2: Use BUG_ON() to annoy users that did not pass valid parameters to function. > > > > Fixes: b3c11ac267d461d3d5 ("drm: move allocation out of drm_get_format_name()) > > Cc: Eric Engestrom <eric@engestrom.ch> > > Cc: Rob Clark <robdclark@gmail.com> > > Cc: Jani Nikula <jani.nikula@intel.com> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > > > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> > > --- > > I still think sanity checking the parameters of an exported function is worth > > doing, even if the way one triggers the NULL pointer crash is priviledged. Not > > a big fan of the verbosity of BUG_ON() and would rather silently reject NULL buf > > pointer, but that is a matter of taste. > > There really is no meaningful difference between doing BUG_ON(!bug) > vs. just letting buf->str oops. The kernel is full of functions that > expect sensible pointers, and I don't see why this one in particular > should be so special to warrant a BUG_ON(). Agree. That is why I prefer v1 where I return immediately on NULL pointers. Best regards, Liviu > > BR, > Jani. > > > > > > > drivers/gpu/drm/drm_fourcc.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c > > index 90d2cc8..6d80239 100644 > > --- a/drivers/gpu/drm/drm_fourcc.c > > +++ b/drivers/gpu/drm/drm_fourcc.c > > @@ -85,6 +85,8 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format); > > */ > > const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf) > > { > > + BUG_ON(!buf); > > + > > snprintf(buf->str, sizeof(buf->str), > > "%c%c%c%c %s-endian (0x%08x)", > > printable_char(format & 0xff), > > -- > Jani Nikula, Intel Open Source Technology Center > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, 23 Nov 2016, Daniel Vetter <daniel@ffwll.ch> wrote: > On Wed, Nov 23, 2016 at 11:23:23AM +0000, Liviu Dudau wrote: >> On Wed, Nov 23, 2016 at 01:00:07PM +0200, Jani Nikula wrote: >> > On Wed, 23 Nov 2016, Liviu Dudau <Liviu.Dudau@arm.com> wrote: >> > > drm_get_format_name() de-references the buf parameter without checking >> > > if the pointer was not NULL. Given that the function is EXPORT-ed, lets >> > > sanitise the parameters before proceeding. >> > > >> > > v2: Use BUG_ON() to annoy users that did not pass valid parameters to function. >> > > >> > > Fixes: b3c11ac267d461d3d5 ("drm: move allocation out of drm_get_format_name()) >> > > Cc: Eric Engestrom <eric@engestrom.ch> >> > > Cc: Rob Clark <robdclark@gmail.com> >> > > Cc: Jani Nikula <jani.nikula@intel.com> >> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> >> > > >> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> >> > > --- >> > > I still think sanity checking the parameters of an exported function is worth >> > > doing, even if the way one triggers the NULL pointer crash is priviledged. Not >> > > a big fan of the verbosity of BUG_ON() and would rather silently reject NULL buf >> > > pointer, but that is a matter of taste. >> > >> > There really is no meaningful difference between doing BUG_ON(!bug) >> > vs. just letting buf->str oops. The kernel is full of functions that >> > expect sensible pointers, and I don't see why this one in particular >> > should be so special to warrant a BUG_ON(). >> >> Agree. That is why I prefer v1 where I return immediately on NULL pointers. > > The question for v1 is why did you hit that? "broken driver code" isn't > really a good reason, au contraire it's a reason to not merge your patch: > We do not want to hide driver bugs silently. Moreover, v1 puts the burden back on the *caller* of the function to check for NULL return, while it previously could not even return NULL. The function is fine. It isn't broken. Don't try to fix it. BR, Jani. > > There's definitely cases where handling NULL automatically is reasonable, > e.g. kfree(). But a NULL drm_format_name_buf sounds like, at least a quick > grep shows that all callers just put this struct onto the stack. > -Daniel
On Wed, Nov 23, 2016 at 02:47:53PM +0200, Jani Nikula wrote: > On Wed, 23 Nov 2016, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Nov 23, 2016 at 11:23:23AM +0000, Liviu Dudau wrote: > >> On Wed, Nov 23, 2016 at 01:00:07PM +0200, Jani Nikula wrote: > >> > On Wed, 23 Nov 2016, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > >> > > drm_get_format_name() de-references the buf parameter without checking > >> > > if the pointer was not NULL. Given that the function is EXPORT-ed, lets > >> > > sanitise the parameters before proceeding. > >> > > > >> > > v2: Use BUG_ON() to annoy users that did not pass valid parameters to function. > >> > > > >> > > Fixes: b3c11ac267d461d3d5 ("drm: move allocation out of drm_get_format_name()) > >> > > Cc: Eric Engestrom <eric@engestrom.ch> > >> > > Cc: Rob Clark <robdclark@gmail.com> > >> > > Cc: Jani Nikula <jani.nikula@intel.com> > >> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > >> > > > >> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> > >> > > --- > >> > > I still think sanity checking the parameters of an exported function is worth > >> > > doing, even if the way one triggers the NULL pointer crash is priviledged. Not > >> > > a big fan of the verbosity of BUG_ON() and would rather silently reject NULL buf > >> > > pointer, but that is a matter of taste. > >> > > >> > There really is no meaningful difference between doing BUG_ON(!bug) > >> > vs. just letting buf->str oops. The kernel is full of functions that > >> > expect sensible pointers, and I don't see why this one in particular > >> > should be so special to warrant a BUG_ON(). > >> > >> Agree. That is why I prefer v1 where I return immediately on NULL pointers. > > > > The question for v1 is why did you hit that? "broken driver code" isn't > > really a good reason, au contraire it's a reason to not merge your patch: > > We do not want to hide driver bugs silently. I was updating a stashed series and discovered that signature of the function has changed. When I looked at how it changed and I got past the "you pass as a parameter a pointer to a struct that is used as a buffer and then that buffer is returned by function" weirdness, I thought that at least checking for bad parameters should be done. > > Moreover, v1 puts the burden back on the *caller* of the function to > check for NULL return, while it previously could not even return NULL. > > The function is fine. It isn't broken. Don't try to fix it. OK. I just like defensive programming, that's all. :) Best regards, Liviu > > BR, > Jani. > > > > > > > There's definitely cases where handling NULL automatically is reasonable, > > e.g. kfree(). But a NULL drm_format_name_buf sounds like, at least a quick > > grep shows that all callers just put this struct onto the stack. > > -Daniel > > -- > Jani Nikula, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c index 90d2cc8..6d80239 100644 --- a/drivers/gpu/drm/drm_fourcc.c +++ b/drivers/gpu/drm/drm_fourcc.c @@ -85,6 +85,8 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format); */ const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf) { + BUG_ON(!buf); + snprintf(buf->str, sizeof(buf->str), "%c%c%c%c %s-endian (0x%08x)", printable_char(format & 0xff),
drm_get_format_name() de-references the buf parameter without checking if the pointer was not NULL. Given that the function is EXPORT-ed, lets sanitise the parameters before proceeding. v2: Use BUG_ON() to annoy users that did not pass valid parameters to function. Fixes: b3c11ac267d461d3d5 ("drm: move allocation out of drm_get_format_name()) Cc: Eric Engestrom <eric@engestrom.ch> Cc: Rob Clark <robdclark@gmail.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> --- I still think sanity checking the parameters of an exported function is worth doing, even if the way one triggers the NULL pointer crash is priviledged. Not a big fan of the verbosity of BUG_ON() and would rather silently reject NULL buf pointer, but that is a matter of taste. drivers/gpu/drm/drm_fourcc.c | 2 ++ 1 file changed, 2 insertions(+)