Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] mhi/sahara: UAF due to missing cancel_work_sync(read_data_work) --
commit db3ce9303033a085ebf1250fe283d48253b7c50d Author: Kishore Batta <[email protected]> bus: mhi: Load DDR training data using device serial number Extend the firmware loading logic for the DDR training image to first attempt loading a per-device image dervied from the device serial number. If the serial-specific image is not present, fall back to the existing default image, preserving current behavior. This allows reuse of previously generated DDR training data when available. > diff --git a/drivers/bus/mhi/host/clients/sahara/sahara.c > b/drivers/bus/mhi/host/clients/sahara/sahara.c > index a4b3ef197b303..62b9c72e82680 100644 > --- a/drivers/bus/mhi/host/clients/sahara/sahara.c > +++ b/drivers/bus/mhi/host/clients/sahara/sahara.c > @@ -58,6 +58,7 @@ > #define SAHARA_RESET_LENGTH 0x8 > #define SAHARA_MEM_DEBUG64_LENGTH 0x18 > #define SAHARA_MEM_READ64_LENGTH 0x18 > +#define SAHARA_DDR_TRAINING_IMG_ID 34 > > struct sahara_packet { > __le32 cmd; [ ... ] [Severity: High] Does driver teardown miss cancelling the read_data_work? Looking at sahara_mhi_remove(): drivers/bus/mhi/host/clients/sahara/sahara.c:sahara_mhi_remove() { ... cancel_work_sync(&context->fw_work); cancel_work_sync(&context->dump_work); vfree(context->mem_dump); ... } If the MHI device is unbound or hot-unplugged while a Sahara READ_DATA streaming operation is active, read_data_work can be scheduled or already running. Since sahara_mhi_remove() omits cancelling read_data_work, when remove() returns, the devres framework will automatically free the context structure allocated via devm_kzalloc(). Can the uncancelled read_data_work then dereference the freed context structure and cause a use-after-free? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/20261013-sahara_protocol_new_v2-v9-0-dc9f24357...@oss.qualcomm.com?part=5
