On 24/08/2022 18:12, מיכאל שטראוס wrote:
>> Please use scripts/get_maintainers.pl to Cc relevant people. You got the
>> same comment last time as well...
> Sorry my bad, i forgot we already contacted.
> I actually ran it and your name came up for some reason.
>> ./scripts/get_maintainer.pl drivers/nfc/st95hf/spi.c
> Bad divisor in main::vcs_assign: 0
> Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> (maintainer:NFC
> netdev(a)vger.kernel.org (open list:NFC SUB
and other addresses... why removing them?
>> What does it mean "current source"? Please be specific which exactly
> kernel version is affected, which commit introduced it.
> *Effected version: *
> - v6.0-rc2 <https://github.com/torvalds/linux/releases/tag/v6.0-rc2> ...
> - *v4.5-rc1* <https://github.com/torvalds/linux/releases/tag/v4.5-rc1>
> *Introducing commit: *
> 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
> What does it mean "remote device"? NFC? NFC tag does not talk over SPI...
> I was wondering maybe the tag is the source for the content that actually
> overflows the kernel buffer,
> In which case it changes the picture a bit.
The buffer is used for SPI transfer, so the NFC tag - except that it
works with that device - is rather long shot.
On 24/08/2022 12:10, מיכאל שטראוס wrote:
> 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
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.
> unsigned char st95hf_response_arr;
> ret = st95hf_spi_recv_response(&st95context->spicontext,
> /* Support of long frame */
> if (receivebuff & 0x60)
> len += (((receivebuff & 0x60) >> 5) << 8) | receivebuff;
> len += receivebuff;
> /* Now make a transfer to read only relevant bytes */
> tx_takedata.rx_buf = &receivebuff;
> tx_takedata.len = len - 2;
> 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
> *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.
> 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...