Re: [PATCH v4 06/13] platform/x86: bitland-mifs-wmi: use devm_blocking_notifier_chain_register()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Potential NULL pointer dereference in `bitland_mifs_wmi_notify()` when handling events for the CONTROL WMI device.
--

--- Patch [6]: [PATCH v4 06/13] platform/x86: bitland-mifs-wmi: use devm_blocking_notifier_chain_register() ---
commit b97b8d7c2a6f0ffd33788a7a075476a57a269e06
Author: Eliav Farber <farbere@amazon.com>

platform/x86: bitland-mifs-wmi: use devm_blocking_notifier_chain_register()

This commit simplifies the driver by replacing the combination of
blocking_notifier_chain_register() and devm_add_action_or_reset()
with a single call to devm_blocking_notifier_chain_register(). It
also removes the now-unused bitland_notifier_unregister() callback.

> diff --git a/drivers/platform/x86/bitland-mifs-wmi.c b/drivers/platform/x86/bitland-mifs-wmi.c
> index b0d06a80e89ef..576d6f3733b4c 100644
> --- a/drivers/platform/x86/bitland-mifs-wmi.c
> +++ b/drivers/platform/x86/bitland-mifs-wmi.c

[ ... ]

> @@ -721,13 +714,9 @@ static int bitland_mifs_wmi_probe(struct wmi_device *wdev, const void *context)
>  		return ret;
>  
>  	drv_data->notifier.notifier_call = bitland_notifier_callback;
> -	ret = blocking_notifier_chain_register(&bitland_notifier_list, &drv_data->notifier);
> -	if (ret)
> -		return ret;
> -
> -	return devm_add_action_or_reset(&wdev->dev,
> -				       bitland_notifier_unregister,
> -				       &drv_data->notifier);
> +	return devm_blocking_notifier_chain_register(&wdev->dev,
> +						     &bitland_notifier_list,
> +						     &drv_data->notifier);
>  }
>  
>  static void bitland_mifs_wmi_notify(struct wmi_device *wdev,

[Severity: High]
This is a pre-existing issue, but I noticed a potential NULL pointer 
dereference in the notification handler.

During bitland_mifs_wmi_probe(), data->input_dev is only allocated if the 
device type is BITLAND_WMI_EVENT. However, if firmware sends a hotkey 
event to the control device, bitland_mifs_wmi_notify() will run without 
checking if data->input_dev is actually allocated:

bitland_mifs_wmi_notify()
    ...
    case WMI_EVENT_OPEN_APP:
    case WMI_EVENT_CALCULATOR_START:
    case WMI_EVENT_BROWSER_START: {
        guard(mutex)(&data->lock);
        if (!sparse_keymap_report_event(data->input_dev,
                                        event->event_id, 1, true))

Could this cause a kernel panic in sparse_keymap_report_event() since it 
doesn't defensively check for a NULL input_dev?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260726101739.33170-1-farbere@amazon.com?part=6