LINUX.ORG.RU

В Linux раскрыта уязвимость GhostLock, позволяющая получить root-доступ

 , , , ,


0

1

В ядре Linux раскрыта уязвимость CVE-2026-43499, получившая неофициальное название GhostLock. Проблема затрагивает код rtmutex и механизм futex с наследованием приоритета, а её эксплуатация может позволить локальному непривилегированному пользователю повысить права до root. По данным AlmaLinux, уязвимость также может использоваться из контейнера для выхода на хост, если система работает на не обновлённом ядре.

Суть ошибки связана с функцией remove_waiter() в kernel/locking/rtmutex.c. Как указано в описании NVD, при откате proxy-lock в сценарии futex_requeue() функция работала с текущей задачей (current), хотя должна была очищать состояние той задачи, которая реально ожидала блокировку (waiter::task). В результате состояние pi_blocked_on могло не очищаться корректно, оставляя висячий указатель и создавая предпосылку для use-after-free.

Исследователи из Nebula Security описали GhostLock как ошибку, присутствовавшую в основных дистрибутивах Linux с 2011 года. Публичное обсуждение уязвимости усилило риск для серверов и контейнерных окружений: CloudLinux отдельно предупреждает, что для CVE-2026-43499 уже существует публичный proof-of-concept, поэтому администраторам не стоит откладывать обновление ядра.

Исправление в апстриме сводится к тому, что remove_waiter() должен использовать waiter::task, а не current, во всех связанных операциях. На это указывает и GitHub Advisory Database, где перечислены последствия ошибки: некорректное удаление из rbtree без нужной блокировки, неочищенное состояние pi_blocked_on и работа rt_mutex_adjust_prio_chain() не с той задачей.

Пользователям Linux-дистрибутивов рекомендуется установить свежие обновления ядра из официальных репозиториев. Уязвимость имеет локальный характер, поэтому удалённый вход сам по себе она не даёт, но на многопользовательских серверах, CI-инфраструктуре, хостингах и системах с контейнерами риск заметно выше: успешная эксплуатация превращает уже полученный низкопривилегированный доступ в полный контроль над системой.

>>> Источник

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 2)

С каждым днем как-то все больше ценишь венду и прочие закрытые сорцы.

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

да ты посмотри сколько там CVE, я про винду, при том что обновления они, у недопущенных в калашный ряд, отрубили, вроде как 2023 году ещё…

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

Вспомнила бабка, как девкой была.

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

Если бабайку видно, то он точно есть, в отличие от.

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

Так для неё тоже регулярно публикуют CVE. Причём их иногда не исправляют по нескольку лет после публикации. Например, CVE-2020-1472. Linux хотя бы оперативно патчат.

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

Ты уверен, что они там все закрытые и не утекли куда-нибудь, хотя бы частично..

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

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

Самая безопасная система - система, без выхода в инет и контакта с кожаными

А закрытые сорсы сразу ставит огромный вопрос в безопасности

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

С каждым днем как-то все больше ценишь венду и прочие закрытые сорцы.

Не OpenBSD да, не санитарию кода, а сраного гейца и индусов, вононочо.

ant1
()

Узнал пост по аффтару.

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

Как минимум эти параноики сисколы забанили, потому что боятся что кто-то таким образом сделает ТАМ ВИРУС

mittorn ★★★★★
()

Патч попал в стабильные ветки 2 месяца назад, а новость написана так, как будто все текущие ядра уязвимы.

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

С каждым днем как-то все больше ценишь венду и прочие закрытые сорцы.

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

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

А ведь я сомневался когда говорили что каждый бздун - виндузятник.

Ладно вендузятник, но почему бздун?

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

даже логотипа не придумали для бага

Да за токое CVE отозвать мало! Что они себе позволяют вообще?!

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

Это отсылка к вероятности встретить динозавра на Невском проспекте, я правильно понял?

hobbit ★★★★★
()

вообще незачем было делать поддержку futexов между процессами.

самая тупая реализация где в пределах процесса размещаем 256(например) указателей на HLIST из потоков. потоки когда хотят подождать, у себя записывают адрес, включают себя в список под индексом ну например (адрес/8)%255, и спят. когда хотят кого-нибудь забудить, выбирают список под нужным индексом, и будят необходимое количество потоков.

Если нужно всё таки futex делить между процессами, то такую же структуру можно реализовать для отдельных объектов shm.

Алгоритм железобетонный, простой как мычание быка, и совершенно не поддающийся ломанию. Если бы процы поддерживали непосредственно операцию блокировки кэш-линейки, вместо шизоереси CAS или LR/SC, то он был бы еще и очень простой в плане реализации. хрен чем сломаешь.

вот нахрена они нагородили всё то из-за чего потом по жёппе получают?

ckotctvo
()

И все равно большая часть обычных пользователей не сможет воспользоваться этими уязвимостями.

Те 10 процентов, которые могут, (из них 9) не станут этого делать в связи с достаточным количеством интеллекта. Остается 1 процент, которые могут и может быть станут, а может быть, не станут.

Делим 1 на половину, получаем 0.5 от всех пользователей, которые могут и, может быть, попытаются, получится только у 0.001 процента. Но они под наблюдением. Поэтому будут проверять, скорее всего, только на своих компах.

Остаются буквально единцы безбашенных, которые попытаются что-то чужое сломать, но у безбашенных обычно разум уже не 100 процентов работает, т.е. вообще никто не сможет воспользоваться.

AnonymUser
()
Последнее исправление: AnonymUser (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.