* [linux-nfc] Re: ST ST95HF DRIVER security bug
[not found] <CAAMXCFnzLX-yWKSJ5JoBxcE8E0=cSQeDExGoFBxhkusUNeYncg@mail.gmail.com>
@ 2022-08-24 12:08 ` Krzysztof Kozlowski
[not found] ` <CAAMXCF=15tSmz7=nzVRgw166wDmMGiBuLx6Of-NLvboMN3nAuQ@mail.gmail.com>
0 siblings, 1 reply; 2+ messages in thread
From: Krzysztof Kozlowski @ 2022-08-24 12:08 UTC (permalink / raw)
To: מיכאל שטראוס,
netdev, linux-kernel
Cc: Jakub Kicinski, David S. Miller, linux-nfc
On 24/08/2022 12:10, מיכאל שטראוס wrote:
> Hi,
> I found a small security bug in the ST95HF driver in Linux kernel .
> Thought it is responsible to report it to you guys so you we can patch it
> up.
Please use scripts/get_maintainers.pl to Cc relevant people. You got the
same comment last time as well...
> CVE ID was requested, when it is reserved I will update.
>
> ST ST95HF DRIVER
> ST95HF is an integrated transceiver for NFC made by ST,
> Buffer overflow can be triggered by the attacker by providing malicious
> size in one of the SPI receive registers.
>
> *Details:*
> ```jsx
> unsigned char st95hf_response_arr[2];
> ret = st95hf_spi_recv_response(&st95context->spicontext,
> st95hf_response_arr);
> ...
>
> /* Support of long frame */
> if (receivebuff[0] & 0x60)
> len += (((receivebuff[0] & 0x60) >> 5) << 8) | receivebuff[1];
> else
> len += receivebuff[1];
>
> /* Now make a transfer to read only relevant bytes */
> tx_takedata.rx_buf = &receivebuff[2];
> tx_takedata.len = len - 2;
>
> spi_message_init(&m);
> spi_message_add_tail(&tx_takedata, &m);
> ```
> Driver sets a buffer of 2 bytes for the input bytes but actually allows the
> driver to overflow it with any valid SPI message (short or long frame) in
> the tx_takedata stage.
> It seems like a mistake, but i may be missing something and i am totally
> wrong.
>
> *Effected commits:* Current source includes issue.
What does it mean "current source"? Please be specific which exactly
kernel version is affected, which commit introduced it.
> *Exploitable:* I actually think vulnerability can be exploitable by any
> device on the SPI bus.
Then the risk is quite low, right? SPI busses are not user hot-pluggable
except some development boards (so again a real niche). Basically it's
impact is negligible, considering that system would need to have such
device reported and configured (which for DT systems is static) and at
the same time malfunctioning or behaving incorrectly?
You already sent me a message about it in May and this does not bring
anything particularly new since then. You did not respond to my reply
that time, although maybe that's continuation.
Anyway proper analyzing of this issue and a patch would be nice.
> *Code:*
> <https://github.com/torvalds/linux/blame/master/drivers/nfc/st95hf/core.c#L284>
> https://github.com/torvalds/linux/blame/master/drivers/nfc/st95hf/core.c#L284
> ,
> https://github.com/torvalds/linux/blob/master/drivers/nfc/st95hf/spi.c#L107
>
> I was not able to understand if the remote device has ability to trigger
> the issue or only the SPI connected device?
What does it mean "remote device"? NFC? NFC tag does not talk over SPI...
Best regards,
Krzysztof
_______________________________________________
Linux-nfc mailing list -- linux-nfc@lists.01.org
To unsubscribe send an email to linux-nfc-leave@lists.01.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
^ permalink raw reply [flat|nested] 2+ messages in thread