On 29/08/2024 10:26, Paolo Abeni wrote:
On 8/27/24 10:48, Aleksandr Mishin wrote:
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: dfccd0f58044 ("NFC: pn533: Add some polling entropy")
Signed-off-by: Aleksandr Mishin <amishin@xxxxxxxxxx>
The issue looks real to me and the proposed fix the correct one, but
waiting a little more for Krzysztof feedback, as he expressed concerns
on v1.
There was one month delay between my reply and clarifications from
Fedor, so original patch is neither in my mailbox nor in my brain.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
However different problem is: shouldn't as well or instead
nfc_genl_start_poll() validate the attributes received by netlink?
We just pass them directly to the drivers and several other drivers
might not expect random stuff there.