CVE-2025-71285

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: Drop the MHI auto_queue feature for IPCR DL channels<br /> <br /> MHI stack offers the &amp;#39;auto_queue&amp;#39; feature, which allows the MHI stack to<br /> auto queue the buffers for the RX path (DL channel). Though this feature<br /> simplifies the client driver design, it introduces race between the client<br /> drivers and the MHI stack. For instance, with auto_queue, the &amp;#39;dl_callback&amp;#39;<br /> for the DL channel may get called before the client driver is fully probed.<br /> This means, by the time the dl_callback gets called, the client driver&amp;#39;s<br /> structures might not be initialized, leading to NULL ptr dereference.<br /> <br /> Currently, the drivers have to workaround this issue by initializing the<br /> internal structures before calling mhi_prepare_for_transfer_autoqueue().<br /> But even so, there is a chance that the client driver&amp;#39;s internal code path<br /> may call the MHI queue APIs before mhi_prepare_for_transfer_autoqueue() is<br /> called, leading to similar NULL ptr dereference. This issue has been<br /> reported on the Qcom X1E80100 CRD machines affecting boot.<br /> <br /> So to properly fix all these races, drop the MHI &amp;#39;auto_queue&amp;#39; feature<br /> altogether and let the client driver (QRTR) manage the RX buffers manually.<br /> In the QRTR driver, queue the RX buffers based on the ring length during<br /> probe and recycle the buffers in &amp;#39;dl_callback&amp;#39; once they are consumed. This<br /> also warrants removing the setting of &amp;#39;auto_queue&amp;#39; flag from controller<br /> drivers.<br /> <br /> Currently, this &amp;#39;auto_queue&amp;#39; feature is only enabled for IPCR DL channel.<br /> So only the QRTR client driver requires the modification.