Loading
nfc: pn533: Add poll mod list filling check
stable inclusion from stable-v6.6.49 commit 56ad559cf6d87f250a8d203b555dfc3716afa946 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAR4F8 CVE: CVE-2024-46676 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id= ... -------------------------------- [ Upstream commit febccb39255f9df35527b88c953b2e0deae50e53 ] In case of im_protocols value is 1 and tm_protocols value is 0 this combination successfully passes the check 'if (!im_protocols && !tm_protocols)' in the nfc_start_poll(). But then after pn533_poll_create_mod_list() call in pn533_start_poll() poll mod list will remain empty and dev->poll_mod_count will remain 0 which lead to division by zero. Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFC_CMD_START_POLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->poll_mod_count is not incremented inside pn533_poll_create_mod_list(), thus leading to division by zero. Call trace looks like: nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll() Add poll mod list filling check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: dfccd0f5 ("NFC: pn533: Add some polling entropy") Signed-off-by:Aleksandr Mishin <amishin@t-argos.ru> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20240827084822.18785-1-amishin@t-argos.ru Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Lin Ruifeng <linruifeng4@huawei.com>