[PATCH] phy: exynos5-usbdrd: Use dynamic phy_cfg size to prevent OOB access

Alim Akhtar alim.akhtar at samsung.com
Mon Sep 14 22:53:58 PDT 2026


Hi Selvarasu

> -----Original Message-----
> From: Selvarasu Ganesan <selvarasu.g at samsung.com>
> Sent: Monday, August 31, 2026 12:33 PM
> To: vkoul at kernel.org; neil.armstrong at linaro.org; krzk at kernel.org;
> peter.griffin at linaro.org; alim.akhtar at samsung.com;
> pritam.sutar at samsung.com; andre.draszik at linaro.org; kernel at lvkasz.us;
> linux-phy at lists.infradead.org; linux-arm-kernel at lists.infradead.org; linux-
> samsung-soc at vger.kernel.org; linux-kernel at vger.kernel.org
> Cc: jh0801.jung at samsung.com; dh10.jung at samsung.com;
> akash.m5 at samsung.com; muhammed.ali at samsung.com;
> thiagu.r at samsung.com; Selvarasu Ganesan <selvarasu.g at samsung.com>
> Subject: [PATCH] phy: exynos5-usbdrd: Use dynamic phy_cfg size to prevent
> OOB access
> 
> The probe loop currently iterates using EXYNOS5_DRDPHYS_NUM (2),
> creating both UTMI and PIPE3 PHY instances regardless of the SoC capability.
> Several SoCs (Exynos2200, Exynos7870, Exynos850, Exynos990, and
> ExynosAutoV920) provide phy_cfg arrays containing only a single element.
> 
> On these SoCs, when the loop reaches index 1, the driver reads past the end
> of the rodata array, populating the second PHY instance with garbage data.
> Since the configuration structure contains critical function pointers (phy_isol,
> phy_init, set_refclk), any subsequent access to this PHY instance via
> exynos5_usbdrd_phy_xlate could result in a kernel oops.
> 
> Fix this by adding 'n_phy_cfg' to struct exynos5_usbdrd_phy_drvdata to
> store the actual size of the phy_cfg array for each SoC. Update the probe
> loop and the xlate function to bound their access against this value instead of
> the hardcoded EXYNOS5_DRDPHYS_NUM.
> 
> Assisted-by: Claude:claude-sonnet-5
> Signed-off-by: Selvarasu Ganesan <selvarasu.g at samsung.com>
> ---
Reviewed-by: Alim Akhtar <alim.akhtar at samsung.com>




More information about the linux-arm-kernel mailing list