netdev - ST ST95HF DRIVER security bug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAAMXCFm12u-v1-AZyYM-hXtTJ1YwFyL26gM8RiONDfMs4+U=WQ@mail.gmail.com>
Date:   Thu, 25 Aug 2022 10:11:22 +0300
From:   מיכאל שטראוס 
        <mdstrauss91@...il.com>
To:     linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: ST ST95HF DRIVER security bug

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.
CVE ID was requested,  when it is reserved I will update.
I want to thank Krzysztof Kozlowski for helping me out.

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.

* Exploitable: I actually think vulnerability can be exploitable by
any device on the SPI bus.
   Exploit is quite low risk and impact is negligible, both because it
requires an actual connected device and because it requires the driver
to be registered.

* Effected versions: v6.0-rc2 - v4.5-rc1

* Introducing commit:
https://github.com/torvalds/linux/commit/cab47333f0f75b685bce1facecb73bf3632e1360

* Code:
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

Side note:
I was wondering if maybe the tag is the source for the content that actually
overflows the kernel buffer,  In which case it changes the picture a bit.
But if i understood correctly the messages are used for configuration
with connected device.

Suggested patch:
I am actually not sure if we can somehow limit the size to MAX command length.
I changed it to 1024 because it seems to support 10 bit long frame spi.

```
diff --git a/drivers/nfc/st95hf/core.c b/drivers/nfc/st95hf/core.c
index ed704bb77..741ce633b 100644
--- a/drivers/nfc/st95hf/core.c
+++ b/drivers/nfc/st95hf/core.c
@@ -281,7 +281,7 @@ static int st95hf_send_recv_cmd(struct
st95hf_context *st95context,
        }

        if (cmd_array[cmd].req == SYNC && recv_res) {
-               unsigned char st95hf_response_arr[2];
+               unsigned char st95hf_response_arr[1024];

                ret = st95hf_spi_recv_response(&st95context->spicontext,
                                               st95hf_response_arr);
```