lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.2303281404360.1142@cbobk.fhfr.pm>
Date:   Tue, 28 Mar 2023 14:04:44 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Tanu Malhotra <tanu.malhotra@...el.com>
cc:     srinivas.pandruvada@...ux.intel.com, linux-input@...r.kernel.org,
        linux-kernel@...r.kernel.org, even.xu@...el.com,
        stable@...r.kernel.org, Shaunak Saha <shaunak.saha@...el.com>
Subject: Re: [PATCH v2] HID: intel-ish-hid: Fix kernel panic during warm
 reset

On Mon, 27 Mar 2023, Tanu Malhotra wrote:

> During warm reset device->fw_client is set to NULL. If a bus driver is
> registered after this NULL setting and before new firmware clients are
> enumerated by ISHTP, kernel panic will result in the function
> ishtp_cl_bus_match(). This is because of reference to
> device->fw_client->props.protocol_name.
> 
> ISH firmware after getting successfully loaded, sends a warm reset
> notification to remove all clients from the bus and sets
> device->fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel
> module drivers were loaded right after any of the first ISHTP device was
> registered, regardless of whether it was a matched or an unmatched
> device. This resulted in all drivers getting registered much before the
> warm reset notification from ISH.
> 
> Starting kernel v5.16, this issue got exposed after the change was
> introduced to load only bus drivers for the respective matching devices.
> In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are
> registered after the warm reset device fw_client NULL setting.
> cros_ec_ishtp driver_register() triggers the callback to
> ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel
> panic in guid_equal() when dereferencing fw_client NULL pointer to get
> protocol_name.
> 
> Fixes: f155dfeaa4ee ("platform/x86: isthp_eclite: only load for matching devices")
> Fixes: facfe0a4fdce ("platform/chrome: chros_ec_ishtp: only load for matching devices")
> Fixes: 0d0cccc0fd83 ("HID: intel-ish-hid: hid-client: only load for matching devices")
> Fixes: 44e2a58cb880 ("HID: intel-ish-hid: fw-loader: only load for matching devices")
> Cc: <stable@...r.kernel.org> # 5.16+
> Signed-off-by: Tanu Malhotra <tanu.malhotra@...el.com>
> Tested-by: Shaunak Saha <shaunak.saha@...el.com>
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>

Applied, thank you.

-- 
Jiri Kosina
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ