+3
−0
+1
−0
+42
−7
Loading
stable inclusion from stable-v6.6.66 commit 2da32aed4a97ca1d70fb8b77926f72f30ce5fb4b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBIFR8 CVE: CVE-2024-47141 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2da32aed4a97ca1d70fb8b77926f72f30ce5fb4b -------------------------------- [ Upstream commit 5a3e85c3c397c781393ea5fb2f45b1f60f8a4e6e ] When two client of the same gpio call pinctrl_select_state() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner. Let's say two processes A, B executing in pin_request() for the same pin and process A updates the desc->mux_usecount but not yet updated the desc->mux_owner while process B see the desc->mux_usecount which got updated by A path and further executes strcmp and while accessing desc->mux_owner it crashes with NULL pointer. Serialize the access to mux related setting with a mutex lock. cpu0 (process A) cpu1(process B) pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) { if (desc->mux_usecount > 1) return 0; desc->mux_owner = owner; } } Signed-off-by:Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/20241014192930.1539673-1-quic_mojha@quicinc.com Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Conflicts: drivers/pinctrl/pinmux.c [ Scope-based resource management is not merged yet (54da6a09), so we lock the data-race region by hand ] Signed-off-by:
Zhang Kunbo <zhangkunbo@huawei.com>