Re: [PATCH v3] arm64: dts: qcom: shikra: Add BAM-DMUX support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] dts: qcom: bam_dmux_pool shares BAM DMA descriptors with untrusted modem
- [High] dts: qcom: bam_dmux driver ignores qcom,vmid, leading to SMMU/XPU faults
--

commit 29cefe6f8087e49778891d714bb8fb329002f944
Author: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>

arm64: dts: qcom: shikra: Add BAM-DMUX support

Add the SMSM state entries, BAM-DMUX node, and BAM DMA controller needed
to provide modem data channels on Shikra. Reserve a 256 KiB restricted
DMA pool and reference it from both the BAM-DMUX and BAM DMA nodes.

> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index 92d22e3b6931c..4980c125b7e1a 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -352,6 +353,13 @@ reserved_memory: reserved-memory {
>  		#size-cells = <2>;
>  		ranges;
>  
> +		bam_dmux_pool: restricted-dma-pool {
> +			compatible = "restricted-dma-pool";
> +			size = <0x0 0x40000>;
> +			alignment = <0x0 0x40000>;
> +			alloc-ranges = <0x0 0x80000000 0x0 0x80000000>;
> +		};
> +

[ ... ]

> @@ -1866,6 +1891,20 @@ glink-edge {
>  				qcom,remote-pid = <1>;
>  				label = "mpss";
>  			};
> +
> +			bam_dmux: bam-dmux {
> +				compatible = "qcom,bam-dmux";
> +				interrupt-parent = <&modem_smsm>;
> +				interrupts = <1 IRQ_TYPE_EDGE_BOTH>,
> +					     <11 IRQ_TYPE_EDGE_BOTH>;
> +				interrupt-names = "pc", "pc-ack";
> +				qcom,smem-states = <&apps_smsm 1>, <&apps_smsm 11>;
> +				qcom,smem-state-names = "pc", "pc-ack";
> +				dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
> +				dma-names = "tx", "rx";
> +				memory-region = <&bam_dmux_pool>;
> +				qcom,vmid = <QCOM_SCM_VMID_NAV>;

[Severity: High]
Does the BAM-DMUX driver actually parse and use this property?

The host BAM-DMUX driver (drivers/net/wwan/qcom_bam_dmux.c) does not appear to
parse qcom,vmid or invoke the necessary Qualcomm SCM calls to configure the
hardware memory protection.

Will this cause SMMU or XPU memory protection faults when the modem attempts
to read or write its buffers, since the driver fails to grant the modem the
necessary access to the DMA pool?

> +			};
>  		};

[ ... ]

> @@ -2026,6 +2065,18 @@ dispcc: clock-controller@5f00000 {
>  			#power-domain-cells = <1>;
>  		};
>  
> +		bam_dmux_dma: dma-controller@6044000 {
> +			compatible = "qcom,bam-v1.7.0";
> +			reg = <0x0 0x06044000 0x0 0x19000>;
> +			interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING 0>;
> +			#dma-cells = <1>;
> +			qcom,ee = <0>;
> +			num-channels = <6>;
> +			qcom,num-ees = <1>;
> +			qcom,powered-remotely;
> +			memory-region = <&bam_dmux_pool>;

[Severity: Critical]
Is it safe to share bam_dmux_pool between the modem and the BAM DMA
descriptors?

The commit message notes that this shared pool provides space for the BAM
descriptor FIFOs. By linking this pool to the bam_dmux node above, the design
aims to grant the untrusted modem access to the entire pool.

Because the bam_dmux_dma controller uses physical addresses, if the modem
overwrites the address field of a DMA descriptor within this shared pool, will
the BAM DMA controller blindly execute DMA operations on the forged address?

Could this allow a compromised modem to read or write arbitrary host memory?

> +		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260920-qcom-shikra-dts-bam-dmux-v3-1-91474d507d61@oss.qualcomm.com?part=1