CVE-2024-35977

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/chrome: cros_ec_uart: properly fix race condition<br /> <br /> The cros_ec_uart_probe() function calls devm_serdev_device_open() before<br /> it calls serdev_device_set_client_ops(). This can trigger a NULL pointer<br /> dereference:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> Call Trace:<br /> <br /> ...<br /> ? ttyport_receive_buf<br /> <br /> A simplified version of crashing code is as follows:<br /> <br /> static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl,<br /> const u8 *data,<br /> size_t count)<br /> {<br /> struct serdev_device *serdev = ctrl-&gt;serdev;<br /> <br /> if (!serdev || !serdev-&gt;ops-&gt;receive_buf) // CRASH!<br /> return 0;<br /> <br /> return serdev-&gt;ops-&gt;receive_buf(serdev, data, count);<br /> }<br /> <br /> It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev-&gt;ops<br /> will also exist. This conflicts with the existing cros_ec_uart_probe()<br /> logic, as it first calls devm_serdev_device_open() (which sets<br /> SERPORT_ACTIVE), and only later sets serdev-&gt;ops via<br /> serdev_device_set_client_ops().<br /> <br /> Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race<br /> condition") attempted to fix a similar race condition, but while doing<br /> so, made the window of error for this race condition to happen much<br /> wider.<br /> <br /> Attempt to fix the race condition again, making sure we fully setup<br /> before calling devm_serdev_device_open().