В Linux-подсистеме nvmet-tcp (NVMe-oF/TCP), позволяющей обращаться к NVMe-накопителям по сети (NVM Express over Fabrics), используя протокол TCP, выявлена уязвимость (CVE-2023-5178), потенциально позволяющая удалённо выполнить свой код на уровне ядра или, при наличии локального доступа, поднять свои привилегии в системе. Исправление пока доступно в виде патча. Проблема проявляется с самой первой версии драйвера NVMe-oF/TCP (в отчёте об уязвимости упоминается ядро Linux 5.15, но поддержка NVMe-oF/TCP была добавлена в ядро 5.0). Уязвимости подвержены системы с включённым сервером NVMe-oF/TCP (NVME_TARGET_TCP), который по умолчанию принимает соединения на сетевом порту 4420.

Уязвимость вызвана логической ошибкой, из-за которой функция nvmet_tcp_free_crypto вызывалась два раза и два раза освобождала некоторые указатели, а также разыменовывала освобождённые адреса. Подобное поведение приводит к обращению к уже освобождённой области памяти (use-after-free) и двойному освобождению памяти (double-free) при обработке сервером NVMe-oF/TCP специально оформленного сообщения от клиента, который может находиться как в локальной, так и в глобальной сети.

  • ThePlayerZero
    link
    fedilink
    arrow-up
    0
    ·
    3 years ago

    обращаться к NVMe-накопителям по сети (NVM Express over Fabrics)

    по идее, кому такое нужно? разве что вычислительным кластерам, которые гонятся за latency пересылки между узлами или ещё чем

    эти узлы из глобал инета не видны, доступ только через шлюз, но на шлюзе

    сервером NVMe-oF/TCP (NVME_TARGET_TCP), который по умолчанию принимает соединения на сетевом порту 4420.

    этого не будет стоять…

    • cocuckaOP
      link
      fedilink
      arrow-up
      0
      ·
      3 years ago

      Да всякое бывает. Например, кто-то может сбилдить универсальное ядро, которое ставит на все машины, с этим драйвером, причём не как модуль, а в составе ядра. Вот и будет достаточно только загрузить такое ядро…