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

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

[Linkui Xiao]

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.

Linkui Xiao (2):
  devlink: param: do not dereference a missing param item
  devlink: sb: do not dereference a missing shared buffer

 net/devlink/param.c | 3 ++-
 net/devlink/sb.c    | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.25.1

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

[Linkui Xiao]

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.

Linkui Xiao (2):
  devlink: param: do not dereference a missing param item
  devlink: sb: do not dereference a missing shared buffer

 net/devlink/param.c | 3 ++-
 net/devlink/sb.c    | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.25.1