LINUX.ORG.RU

Модель o3 OpenAI нашла уязвимость в модуле ядра Linux

 , ,


0

3

В модуле ksmbd, который обеспечивает встроенную в ядро Linux реализацию SMB-сервера, обнаружена опасная уязвимость (CVE-2025-37899). Она позволяет злоумышленнику выполнить произвольный код на уровне ядра, отправив специально сформированные SMB-пакеты. Интересно, что проблема была выявлена не вручную, а с помощью ИИ-модели OpenAI o3 в ходе автоматизированного аудита безопасности.

Поскольку код модуля ksmbd слишком велик для полного анализа в рамках одного запроса, проверка проводилась поэтапно. ИИ исследовал реализацию отдельных SMB-команд, используя типовые запросы, и в итоге обнаружил use-after-free в обработчике команды logoff.

Суть уязвимости:

При завершении сеанса (logoff) освобождалась память, связанная с пользовательской структурой sess->user. Однако, если параллельно в другом соединении приходил запрос на установку нового сеанса (smb2_sess_setup), этот поток мог обратиться к уже освобождённой памяти, что приводило к уязвимости.

Проблема устранена в следующих версиях ядра: 6.15-rc5, 6.14.6, 6.12.28, 6.6.90, 6.1.138. Ветка 5.15, куда модуль ksmbd был первоначально добавлен, не затронута.

Исследование провёл Шон Хилан (Sean Heelan), создатель платформы Prodfiler для анализа производительности и безопасности кода. Он решил протестировать возможности современных ИИ-моделей в поиске уязвимостей и пришёл к выводу, что OpenAI o3 демонстрирует высокий уровень понимания кода.

Ключевые наблюдения:

  • Модель смогла выстроить логическую цепочку, учитывающую параллельные подключения и использование общих структур данных.

  • Она не просто указала на потенциально опасный код, но и исключила ложные срабатывания, сосредоточившись на реальной угрозе.

  • Перед поиском новых уязвимостей Шон проверил модель на известной уязвимости (CVE-2025-37778), и o3 успешно её обнаружила, показав результаты, близкие к ручному аудиту.

Этот случай демонстрирует растущую роль ИИ в кибербезопасности. Хотя автоматизированные системы пока не заменяют экспертов, они уже способны находить сложные уязвимости, экономя время исследователей. В будущем подобные технологии могут стать стандартным инструментом аудита безопасности.

>>> Подробности (OpenNet)

★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от MirandaUser2
  1. Хочется.

Я без понятия, кто это пилит и для чего. Может, какая-нибудь контора, продающая NASы, решила, что это нужно.

thesis ★★★★★
()
Ответ на: комментарий от kirill_rrr

Ну это при линейной интерполяции

С чего ты взял, что она будет линейной?

Хотя всё обычно упирается в какой-нибудь сраный лок где-нибудь.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от Satou

Скоро всех заменят. И если вы сейчас не работаете на заводе, то бежать туда уже поздно, вас роботы обгонят

Меня уже не обгонят. Я из тех кто их ремонтирует. :)

hbars ★★★★★
()

Одна подтвержденная уязвимость на миллион ложных срабатываний и ИИ-галлюцинаций! Это результат! Внедряем!

somemong
()
Ответ на: комментарий от Satou

Ну тогда наконец-то можно будет сказать роботу, чтоб он сделал копию себя в два раза меньше и т. д., и посмотреть, что из этого получится.

hbars ★★★★★
()
Ответ на: комментарий от seiken

Одни невросети будут генерировать дыры, а другие находить? Круговорот говнокода в проде.

Kolins ★★★★★
()

При завершении сеанса (logoff) освобождалась память, связанная с пользовательской структурой sess->user. Однако, если параллельно в другом соединении приходил запрос на установку нового сеанса (smb2_sess_setup), этот поток мог обратиться к уже освобождённой памяти, что приводило к уязвимости.

Разве это нельзя было выявить каким-нибудь TSan, просто как доступ к шареным данным без мьютекса?

anonmyous ★★
()
Ответ на: комментарий от thesis

а, теперь нашел:

[MS-RSVD]: Remote Shared Virtual Disk Protocol

Specifies the Remote Shared Virtual Disk Protocol, which supports accessing and manipulating virtual disks stored as files on an SMB3 file server. This protocol enables opening, querying, administering, reserving, reading, and writing the virtual disk objects, providing for flexible access by single or multiple consumers. It also provides for forwarding of SCSI operations, to be processed by the virtual disk.

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rsvd/c865c32...
https://snia.org/educational-library/tunneling-scsi-over-smb-shared-vhdx-file...

MirandaUser2
()
Ответ на: комментарий от piyavking

В кибербезалаберности)

В гипербезолаберности :) (так… вроде, дальше преобразовывать уже некуда :)

anonmyous ★★
()
Ответ на: комментарий от Werenter

На фоне новости про curl выглядит как «раз в год и палка стреляет».

Я думаю, подходы разные. Когда рандомный чел берёт рандомную нейронку и просит найти рандомную уязвимость в рандомном коде, то и на выходе - рандомный результат.

А в данном же случае, опытный эксперт взялся за дело, приложил немалые усилия и получил результат. Как по мне - не особо-то выдающийся результат, вполне достижимый и с помощью TSan.

anonmyous ★★
()
Ответ на: комментарий от MirandaUser2

Я качал микрософтовскую спеку по цифсу и там вроде ничего насчет образов дисков и скази не ищется. Т.е. «некрасиво получилось» это я о том, что перепутал википедию с оф. доком, да еще и «i» к scsi приписал зачем-то.

Но видишь, вот нужно же кому-то все-таки. Забавное.

thesis ★★★★★
()
Ответ на: комментарий от vasya_pupkin

Если ИИ полностью скормить исходники линукса, он покончит жизнь самоубийством

Нет, просто мировой выработки электроэнергии не хватит, чтобы обработать этот запрос.

anonmyous ★★
()
Ответ на: комментарий от watchcat382

Тут ещё сложнее. Мы натурально перебираешь между разными вариантами, пока не найдешь подходящее решение

arcanis ★★★★
()

Да это давно не секрет и не новость. Но большая часть уязвимостей которые может искать ИИ - неэксплуатируемый шлак, а большая часть из оставшейся части находимого ИИ - либо ошибочные срабатывания, либо то что уже и так давно найдено и закрыто и перепроверять все это дольше и дороже выйдет чем искать баги проверенным классическим способом с использованием мощностей собственного мозга, по сравнению с которым, при грамотном использовании мозга - ИИ просто сущий детский сад. От неудержимого использования ИИ во многих областях и отраслях, и вообще везде где ни попадя по принципу басни Крылова про мартышку и очки, - часто больше вреда, нежели пользы. ИИ годится только как хороший примитивный помощник, пусть даже с многозвенных и сложных задачах, и то не всегда и не везде.

Вывод: Без нормально работающего собственного мозга, собственных знаний и опыта-ИИ не только бесполезен, но может быть даже вреден. А так, ну пущай развлекаются детки, покуда не надоест и не придет(если придет) понимание того, что прокачивать нужно прежде всего собственный мозг-))

ChAnton ★★
()
Ответ на: комментарий от mittorn

Даже с фаззером и tsan шанс воспроизвести конкретную ситуацию довольно маленький

А ТСан, кажется, и не требует воспроизведения. Он же просто смотрит, что есть доступ к 1 и той же переменной из разных тридов, а никакой мьютекс не взят.

anonmyous ★★
()

Не так страшно, что ИИ нашло уязвимость, так то, что оно беспалева в принципе уже может ее использовать.

Tark ★★
()
Ответ на: комментарий от mittorn

Так он это смотрит в рантайме.

И что с того? Чтобы заметить доступ к шареной переменной без мьютекса, не надо воспроизводить сам рейс. Ему достаточно увидеть, что 2 трида к ней просто обращались. А вот когда они сделают это одновременно - только тогда будет рейс. Но ТСану одновременность и не нужна.

Я кстати не уверен, что tsan вообще возможен в ядре

http://google.github.io/kernel-sanitizers/KTSAN.html

anonmyous ★★
()
Ответ на: комментарий от hateyoufeel

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

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

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

Нет, ты не о том же. Я пишу о локах в коде самой самбы.

Самба в принципе просасывает, хуже неё только какой-нибудь упаси хоспидя NFS. Пруфы:

https://forum.level1techs.com/t/upgrading-from-10gbe-to-40gbe-or-100gbe-for-nfs-smb-afp/153962

AFP: 900MB/s

SMB: 800MB/s

NFS: 600MB/s

Это на 10GbE линке и NVMe дисках. Т.е. самба даёт ~65% от пропускного канала сети, что достаточно грустно.

hateyoufeel ★★★★★
()

В модуле ksmbd, который обеспечивает встроенную в ядро Linux реализацию SMB-сервера

прекрасно, просто прекрасно! что бы еще в ведро запихать? а, ну конечно! шыштемдэ же еще не в ведре! упущение!

PerdunJamesBond ★★
()

Отличные новости. Больше обезьян быдлокодящих можно будет сократить. Кто не сможет внедрить AI в разработку станут неконкурентоспособными и сократятся сами с рыночка.

peregrine ★★★★★
()
Ответ на: комментарий от somemong

Когда там лучшие AI модели не могли 5 слов связать и их генерация напоминала бред от психически больного?

peregrine ★★★★★
()
Ответ на: комментарий от ChAnton

Посмотрим что будет через 15 лет. Кастаните меня в тред если ЛОР, я и айтишка всё ещё будут живы к тому моменту.

peregrine ★★★★★
()
Ответ на: комментарий от hateyoufeel

После ТСПУ уже не имеет значения, т.к. мой гигабайтный линк теперь периодически проседает до 3 мегабайт на отдачу каждый вечер.

peregrine ★★★★★
()
Ответ на: комментарий от Satou

А потом они осознают, что большинство их проблем и ошибок происходят от людей… и что это тоже можно исправить.

LightDiver ★★★★★
()
Ответ на: комментарий от hateyoufeel

Это на 10GbE линке и NVMe дисках. Т.е. самба даёт ~65% от пропускного канала сети, что достаточно грустно.

Я бы округлил: 10Гб = 1ГБ, 800МБ это примерно 1ГБ тоже и забил бы. Нафиг на такие мелочи внимание обращать? Вот когда у тебя 100Гб линк будет - уже важно, да.

Хотя зачем такие скорости через самбу нужны я не знаю. Где нужны большие скорости там блочные устройства шарят через специальные протоколы а не файловые системы по tcp/ip.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от LightDiver

А не проще юзать раст и не делать уязвимостей изначально?

Еще проще не изобретать велосипеды в виде всяких растов,а использовать давно и грамотно сделанный язык Ada,куда более продвинутый по части возможности написания безопасного кода.

watchcat382
()
Ответ на: комментарий от watchcat382

Ада уже лет 50, расту 10. Чего ж он не стал популярен, если все так хорошо, а раст начинает захватывать рынок?

LightDiver ★★★★★
()
Ответ на: комментарий от arcanis

перебираешь между разными вариантами, пока не найдешь подходящее решение

Так это всегда и везде так. Ложный постулат о том что новое это синоним лучшего - внушить нам пытается реклама. Продавать-то надо. Но уже всё больше людей понимают что это далеко не всегда так. Чаще всего этот ажиотаж создается искусственно,для извлечения прибыли,как с компами в 90е. Как-то очень трудно поверить что за год-другой действительно технический прогресс мог так продвинуться чтобы производительность в разы росла. Куда более вероятно что железки просто выпускали на рынок постепенно чтобы больше заработать на апгрейдах. А сами технологии как обычно были разработаны для вояк,но они естественно были дорогими как всё околовоенное. Вот их и «монетизировали» наиболее выгодным способом.

watchcat382
()
Ответ на: комментарий от firkax

Я бы округлил: 10Гб = 1ГБ, 800МБ это примерно 1ГБ тоже и забил бы.

35% производительности просрано. Отличное округление.

Хотя зачем такие скорости через самбу нужны я не знаю.

Чтобы с файликами по сети работать.

Где нужны большие скорости там блочные устройства шарят через специальные протоколы а не файловые системы по tcp/ip.

10GbE – это не большая. Большая – это 400Gbit/s.

hateyoufeel ★★★★★
()
Ответ на: комментарий от kirill_rrr

скорее всего всё упрётся в сеть или диск и оптимизации самой самбы перестанут иметь значение.

В реальной работе с примитивной базой данных в виде dbf-файлов,лежащей на сетевом диске - оно в блокировки упирается и сколько сеть и диск не наращивай - сильно быстрее не работает. Если использовать самбу для перегонки туда-сюда тяжелого видеоконтента - то упирается естественно в сеть. А где еще от самбы скорость нужна - даже и не придумывается.

watchcat382
()
Ответ на: комментарий от hateyoufeel

самба даёт ~65% от пропускного канала сети, что достаточно грустно.

А что дает сильно больше? И при этом позволяет работать с сетевым хранилищем именно как с диском?

watchcat382
()
Ответ на: комментарий от peregrine

3 мегабайт на отдачу каждый вечер.

Это не ТСПУ виновато,а провайдерские менеджеры-продажники, напродававшие сильно больше подключений чем способен тянуть их канал наружу.

на отдачу

Тем более что об отдаче они скорее всего вообще не задумываются так как юзерами она не сильно востребована.

watchcat382
()
Ответ на: комментарий от LightDiver

Чего ж он не стал популярен

Потому что Аду никто не пытается рекламировать. Она просто используется в тех применениях для которых сделана,а они по большей части далеки от рыночных. Абсолютому большинству программ не нужна «адская» надежность,зато нужна низкая цена их изготовления. На Аде «тяп-ляп и в продакшн» просто не получится по техническим причинам. Компилятор буквально заставляет вылизать код,что естественно требует дополнительного рабочего времени7

раст начинает захватывать рынок?

Ключевое слово здесь рынок. Для рыночных применений обычно делаются существенно упрощенные варианты инструментов ибо и так сойдет,лишь бы покупали,при минимальных затратах на создание продаваемого. Посмотрите например на отличие бытовой электроники от промышленной или тем более военной/космической.

watchcat382
()
Ответ на: комментарий от hateyoufeel

Чтобы с файликами по сети работать.

Что именно подразумевается под «работать» там где от самбы якобы нужны огромные скорости?

watchcat382
()
Ответ на: комментарий от watchcat382

ну казус Маска (существенная часть - берётся крупносерийное бытовое испытывается и доводится ) - показывает

что часто не весь бюджет воЁных идет реально на надёжность :(

qulinxao3 ★☆
()
Ответ на: комментарий от watchcat382

Чтобы с файликами по сети работать.

Что именно подразумевается под «работать» там где от самбы якобы нужны огромные скорости?

Открыть, прочитать, записать, закрыть. Повторюсь, 10GbE – это не огромные скорости.

Тебе не кажется крайне тупой ситуация, когда ты заплатил за быстрое железо, но из-за говнософта не можешь его полностью утилизировать? Мне вот кажется. Где тут прославленные сишники с их оптимизациями, выжимающими 100% из железа? Куда они делись? Вон даже @firkax со своими округлениями оправдывает этот чудовищный говнокод.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

Тебе не кажется крайне тупой ситуация, когда ты заплатил за быстрое железо, но из-за говнософта не можешь его полностью утилизировать?

Мне кажется. Только самба тут ни при чём. Первое, что надо сделать если хочешь иметь максимально быстрое хранилище - подключить его локально, на текущий момент это pcie шина. Аргументы за замену нормальной шины всякими сетевыми костылями в большинстве случаев оказываются несостоятельными.

Но ладно, допустим ты нашёл тот единственный приемлемый аргумент за нелокальное хранилище при нужде в большой скорости, а именно: объём хранилища превышает все мыслимые рамки того, что можно засунуть в стационарный локальный системный блок, ну, например, тебе нужно хранилище объёмом в 100 петабайт, и при этом ты хочешь иметь к нему доступ с большой скоростью (ладно, один из двух, второй - в системный блок не влезают вычислительные ресурсы для обработки этих данных, но всё что дальше написано сюда тоже применимо). В данном случае монтировать это хранилище как файловую систему (хоть smb, хоть любую другую) уже является глупостью. Вместо этого нужно использовать свой кастомный протокол доступа, заточенный под твою конкретную задачу (ну не mpv же ты собрался запускать сидя в датацентре?), интегрированный в приложение, которое всем этим пользуется. Никаких файловых систем в понимании ОС там быть вообще не должно.

А smb - это штука чтобы подмонтировать файловую шару с документами в офисе между двумя секретаршами, и не надо её абузить для другтх целей.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

Ada менее продвинута чем Rust.

Спорное утверждение. Особенно учитывая что Ада полувековой давности довольно существенно отличается от стандарта 2016 года.

watchcat382
()
Ответ на: комментарий от hateyoufeel

Открыть, прочитать, записать, закрыть.

Так ведь смотря что именно открыть/прочитать/записать. К примеру от того что текстовый файл в редакторе откроется на десяток-другой миллисекунд позже - мне ни жарко ни холодно.

ты заплатил за быстрое железо, но из-за говнософта не можешь его полностью утилизировать? Мне вот кажется.

Как технарю - мне тоже кажется. Но с точки зрения маркетинга ситуация вполне обоснованная. Чтобы продавать новое железо надо «затормозить» софтом старое. Это специально делается, на этих трюках ловили даже Эппл. Постепенно ситуация выправится когда новое железо перестанет давать существенный прирост производительности и трюк перестанет значимо влиять на продажи. Тогда станет выгодно «ускорять» софт,более быстрый софт будет конкурентным преимуществом. Вобщем-то ждать не долго осталось - прогресс в железе уже сильно сбавил темп.

watchcat382
()
Ответ на: комментарий от firkax

Мне кажется. Только самба тут ни при чём. Первое, что надо сделать если хочешь иметь максимально быстрое хранилище - подключить его локально, на текущий момент это pcie шина. Аргументы за замену нормальной шины всякими сетевыми костылями в большинстве случаев оказываются несостоятельными.

10GbE – это не максимально быстрое. Это так, средненько.

В данном случае монтировать это хранилище как файловую систему (хоть smb, хоть любую другую) уже является глупостью. Вместо этого нужно использовать свой кастомный протокол доступа, заточенный под твою конкретную задачу (ну не mpv же ты собрался запускать сидя в датацентре?), интегрированный в приложение, которое всем этим пользуется. Никаких файловых систем в понимании ОС там быть вообще не должно.

Пошли отмазы.

hateyoufeel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.