Re: [PATCH net 0/2] devlink: do not dereference a missing param item or shared buffer

[Simon Horman <horms@kernel.org>]

On Mon, Nov 02, 2026 at 09:12:16PM +0800, Linkui Xiao wrote:
> Hi Simon,
> 
> thanks for the review.
> 
> On 2026/11/2 20:05, Simon Horman wrote:
> > On Fri, Oct 30, 2026 at 11:33:30AM +0800, Linkui Xiao wrote:
> > > From: Linkui Xiao <xiaolinkui@kylinos.cn>
> > > 
> > > Two devlink helpers look an object up by id or index, warn when the
> > > lookup fails, and then pass the NULL result to code that dereferences
> > > it. A driver mistake (a param_id that was never registered, an sb_index
> > > that was never registered or is unregistered twice) therefore costs an
> > > oops instead of a warning.
> > > 
> > >    1/2 param: devl_param_value_changed() hands the missing param item to
> > >        devlink_param_notify() -> devlink_nl_param_fill(), whose first
> > >        statement dereferences param_item->param.
> > > 
> > >    2/2 sb: devl_sb_unregister() runs list_del() on the missing shared
> > >        buffer; list is the first member of struct devlink_sb, so it
> > >        reads and writes through address 0.
> > > 
> > > In both cases every other user of the same lookup already returns right
> > > after the warning, so the fixes just align the remaining callers; there
> > > is no change of behavior beyond avoiding the dereference. The param side
> > > follows the example Jiri set for devlink_param_unregister():
> > > 
> > > Link: https://lore.kernel.org/all/20230126075838.1643665-5-jiri@resnulli.us/
> > > 
> > > Both Fixes: tags point at the commits that introduced the unguarded
> > > WARN_ON pattern; the current devl_() functions are pure renames of those
> > > originals. No in-tree caller triggers either path today (the audit is
> > > part of a defensive hardening pass), so both are aimed at stopping
> > > out-of-tree drivers from turning a driver bug into an oops.
> > 
> > Thanks, both these fixes look good to me.
> > 
> > But I do wonder if the hardening aspect, from an in-tree pov,
> > makes them net-next rather than net material.
> > 
> > I say that, because my understanding is that there is some pressure
> > to only push critical bug fixes via net. This is because of the recent
> > up-tick in bug fixes driven by AI-related activities.
> 
> Agreed -- net-next is open now, so I have just resent this as
> [PATCH net-next v2 0/2]. Only the prefix and the base changed: the two
> hunks,
> the Fixes: tags and the commit messages are the ones you reviewed, and the
> Reviewed-by tags from v1 are kept. Neither patch carries a Cc: stable, so
> there is nothing to drop with the new target.

Thanks, much appreciated.