cve/2024/CVE-2024-42319.md

### [CVE-2024-42319](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-42319)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=623a6143a845%3C%201403991a40b9%20&color=brighgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=brighgreen)

### Description

In the Linux kernel, the following vulnerability has been resolved:mailbox: mtk-cmdq: Move devm_mbox_controller_register() after devm_pm_runtime_enable()When mtk-cmdq unbinds, a WARN_ON message with conditionpm_runtime_get_sync() < 0 occurs.According to the call tracei below:  cmdq_mbox_shutdown  mbox_free_channel  mbox_controller_unregister  __devm_mbox_controller_unregister  ...The root cause can be deduced to be calling pm_runtime_get_sync() aftercalling pm_runtime_disable() as observed below:1. CMDQ driver uses devm_mbox_controller_register() in cmdq_probe()   to bind the cmdq device to the mbox_controller, so   devm_mbox_controller_unregister() will automatically unregister   the device bound to the mailbox controller when the device-managed   resource is removed. That means devm_mbox_controller_unregister()   and cmdq_mbox_shoutdown() will be called after cmdq_remove().2. CMDQ driver also uses devm_pm_runtime_enable() in cmdq_probe() after   devm_mbox_controller_register(), so that devm_pm_runtime_disable()   will be called after cmdq_remove(), but before   devm_mbox_controller_unregister().To fix this problem, cmdq_probe() needs to movedevm_mbox_controller_register() after devm_pm_runtime_enable() to makedevm_pm_runtime_disable() be called afterdevm_mbox_controller_unregister().

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/fkie-cad/nvd-json-data-feeds