CVE-2024-46693

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: pmic_glink: Fix race during initialization<br /> <br /> As pointed out by Stephen Boyd it is possible that during initialization<br /> of the pmic_glink child drivers, the protection-domain notifiers fires,<br /> and the associated work is scheduled, before the client registration<br /> returns and as a result the local "client" pointer has been initialized.<br /> <br /> The outcome of this is a NULL pointer dereference as the "client"<br /> pointer is blindly dereferenced.<br /> <br /> Timeline provided by Stephen:<br /> CPU0 CPU1<br /> ---- ----<br /> ucsi-&gt;client = NULL;<br /> devm_pmic_glink_register_client()<br /> client-&gt;pdr_notify(client-&gt;priv, pg-&gt;client_state)<br /> pmic_glink_ucsi_pdr_notify()<br /> schedule_work(&amp;ucsi-&gt;register_work)<br /> <br /> pmic_glink_ucsi_register()<br /> ucsi_register()<br /> pmic_glink_ucsi_read_version()<br /> pmic_glink_ucsi_read()<br /> pmic_glink_ucsi_read()<br /> pmic_glink_send(ucsi-&gt;client)<br /> <br /> ucsi-&gt;client = client // Too late!<br /> <br /> This code is identical across the altmode, battery manager and usci<br /> child drivers.<br /> <br /> Resolve this by splitting the allocation of the "client" object and the<br /> registration thereof into two operations.<br /> <br /> This only happens if the protection domain registry is populated at the<br /> time of registration, which by the introduction of commit &amp;#39;1ebcde047c54<br /> ("soc: qcom: add pd-mapper implementation")&amp;#39; became much more likely.