CVE-2024-46693

In the Linux kernel, the following vulnerability has been resolved:

soc: qcom: pmic_glink: Fix race during initialization

As pointed out by Stephen Boyd it is possible that during initialization of the pmic_glink child drivers, the protection-domain notifiers fires, and the associated work is scheduled, before the client registration returns and as a result the local client pointer has been initialized.

The outcome of this is a NULL pointer dereference as the client pointer is blindly dereferenced.

Timeline provided by Stephen: CPU0 CPU1

ucsi->client = NULL; devm_pmic_glink_register_client() client->pdr_notify(client->priv, pg->client_state) pmic_glink_ucsi_pdr_notify() schedule_work(&ucsi->register_work) pmic_glink_ucsi_register() ucsi_register() pmic_glink_ucsi_read_version() pmic_glink_ucsi_read() pmic_glink_ucsi_read() pmic_glink_send(ucsi->client) ucsi->client = client // Too late!

This code is identical across the altmode, battery manager and usci child drivers.

Resolve this by splitting the allocation of the client object and the registration thereof into two operations.

This only happens if the protection domain registry is populated at the time of registration, which by the introduction of commit 1ebcde047c54 (soc: qcom: add pd-mapper implementation) became much more likely.

Weakness

A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.

Affected Software

Potential Mitigations

References

• https://git.kernel.org/stable/c/1efdbf5323c9360e05066049b97414405e94e087
• https://git.kernel.org/stable/c/3568affcddd68743e25aa3ec1647d9b82797757b
• https://git.kernel.org/stable/c/943b0e7cc646a624bb20a68080f8f1a4a55df41c