CVE-2025-68260: Первая уязвимость в коде Linux на Rust

Баги бывают у всех. Да, иногда получается написать код, который работает с первого предъявления, но это редкость. «Если отладка — это процесс нахождения ошибок, то программирование следует рассматривать как процесс их создания». (с) Эдсгер Дейкстра.

Ты забываешь о гордых труженниках Лаборатории Касперского, dr Web и прочих разработчиков прочих антивирусов, которым надо как то зарабатывать.

Это другое :)

а растамане уже асилили двусвязный список? я помню у них там были какие-то проблемы, а в ядре ведь еще hlist есть и прочая недружественная к свиньям и боровам всячина

Ну вот в unsafe-блоке только и можно такое осилить :)

В каждом топике по успехи раста.

Врёшь как обычно. Цитаты где?

а растамане уже асилили двусвязный список?

Господи, как с такого не наложить себе в руки?..

Нету никакой «серебряной пули» в мире IT. И не может быть!

а кому ещё-то нужен компилятор, который за программиста решает, что ему можно, а что нет?

Любому кто использует типизируемый язык. Но ты что-то даже больше обычного сегодня тупишь: прямо вот в этой новости обсуждается косяк в unsafe блоке - это ж буквально способ сказать компилятору «я знаю как надо». Натурально эмуляция С в Rust - без ограничений и без гарантий безопасности. То есть прямо противоположное твоему «полагаются на компилятор».

Ну и наверняка же не последняя? С почином!

А надо было: «Перепиши мне этот модуль на Rust без багов и unsafe». Новички, не понимают как общаться с ИИ.

Ну ты передергиваешь. Оно понятно, что в unsafe-блоке раст от Си отличается только синтаксисом. :) В норме-то полагаются на компилятор. Посмотрел я тут на код на расте в ядре, unsafe там не сказать что б много. Ну да, весь аллокатор unsafe extern C, ну а как ещё-то?

Всего не смотрел, конечно, надо какие-то дополнительные крейты тащить, как я понимаю, растовая поддержка, которая прям в дереве ядра, — это далеко не все.

Напишет. Надо потом попросить «а теперь скомпилируй что б работало!» Тут ИИ и стухнет :)

В норме-то полагаются на компилятор.

Ты про С? На да, само собой. Хотя вот лично ты можешь на него не полагаться и написать свой. Ещё полагаются на библиотеки. Тут тоже себя не сдерживай - перепиши всё.

Ты опять словоблудием занимаешься. Не интересно.

Оооо, пошло-поехало) OpenBSD, не спеши, я досмотрю это зрелище и с тобой пойду)

Заббал уже всез за*бал по моему, мб бан?)

Никогда такого не было, и вот опять! Кто бы ожидал?

Я бы даже сказал не «Лепота!», а Ляпота, точнее поток сознания в виде «вот теперь точно заживем».

Что значит мгновенно? Откуда этот вывод?

Особенно, если этих блоков unsafe две-три штуки на десятки тысяч строк.

Ну ты подожди пока процент раста в ядре увеличится и количество таких блоков видимо тоже.

Ты опять словоблудием занимаешься.

Ты уверяешь что проблема с Rust в том что программисты полагаются на компилятор. И делаешь это в комментах к новости где проблема возникла ровно в том самом unsafe куске где они на компилятор не полагаются. Чувак, проснись, ты опять обосрался. А, ты не спишь…

Никогда такого не было, и вот опять!

Ты опять перебрал что-ли? Race condition в ядре не первое десятилетие находят.

Но в русте не бывает багов!!! Оно изначально божественно! /s

Это прецедент. Который показывает, что unsafe будет и чем больше процент раста в ядре, тем больше unsafe.

Я полагаю, что люди, доверяющие компилятору раста не в состоянии доверять своему опыту и чутью. Для успешного программирования на расте нужно что-то другое. Люди, пришедшие в ядро из юзерспейса (а так обычно бьвает) не в состоянии (или гораздо реже бывают в состоянии) оценить все возникающие проблемы. Гонки бывают у всех и везде. Но хардкорные сишники с большей вероятностью наелись сегфолтами и гонками в многопоточных программах в юзерспейсе перед тем, как спуститься в ядро. Ощущение безопасности притупляет бдительность, как известно.

Если твоя цель меня оскорбить — то ты ее не достиг. У кащенитов изящнее выходило. Твой тролинг так, на троечку.

Для успешного программирования на расте нужно что-то другое.

Для успешного программирования на расте нужно то, что нужно для программирования на любом строгом статически типизированном языке: уметь рассуждать логически. Соответствие Карри — Ховарда и т. д.

Теперь решать баги будет ешё интересней.

Так уже. Посмотри на сам баг: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/
Он довольно неочевидный, и интереснее типичных сишних CVE.

Rust’ите баги большие пребольшие

Чудес же не бывает.

«а разговоров-то было…» (с)

С почином.

переписанного на Rust драйвера Binder

Binder

Гугломакаки не могут писать код вне зависимости от языка. Binder ещё на Си был известен своими утечками памяти.

Не говоря уже о каком-нибудь израильском Cellebrite.

ух-ты, ах-ты, первый блин - совсем не комом!!! :о)

Эта фуфайка порвалась, несите следующую. Ты на какждый факап с растом будешь реагировать как истеричка?

Вся суть руста.

Я б даже сказал, что это вся суть растоманов, которые в Си «не смогли», а потом и в ржавом «не смогли»))))

Data race в unsafe блоке. Всё в штатном режиме в общем-то, как и заявлялось.

Я полагаю, что люди, доверяющие компилятору раста не в состоянии доверять своему опыту и чутью.

Охренительные истории, одна охренительней другой просто.

Люди, доверяющие ассемблерам, не в состоянии доверять своему опыту и чутью (и писать на хекс-кодах).

Люди, доверяющие компилятору Си, не в состоянии доверять своему опыту и чутью (и писать на чистом ассемблере).

Люди, доверяющие assert(), не в состоянии доверять своему опыту и чутью.

Люди, доверяющие defer, не в состоянии доверять своему опыту и чутью.

Люди, доверяющие with, не в состоянии доверять своему опыту и чутью.

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

Он довольно неочевидный, и интереснее типичных сишних CVE.

Знаешь, я бы предпочел, чтобы баги не были «неочевидными», а раз баг «неочевиден», то это проблемы языка скорее…

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

Data race в unsafe блоке. Всё в штатном режиме в общем-то, как и заявлялось.

Но позвольте, эксперты в один голос кричали что unsafe - это просто работа с указателями сишными, там точно ничего плохого не может быть, все остальное покрыто Rust кодом!

Картинку рака прилепи к статье, чтоб канонично было)))) Они ж в двусвязный список «не смоли»…))))

Меня больше вопрос интересует: зачем нужно было существующий модуль переписывать на Rust, а не использовать последний для нового функционала. Работает - не трогай.

Меня больше вопрос интересует: зачем нужно было существующий модуль переписывать на Rust, а не использовать последний для нового функционала. Работает - не трогай.

Так у них «новое» не получается, они на переписывании стараются доказать, что язык на что-то годен, но и тут фэйл…

Тут надо задуматься о том, что почему-то ржавые не стали лепить свою ветку в линуксах, а начали все нещадно переписывать, это попахивает корпоратским захватом линукса…

Кому ты объясняешь эти прописные истины? Тут собрались диванные критики, большая часть из них ни на сишке, ни на Расте хелловорлда не написали, но критикуют, своё мнение спешат сообщить.

Грамотные СИшники

А неграмотные?

понимают с какой гранатой имеют дело

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

Интересно, сколько строк в этом драйвере safe и unsafe.

Тебя забанили в гугле? Первая ссылка.

From: Alice Ryhl <aliceryhl@google.com>
Subject: [PATCH RFC 00/20] Setting up Binder for the future
Date: Wed, 01 Nov 2023 18:01:30 +0000	[thread overview]

We're generally not proponents of rewrites (nasty uncomfortable things
that make you late for dinner!). So why rewrite Binder? 

Binder has been evolving over the past 15+ years to meet the evolving
needs of Android. Its responsibilities, expectations, and complexity
have grown considerably during that time. While we expect Binder to
continue to evolve along with Android, there are a number of factors
that currently constrain our ability to develop/maintain it. Briefly
those are:

1. Complexity: Binder is at the intersection of everything in Android and
   fulfills many responsibilities beyond IPC. It has become many things
   to many people, and due to its many features and their interactions
   with each other, its complexity is quite high. In just 6kLOC it must
   deliver transactions to the right threads. It must correctly parse
   and translate the contents of transactions, which can contain several
   objects of different types (e.g., pointers, fds) that can interact
   with each other. It controls the size of thread pools in userspace,
   and ensures that transactions are assigned to threads in ways that
   avoid deadlocks where the threadpool has run out of threads. It must
   track refcounts of objects that are shared by several processes by
   forwarding refcount changes between the processes correctly.  It must
   handle numerous error scenarios and it combines/nests 13 different
   locks, 7 reference counters, and atomic variables. Finally, It must
   do all of this as fast and efficiently as possible. Minor performance
   regressions can cause a noticeably degraded user experience.

2. Things to improve: Thousand-line functions [1], error-prone error
   handling [2], and confusing structure can occur as a code base grows
   organically. After more than a decade of development, this codebase
   could use an overhaul.

3. Security critical: Binder is a critical part of Android's sandboxing
   strategy. Even Android's most de-privileged sandboxes (e.g. the
   Chrome renderer, or SW Codec) have direct access to Binder. More than
   just about any other component, it's important that Binder provide
   robust security, and itself be robust against security
   vulnerabilities.

It's #1 (high complexity) that has made continuing to evolve Binder and
resolving #2 (tech debt) exceptionally difficult without causing #3
(security issues). For Binder to continue to meet Android's needs, we
need better ways to manage (and reduce!) complexity without increasing
the risk.

The biggest change is obviously the choice of programming language. We
decided to use Rust because it directly addresses a number of the
challenges within Binder that we have faced during the last years. It
prevents mistakes with ref counting, locking, bounds checking, and also
does a lot to reduce the complexity of error handling. Additionally,
we've been able to use the more expressive type system to encode the
ownership semantics of the various structs and pointers, which takes the
complexity of managing object lifetimes out of the hands of the
programmer, reducing the risk of use-after-frees and similar problems.

Rust has many different pointer types that it uses to encode ownership
semantics into the type system, and this is probably one of the most
important aspects of how it helps in Binder. The Binder driver has a lot
of different objects that have complex ownership semantics; some
pointers own a refcount, some pointers have exclusive ownership, and
some pointers just reference the object and it is kept alive in some
other manner. With Rust, we can use a different pointer type for each
kind of pointer, which enables the compiler to enforce that the
ownership semantics are implemented correctly.

Another useful feature is Rust's error handling. Rust allows for more
simplified error handling with features such as destructors, and you get
compilation failures if errors are not properly handled. This means that
even though Rust requires you to spend more lines of code than C on
things such as writing down invariants that are left implicit in C, the
Rust driver is still slightly smaller than C binder: Rust is 5.5kLOC and
C is 5.8kLOC. (These numbers are excluding blank lines, comments,
binderfs, and any debugging facilities in C that are not yet implemented
in the Rust driver. The numbers include abstractions in rust/kernel/
that are unlikely to be used by other drivers than Binder.)

Although this rewrite completely rethinks how the code is structured and
how assumptions are enforced, we do not fundamentally change *how* the
driver does the things it does. A lot of careful thought has gone into
the existing design. The rewrite is aimed rather at improving code
health, structure, readability, robustness, security, maintainability
and extensibility. We also include more inline documentation, and
improve how assumptions in the code are enforced. Furthermore, all
unsafe code is annotated with a SAFETY comment that explains why it is
correct.

We have left the binderfs filesystem component in C. Rewriting it in
Rust would be a large amount of work and requires a lot of bindings to
the file system interfaces. Binderfs has not historically had the same
challenges with security and complexity, so rewriting binderfs seems to
have lower value than the rest of Binder.

Correctness and feature parity
------------------------------

Rust binder passes all tests that validate the correctness of Binder in
the Android Open Source Project. We can boot a device, and run a variety
of apps and functionality without issues. We have performed this both on
the Cuttlefish Android emulator device, and on a Pixel 6 Pro.

As for feature parity, Rust binder currently implements all features
that C binder supports, with the exception of some debugging facilities.
The missing debugging facilities will be added before we submit the Rust
implementation upstream.

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

Его ещё называют «код на С» - ядро большей частью из него состоит на данный момент.

О, у тебя и здесь пригорело. Ты вообще моих сообщений не пропускаешь что-ли? Неужели у меня наконец-то появился личный упоротый фанат?! Тупенький слегка, конечно, но для начала сойдёт :)

теперь стало очевидно, что они придумали unsafe для оправдания кривости языка🤭

Люди, доверяющие ассемблерам, не в состоянии доверять своему опыту и чутью (и писать на хекс-кодах)…. и т.д.

Это сравнение пальца и непальца - вообще не в ту лужу…

Если какую-то часть работы можно переложить на дубовый алогоритм, то эта работа должна быть переложена на него.

В ржавом переложили на компилятор вообще ни разу не дубовые вещи…

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

«обмазаться линтерами и обмазать проверками весь код» - вообще негодная идея, это называется выкинуть производительность в помойку…

А уж если компилятор в состоянии закрыть большую часть проблем связанных с памятью (а CVE по большей части из них и состоят) - это должно быть сделано.

Как оказалось не «в состоянии закрыть большую часть проблем связанных с памятью», а в состоянии только растомана заставить написать слово unsafe, более никаких проблем не решается, как показала практика…