The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально позволяющая выполнить код"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально позволяющая выполнить код"  +/
Сообщение от opennews (??), 16-Дек-21, 09:27 
В USB Gadget, подсистеме ядра Linux, предоставляющей программный интерфейс для создания клиентских USB-устройств и программной симуляции USB-устройств, выявлена уязвимость (CVE-2021-39685), которая может привести к утечке информации из ядра, краху или выполнению произвольного кода на уровне ядра. Атака производится непривилегированным локальным пользователем через манипуляции с различными классами устройств, реализованными на базе API USB Gadget, такими, как rndis, hid, uac1, uac1_legacy и uac2...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=56357

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –29 +/
Сообщение от Аноним (1), 16-Дек-21, 09:27 
Да блин. Опять все из за Сей, с их буфферами ограниченного размера, создаваемыми на стеке. Сейчас 21-й век. Ну юзайте, блин, динамически выделяемые буфферы.
Ответить | Правка | Наверх | Cообщить модератору

4. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +15 +/
Сообщение от Корец (?), 16-Дек-21, 09:36 
На сях можно выделить память на куче и работать с ней. При чём тут си? Тут ошибка в логике.
Ответить | Правка | Наверх | Cообщить модератору

10. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –11 +/
Сообщение от Анонимemail (10), 16-Дек-21, 09:56 
а когда кучу надо освободить — это всегда безопасная процедура?
Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –18 +/
Сообщение от Брат Анон (ok), 16-Дек-21, 10:05 
На стеке -- да. Но никак не в куче. А вообще, Си доказал давно свою профнепригодность.
Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +16 +/
Сообщение от InuYasha (??), 16-Дек-21, 10:14 
Пока что, лишь Анон доказал давно свою профнепригодность.
Ответить | Правка | Наверх | Cообщить модератору

43. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –2 +/
Сообщение от Брат Анон (ok), 16-Дек-21, 11:08 
> Пока что, лишь Анон доказал давно свою профнепригодность.

При выполнении пары правил (что само по себе не очень идея) -- можно.
Си по определению опасен. Я бы его использовать не стал. Оберон -- другое дело.

Ответить | Правка | Наверх | Cообщить модератору

56. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Sw00p aka Jerom (?), 16-Дек-21, 11:35 
>Си по определению опасен

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

Ответить | Правка | Наверх | Cообщить модератору

67. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +5 +/
Сообщение от Rev (?), 16-Дек-21, 13:33 
Значит ядро с такими уязвимостями писали знайки и доучки, да?
Ответить | Правка | Наверх | Cообщить модератору

72. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –3 +/
Сообщение от Sw00p aka Jerom (?), 16-Дек-21, 14:11 
> Значит ядро с такими уязвимостями писали знайки и доучки, да?

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

Ответить | Правка | Наверх | Cообщить модератору

77. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +3 +/
Сообщение от _ (??), 16-Дек-21, 14:41 
> а ядро причем? никто не запрещает незнайкам и недоучкам писать ядро, а
> раз в ядре такие же баги, значить их писали незнайки и недоучки.

И рецензировали написанное - тоже незнайки-недоучки, а не сферическо-пряморукие Си-погромизды с опеннета (правда, немного воображаемые), ага.
> Конечно легче все свалить на дырявую Сишку, а свою безолаберность и некомпетентность не признавать.

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

Ответить | Правка | Наверх | Cообщить модератору

89. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –1 +/
Сообщение от Sw00p aka Jerom (?), 16-Дек-21, 17:07 
> И рецензировали написанное - тоже незнайки-недоучки, а не сферическо-пряморукие Си-погромизды
> с опеннета (правда, немного воображаемые), ага.

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

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

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


Ответить | Правка | Наверх | Cообщить модератору

117. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Прохожий (??), 17-Дек-21, 07:29 
>Не знание тонкостей работы с инструментом не говорит о его "плохости"

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

Ответить | Правка | Наверх | Cообщить модератору

124. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Sw00p aka Jerom (?), 17-Дек-21, 11:15 
>Простая логика.

Потребительская логика, легче купить продукт.

Ответить | Правка | Наверх | Cообщить модератору

135. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от амоним (?), 17-Дек-21, 18:11 
легче купить нового раба с нужными знаниями
Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

95. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (95), 16-Дек-21, 20:13 
>> никто не запрещает незнайкам и недоучкам писать ядро

А значит ядро нужно писать не на Си. А то незнайки и недоучки делают много ляпов.

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

98. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +1 +/
Сообщение от Sw00p aka Jerom (?), 16-Дек-21, 21:52 
> А значит ядро нужно писать не на Си. А то незнайки и
> недоучки делают много ляпов.

отличная логика, незнайка и недоучка по определению не должен писать не на Си ни ядро, раз на то пошло. А если и пишет, ну Бог с ним, я не запрещал :)

Ответить | Правка | Наверх | Cообщить модератору

114. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +1 +/
Сообщение от искра (?), 17-Дек-21, 04:05 
>ибо язык это не для незнаек и недоучек

а кто доучка? практика показвывает, что на си пишут исключительно недоучки, получается. вездеж дыры, значит везде недоучки пишут.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

125. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Sw00p aka Jerom (?), 17-Дек-21, 11:22 
>а кто доучка?

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

Ответить | Правка | Наверх | Cообщить модератору

65. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +1 +/
Сообщение от Аноним (65), 16-Дек-21, 13:23 
Брат Анон, тебе в ЯОС!
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

100. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от _ (??), 16-Дек-21, 23:44 
Ну а что - тоже хорошие 3 буквы, и означают наверное то-же самое  :)
Ответить | Правка | Наверх | Cообщить модератору

146. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Брат Анон (ok), 19-Дек-21, 18:28 
> Брат Анон, тебе в ЯОС!

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

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

23. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Анонм (?), 16-Дек-21, 10:19 
Си еще ладно.
Машинные коды вообще никуда не годятся!
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

44. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Брат Анон (ok), 16-Дек-21, 11:09 
> Си еще ладно.
> Машинные коды вообще никуда не годятся!

Машинные коды не язык. И не переносимо. Хреновая идея.

Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +2 +/
Сообщение от псевдонимус (?), 16-Дек-21, 11:31 
А по мне так отличная. Одна железка -- одна программа, гы. Как у макосексуалистов. Правдо гейось это не спасло: оно все равно оно, что платформа, что ось.
Ответить | Правка | Наверх | Cообщить модератору

90. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +2 +/
Сообщение от InuYasha (??), 16-Дек-21, 17:30 
Полностью согла..
*надменно-осуждающие лица дизайнеров из соседней комнаты*
...сен.
*захлопнул дверь*
Ответить | Правка | Наверх | Cообщить модератору

93. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от псевдонимус (?), 16-Дек-21, 19:00 
> Полностью согла..
> *надменно-осуждающие лица дизайнеров из соседней комнаты*
> ...сен.
> *захлопнул дверь*

;))

Но ведь и правда, что нужно: ассемблеры, Фортран, тикль и Шелл. Ну ладно, ц исчо. ) И перл. Для одминов.

Ответить | Правка | Наверх | Cообщить модератору

101. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от _ (??), 16-Дек-21, 23:49 
и жаба - для индусов
и раст - для ******
и пеЙтон - для школоты
и ребе - для замороженных
и плюсы - чтобы можно было в свитер с оленями
...
и брейнфак - потому что это красиво!

ВотЪ! (С) :)

Ответить | Правка | Наверх | Cообщить модератору

94. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от псевдонимус (?), 16-Дек-21, 19:02 
> Полностью согла..
> *надменно-осуждающие лица дизайнеров из соседней комнаты*
> ...сен.
> *захлопнул дверь*

Мля, япро форт забыл. В принципе достаточно его одного. Лучший язык всех времён и народов, я не шучу

Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

102. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от _ (??), 16-Дек-21, 23:51 
Дык все глупости в этом мире сделаны с серьёзным выражение лица! (С) Барон Мюнхгаузен
Ответить | Правка | Наверх | Cообщить модератору

127. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Sw00p aka Jerom (?), 17-Дек-21, 12:02 
не мешайте глупцам совершать глупости (ц) Барон Жером :)
Ответить | Правка | Наверх | Cообщить модератору

129. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от InuYasha (??), 17-Дек-21, 12:32 
Бегите, глупцы! (ц) Гендо... т.е. Гендальф :)


Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +4 +/
Сообщение от Sw00p aka Jerom (?), 16-Дек-21, 11:32 
С доказывает только профнепригодность программистов, которые пишут программы не думая о стеке куче всякой архитектурной хрени
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

110. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (110), 17-Дек-21, 01:37 
>> С доказывает только профнепригодность программистов, которые пишут программы не думая о стеке куче всякой архитектурной хрени

Чтоб об этом думать - надо об этом знать
Последних много лет идет снижение порога входа в отрасль
А коммит в ядро это строчка в резюме
Ревью тоже человеки делают
Ну и вот

Ответить | Правка | Наверх | Cообщить модератору

126. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Sw00p aka Jerom (?), 17-Дек-21, 11:29 
>Последних много лет идет снижение порога входа в отрасль

ну и к чему приведет снижение этого порога? Можно ли опустить допустим знания приоритетов обычных арифметических действий и заниматься вышматом?

Ответить | Правка | Наверх | Cообщить модератору

137. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (110), 18-Дек-21, 03:26 
>> ну и к чему приведет снижение этого порога?

К усилению позиции корпорации-инициатора.

Корпорация может себе позволить нанять нормальных. Знающих про процессор, стек, кэш и страницы памяти. И то что они есть и как работают в разных архитектурах. И учитывающих это всё.

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

Ответить | Правка | Наверх | Cообщить модератору

138. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (110), 18-Дек-21, 03:34 
>> Можно ли опустить допустим знания приоритетов обычных арифметических действий и заниматься вышматом?

В чужой стране - просто необходимо)
Убить системный подход в образовании самый сильный ход наверное.
Пообщайтесь с выпускниками школ. Они даже запоминают плохо. Про мышление, тем более критическое, речи не идет.

Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

140. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Sw00p aka Jerom (?), 18-Дек-21, 11:16 
>В чужой стране - просто необходимо)

план даллеса курит в сторонке, серьезно.

>Убить системный подход в образовании самый сильный ход наверное.

хотелось бы написать про самообразование, но увы это единицы, и школа решает.

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

шпаргалки даже нынче не в моде :) гугл в помощь

Ответить | Правка | Наверх | Cообщить модератору

61. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +1 +/
Сообщение от x3who (?), 16-Дек-21, 12:38 
>  На стеке -- да. Но никак не в куче.

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

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

69. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +3 +/
Сообщение от n00by (ok), 16-Дек-21, 13:51 
>>  На стеке -- да. Но никак не в куче.
> Не догоняю в чем разница. Если тебе в стек напишут данные в
> уже освобождённый буфер по сбежавшему указателю - это разве сильно безопаснее?

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

Ответить | Правка | Наверх | Cообщить модератору

130. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от x3who (?), 17-Дек-21, 12:57 
> Такая запись не испортит актуальные данные, если не выйдет за границы стека
> (в ядре ограничен несколькими страницами). Другое дело, что в положенное место
> запись не прошла, значит там мусор?

Во-первых испортит, если все данные будут храниться на стеке. Во-вторых появляется испортить ещё и как минимум адрес возврата из функции, что вдогонку приведёт к ещё более нехорошим последствиям.

Ответить | Правка | Наверх | Cообщить модератору

131. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от n00by (ok), 17-Дек-21, 15:00 
Тут надо понимать, что такое вершина стека, которую адресует указатель стека. Обычно путаются, потому что стек растёт в сторону младших адресов (т.е. адрес уменьшается). На самом деле от численных значений можно абстрагироваться:

1. создали локальные:

аргумент
адрес возврата
локальная1
локальная2
локальная3
вершина

2. освободили локальная3:

аргумент
адрес возврата
локальная1
локальная2
вершина
локальная3 <- вот сюда пишем по ошибке.

Стековый кадр возможно даже не создавать, не менять SP, если внутри подпрограммы нет вызовов. Просто адресуются ячейки над вершиной (а в цифрах их адреса ниже). Подробнее см. red zone в x86-64-psABI-1.0.pdf

Ответить | Правка | Наверх | Cообщить модератору

139. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от x3who (?), 18-Дек-21, 10:22 
> вершина
> локальная3 <- вот сюда пишем по ошибке.

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


> Обычно путаются, потому что стек растёт в сторону младших адресов (т.е. адрес уменьшается).

ну и что? вот разместил ты на стеке буфер и пишешь в него. По возрастанию адресов. Буфер кончился, а ты по ошибке продолжаешь в него писать. Такую ошибку легко вообразить. И будешь ты переписывать данные и адреса возвратов. Не вижу чем это лучше динамического выделения памяти ппи котором хоть адреса возврата уцелеют если что.

Ответить | Правка | Наверх | Cообщить модератору

141. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от n00by (ok), 18-Дек-21, 11:16 
>> вершина
>> локальная3 <- вот сюда пишем по ошибке.
> совершенно необязательно, что именно сюда только сюда. И даже что пишем необязательн.
> По ошибке можно что хошь прчитать или перезаписать.

Желательно помнить контекст:

#10 >>> а когда кучу надо освободить — это всегда безопасная процедура?
#15 >> На стеке -- да. Но никак не в куче.
#61 > Не догоняю в чем разница. Если тебе в стек напишут данные
#61 > в уже освобождённый буфер по сбежавшему указателю - это разве сильно безопаснее?

освобождённый на стеке - всегда после вершины

>> Обычно путаются, потому что стек растёт в сторону младших адресов (т.е. адрес уменьшается).
> ну и что? вот разместил ты на стеке буфер и пишешь в
> него. По возрастанию адресов. Буфер кончился, а ты по ошибке продолжаешь
> в него писать. Такую ошибку легко вообразить. И будешь ты переписывать
> данные и адреса возвратов. Не вижу чем это лучше динамического выделения
> памяти ппи котором хоть адреса возврата уцелеют если что.

Этот буфер не освобождён и ошибка другая.

Ответить | Правка | Наверх | Cообщить модератору

142. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от x3who (?), 18-Дек-21, 12:30 
> освобождённый на стеке - всегда после вершины

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

> Этот буфер не освобождён и ошибка другая.

желательно помнить контекст - тема про переполнение буфера, так что ошибка будет сабжевая

Ответить | Правка | Наверх | Cообщить модератору

143. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от n00by (ok), 18-Дек-21, 13:38 
>> освобождённый на стеке - всегда после вершины
> Не всегда.

Это следует из определения. Цитирую System V Application Binary Interface AMD64 Architecture Processor Supplement

3.2.2 The Stack Frame
The stack pointer, %rsp, always points to the end of the latest allocated stack frame.

> Вот пример: какой-то код фызвал функцию, которая разместила буфер на
> стеке, пошаманила там что-то и вернула некую структуру в которой одно
> из полей содержит указатель на этот буфер.

В данный момент буфер в стеке освобождён, записи пока нет.

> Вызывающий код про эту структуру даже не курсе, он просто передаёт её
> как параметр другой функции и та вдруг осуществляет доступ по переданному
> указателю куда-то себе в стек, где лежат уже другие данные.

Здесь стек уже занят (под другой буфер). Спасибо, теперь понятно, где я ошибся. В вопросах фигурировало "всегда" и мне следовало бы конкретизировать "в пределах функции", что бы не возникло разночтений. Я понял "уже освобождённый" как "только что освобождённый".

Вот такой код может уронить приложение, поскольку страница вернулась системе:
free(p);
if (*p);

>> Этот буфер не освобождён и ошибка другая.
> желательно помнить контекст - тема про переполнение буфера, так что ошибка будет
> сабжевая

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

Ответить | Правка | Наверх | Cообщить модератору

144. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от x3who (?), 18-Дек-21, 15:20 
> Вот такой код может уронить приложение, поскольку страница вернулась системе:
> free(p);
> if (*p);

Не должен бы. Не знаю, но подозреваю, что кернельские треды уже имеют преаллоцированные стеки. Стеки юзерских процессов судя по наличию функции expand_stack() и отсутствию обратной ( https://github.com/torvalds/linux/blob/master/include/linux/... ) - только растут. Ну и по смыслу на каждое подергивание стека ходить в ядро и освобождать страницы - это очень дорогая операция. Кроме того, даже если ваша программа обратится в произвольную часть стека в пределах лимита на размер стека и там не окажется страницы то никто никуда не упадёт: возникнет исключение в котором ядро скорее всего тупо подложит страницу под ту область куда произошло обращение.


> Тему сменили на обсуждение использования после освобождения, и я отвечал на вполне
> конкретный вопрос про освобождённый стек. Размер записанных данных в вопросе не
> оговаривается, потому я его вывел из условия "освобождённый" - то есть
> не пересекает вершину.

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

Ответить | Правка | Наверх | Cообщить модератору

145. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от n00by (ok), 18-Дек-21, 17:21 
>> Вот такой код может уронить приложение, поскольку страница вернулась системе:
>> free(p);
>> if (*p);
> Не должен бы.

Если освобождаемый блок окажется последним занятым в странице памяти, менеджер кучи может решить вернуть страницу системе и выполнит munmap(). Таким образом адресуемая указателем память окажется недоступна. Самое весёлое, когда подобное совпадение происходит в 1 случае из 100000.

> Не знаю, но подозреваю, что кернельские треды уже имеют
> преаллоцированные стеки.

Писал о них в #74. Размер 8К.

> Стеки юзерских процессов судя по наличию функции expand_stack()
> и отсутствию обратной ( https://github.com/torvalds/linux/blob/master/include/linux/...
> ) - только растут. Ну и по смыслу на каждое подергивание
> стека ходить в ядро и освобождать страницы - это очень дорогая
> операция.

Так free() это не стек. В куче предполагается хранить большие объёмы, а в стеке малые - потому в куче разумно предусмотреть возврат страниц системе, а в стеке они лишний.

> Кроме того, даже если ваша программа обратится в произвольную часть
> стека в пределах лимита на размер стека и там не окажется
> страницы то никто никуда не упадёт: возникнет исключение в котором ядро
> скорее всего тупо подложит страницу под ту область куда произошло обращение.
>> Тему сменили на обсуждение использования после освобождения, и я отвечал на вполне
>> конкретный вопрос про освобождённый стек. Размер записанных данных в вопросе не
>> оговаривается, потому я его вывел из условия "освобождённый" - то есть
>> не пересекает вершину.
> Ну я просто например не понял, почему там народ решил, что освобождение
> памяти в куче чем-то опаснее чем стек, потому и спрашивал.

Наверное, потому что аллоцировать на куче и сохранять указатель - обычная операция (другое дело, что потом с ним работа некорректна). А сохранять указатель на стековые данные - необычная. То есть стек используется как кратковременное хранилище, в таком сценарии перезапись свободной его части безопасна.

P.S. капча 66666 >*-)

Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

147. Скрыто модератором  +/
Сообщение от Аноним (-), 23-Дек-21, 08:28 
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

16. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Корец (?), 16-Дек-21, 10:06 
Да, если с освобождаемой памятью закончена работа и к ней больше не обращаться.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

41. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (41), 16-Дек-21, 11:07 
> а когда кучу надо освободить — это всегда безопасная процедура?

Да.
Как можно не знать таких основ (азов, элементарщины)!

Нельзя обращаться к освобождённой куче.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

70. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от n00by (ok), 16-Дек-21, 13:55 
>> а когда кучу надо освободить — это всегда безопасная процедура?
> Да.
> Как можно не знать таких основ (азов, элементарщины)!
> Нельзя обращаться к освобождённой куче.

Если нельзя, но очень хочется реализовать сборку мусора по алгоритму mark-compact, то можно.

Ответить | Правка | Наверх | Cообщить модератору

12. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –1 +/
Сообщение от Анонн (?), 16-Дек-21, 09:58 
Проблема в том, что при обращении за пределы "своей" памяти по умолчанию происходит... абсолютно ничего! Порти чужую память как хочешь, ты же знаешь что делаешь!
Это нужно включать всякие защиты в виде доп.опций компиляции чтобы оно начинало проверять и ругаться. И конечно оно выключено по умолчанию.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

36. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +1 +/
Сообщение от Онаним (?), 16-Дек-21, 10:50 
Какая "своя память", "чужая память".
Это ядро и ring0, так-то.
Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –3 +/
Сообщение от Аноним (1), 16-Дек-21, 10:00 
Можно это аргументировать так, что куча медленная, но можно же сделать что то типа пулла буферов. Не? Тут смысл просто в том, чтобы не было этого искусственного ограничения из за создания константного массива на стеке, хотя стек в принципе можно тоже выделять и динамически. И чтобы данные не валялись рядом с адресами возврата, которые можно попортить переполнением.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

18. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +1 +/
Сообщение от Корец (?), 16-Дек-21, 10:08 
>куча медленная

Первый раз слышу. Расскажи подробнее.

Ответить | Правка | Наверх | Cообщить модератору

32. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (1), 16-Дек-21, 10:33 
Как работает стек:
SUB RSP, 10H

Как работает куча:
Найти свободный блок
Выделить свободный блок

Стек всегда можно тоже выделять динамически, просто об этом мало кто знает:
//Предполагается fastcall, размер в rax
AllocStack proc
  pop rdx
  sud rsp, rax
  jmp rdx
endp

Ответить | Правка | Наверх | Cообщить модератору

33. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –5 +/
Сообщение от Аноним (-), 16-Дек-21, 10:43 
В х..якс интелбои недоделанные. реализация кучи для усера это malloc в libc, sbrk в ведре и тд . стеки оно попает каком-то говноасме неправославном
Ответить | Правка | Наверх | Cообщить модератору

39. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +6 +/
Сообщение от Аноним (1), 16-Дек-21, 10:56 
Ну да. А malloc за счет духа святого работает. Вот и выросло поколение, которое думает, что выделение памяти - это бесплатная операция. А ведь когда то в давние времена все данные были статичным, в том числе и объекты, именно потому, что это далеко не так.
Ответить | Правка | Наверх | Cообщить модератору

49. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –1 +/
Сообщение от Аноним (-), 16-Дек-21, 11:26 
> А malloc за счет духа святого работает.

в сообщении выше так и сказано. динамической памятью занимается операционная система.

> в давние времена все данные были статичным, в том числе и объекты

т.е ты предлагаешь начать растягивать стек ? ты или ни..я не понимаешь о чем говоришь, либо мосок решил повыносить, но скорее первое.

Ответить | Правка | Наверх | Cообщить модератору

103. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от szt1980 (ok), 16-Дек-21, 23:52 
В рылотайме оно то сих пор не так, программирование его на древних процессорах вправляет мозги.
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

148. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (-), 23-Дек-21, 08:30 
Собственно никто не заставляет использовать динамическое выделение памяти в своих программах. Но есть нюанс, размер стека не резиновый, и если вы хотите 100 мегов - в стеке их элементарно не окажется. Более того, вы об этом узнаете довольно неприятным способом. Каким именно? А закажите себе VLA покрупнее, как раз и узнаете почему их не любят.
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

40. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –3 +/
Сообщение от Аноним (1), 16-Дек-21, 10:59 
И да. По мне так AT&T не православный асм, ибо куча знаков препинания ненужных.
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

75. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от n00by (ok), 16-Дек-21, 14:36 
Злодеи они, запретили man alloca. Впрочем, правильно сделали.
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

78. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (-), 16-Дек-21, 14:53 
если не понимаешь о чем речь - проходи мимо, не позорься
Ответить | Правка | Наверх | Cообщить модератору

79. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от n00by (ok), 16-Дек-21, 14:57 
А о чём речь? sbrk в ядре? Азазазаза. https://www.kernel.org/doc/htmldocs/kernel-api/mm.html
Ответить | Правка | Наверх | Cообщить модератору

85. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (-), 16-Дек-21, 15:46 
сейчас до тебя дойдет что это работа памятью в кернелспейсе ... продолжай перебор, может докопаеш к вечеру
Ответить | Правка | Наверх | Cообщить модератору

120. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от n00by (ok), 17-Дек-21, 08:45 
Работа с памятью в, цитирую новость: подсистеме ядра Linux, происходит в кернелспейсе?! Какая неожиданность. Я думал, ядро - это то, на чём Мюнхгаузен летал в земли юзеров.
Ответить | Правка | Наверх | Cообщить модератору

55. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Урри (ok), 16-Дек-21, 11:35 
man alloca, Аноним.
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

123. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (123), 17-Дек-21, 09:54 
Может не будем языком молоть и просто проведем тест?

Скажем миллион раз сделаем malloc и free.
Миллион раз сделаем sub rsp, x и add rsp, x.

Потом сравним результаты.

Ответить | Правка | Наверх | Cообщить модератору

132. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Урри (ok), 17-Дек-21, 15:03 
Аноним настолько туп, что не может отличить "alloca" от "malloc"?

Аноним НАСТОЛЬКО туп, что допускает неспособность оппонента отличить вызов функции от инкремента/декремента регистра?

Аноним, небось, еще и поклонник раста? Я угадал?

Ответить | Правка | Наверх | Cообщить модератору

63. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от x3who (?), 16-Дек-21, 12:51 
1. Ты забыл про путешествия в ядро за физическими страницами памяти, что для стека что для кучи. Это очень медленно и при этом куча умеет эти страницы придерживать для переиспользования.

2. На стеке ты сильно много данных не разместишь, дефолтный ulimit 8Мб, ну можно его раздвинуть, но тоже несравнимо с адресным пространством данных

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

74. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от n00by (ok), 16-Дек-21, 14:30 
>[оверквотинг удален]
> Как работает куча:
> Найти свободный блок
> Выделить свободный блок
> Стек всегда можно тоже выделять динамически, просто об этом мало кто знает:
> //Предполагается fastcall, размер в rax
> AllocStack proc
>   pop rdx
>   sud rsp, rax
>   jmp rdx
> endp

Как и об этом:

x86_64 page size (PAGE_SIZE) is 4K.

Like all other architectures, x86_64 has a kernel stack for every
active thread. These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big

https://www.kernel.org/doc/Documentation/x86/kernel-stacks

>   pop rdx
>   sud rsp, rax
>   jmp rdx

Так делать не рекомендуется из соображений производительности. Да и прикиньте размеры опкодов - их экономичнее встроить вместо call.

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

64. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Совершенно другой аноним (?), 16-Дек-21, 13:18 
Можно, и даже уже сделано - в ядре есть и разные slab/slub аллокаторы, и kmalloc и чего только нет. Но в данном случае программист выделил буфер на стеке, потому-что выделять через аллокаторы дороже (на стеке это буквально несколько команд, а всё остальное это вызовы функций и беготня по другим подсистемам ядра).
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

5. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (5), 16-Дек-21, 09:38 
да кстати, пацаны, почему каждая либа изобретает свой собственный менеджер памяти? в libxml2 есть какой-то собственный xmlBuf, а у xerces там вообще страшно смотреть на ихнее дерево классов, посвященное только управлению памяти. Почему нельзя догадаться сделать какой-нибудь libmem, который будет это все делать правильно и унифицировано?
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

20. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +2 +/
Сообщение от Иноагент (?), 16-Дек-21, 10:15 
Можно. Разрешаю.
Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +4 +/
Сообщение от lombock (?), 16-Дек-21, 10:22 
> который будет это все делать правильно и унифицировано

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

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

50. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –1 +/
Сообщение от Аноним (-), 16-Дек-21, 11:29 
> да кстати, пацаны, почему каждая либа изобретает свой собственный менеджер памяти

шоп на выхаде ты такой стоя спиной к эффектному взрыву говоришь - free(xmlBuf) , и уходишь за фокус камеры, можно еще фак в сторону мелкософтного жималока показать

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

58. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –1 +/
Сообщение от Аноним (58), 16-Дек-21, 11:59 
Так уже один ржавый язык придумал, так теперь огромная пачка олдфагов ходит и пердит в каждом топике о ненужности.

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

Вообще переработать apr и воткнуть в стандарт C22

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

66. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +2 +/
Сообщение от Урри (ok), 16-Дек-21, 13:23 
Очередной растишечка расписался в профнепригодности.
Ответить | Правка | Наверх | Cообщить модератору

82. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от РастоманПитонофил (?), 16-Дек-21, 15:37 
ахаха, это пять.
Ответить | Правка | Наверх | Cообщить модератору

149. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (-), 23-Дек-21, 08:32 
Это он сгоряча, он просто маны на unsafe на раст не читал.
Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

38. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +4 +/
Сообщение от Онаним (?), 16-Дек-21, 10:54 
В ядре?
Ну ладно, указанный случай ещё терпимо.
Но вот пожелаю вам в обработчиках прерываний всю жизнь динамически буферы выделять.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

76. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –1 +/
Сообщение от BorichL (ok), 16-Дек-21, 14:37 
Ты когда молотком по пальцу попадаешь, это молоток виноват или это ты криворукий придурок?
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

118. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Прохожий (??), 17-Дек-21, 07:44 
Есть автоматизированные молотки. Там тяжело, если вообще возможно, по пальцу попасть. Так что - да, если молотком можно попасть по пальцу - это плохой молоток.
Ответить | Правка | Наверх | Cообщить модератору

133. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от BorichL (ok), 17-Дек-21, 16:58 
> Есть автоматизированные молотки. Там тяжело, если вообще возможно, по пальцу попасть. Так
> что - да, если молотком можно попасть по пальцу - это
> плохой молоток.

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

https://www.youtube.com/watch?v=xA7W1vxYYlE

там ещё продолжение есть, можно посмотреть на результат с 1:20 https://www.youtube.com/watch?v=vfUZVyBlca0

Ответить | Правка | Наверх | Cообщить модератору

119. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Прохожий (??), 17-Дек-21, 07:45 
А придурок тот, кто этого не понимает.
Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

134. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от BorichL (ok), 17-Дек-21, 17:00 
> А придурок тот, кто этого не понимает.

Не, придурок тот, кто думает, что автоматика за него всё сделает, а он только кнопочку нажмёт.

Ответить | Правка | Наверх | Cообщить модератору

150. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (-), 23-Дек-21, 08:33 
Так его как раз и уволят - кнопку так то и робот жать может, да и кнопку можно убрать, роботу она ни к чему.
Ответить | Правка | Наверх | Cообщить модератору

155. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от BorichL (ok), 23-Дек-21, 14:02 
> Так его как раз и уволят - кнопку так то и робот
> жать может, да и кнопку можно убрать, роботу она ни к
> чему.

Именно так  :-) Сейчас нейросети научат растоманить и все "безопасные программисты" пойдут на мороз  ;-)

Ответить | Правка | Наверх | Cообщить модератору

84. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от richman1000000 (ok), 16-Дек-21, 15:44 
Потом от вашей динамической памяти страдают целые сервера.
программировать нормально надо, а не задним местом!!
А ошибки в коде - это нормально, люди ведь пишут, и находят и исправляют. Так мы и эволюционируем, из обезьяны  в профессионалы.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –12 +/
Сообщение от Аноним (3), 16-Дек-21, 09:36 
Пока ядро не переведут на более адекватные языки - оно так и будет рассадником дыр
Ответить | Правка | Наверх | Cообщить модератору

7. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +6 +/
Сообщение от Аноним12345 (?), 16-Дек-21, 09:48 
Я даже знаю, какой адекватный язык вы имеете ввиду
Ответить | Правка | Наверх | Cообщить модератору

30. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +5 +/
Сообщение от Fracta1L (ok), 16-Дек-21, 10:31 
Догадаться нетрудно
Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (58), 16-Дек-21, 12:01 
Ты на нем попробуй напищи чего-нить... там что не действие то боль сплошная. А в сях ращбереться даже карапуз
Ответить | Правка | Наверх | Cообщить модератору

62. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –1 +/
Сообщение от Fracta1L (ok), 16-Дек-21, 12:44 
Ахахаха, это пять)
Ответить | Правка | Наверх | Cообщить модератору

151. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (-), 23-Дек-21, 08:36 
Покажи свои проекты на расте, чудик? Ты вообще видел шоу с поддержкой раста в ядре? Там куда ни ткни, подпорки и костыли, в найтли уже почти работает, но у нас там косяк с архитектурой либы и рантайма вышел, мы работаем над этим!!!111

А пакамест проапдейтите сборку окислов запуском неподписаного шелскриптика с хз какого сайта вот. Безопасность.

Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +1 +/
Сообщение от Rev (?), 16-Дек-21, 13:37 
Вот карапузы и ваяют эти уязвимости как раз :))
Не смог разобраться в Расте - не лезь в ядро. Так должно быть.
Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

83. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +2 +/
Сообщение от РастоманПитонофил (?), 16-Дек-21, 15:38 
> Не смог разобраться в Расте - не лезь в ядро. Так должно быть.

Не смог осилить элементарный C не лезь вообще никуда. Улицы убирай, срачь кругом.

Ответить | Правка | Наверх | Cообщить модератору

88. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от _ (??), 16-Дек-21, 16:13 
> Не смог осилить элементарный C не лезь вообще никуда. Улицы убирай, срачь кругом.

https://www.misra.org.uk/misra-c/
https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Cod...
> SEI CERT C Coding Standard

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


Ответить | Правка | Наверх | Cообщить модератору

121. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Fracta1L (ok), 17-Дек-21, 09:09 
Предлагаешь всем без исключения программистам на сишке пойти мести улицы? какая жестокость
Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

152. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (-), 23-Дек-21, 08:36 
А ядро тебе кто будет тогда патчить, чтобы ты тут мог умные коменты строчить?
Ответить | Правка | Наверх | Cообщить модератору

115. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от искра (?), 17-Дек-21, 04:08 
точно! этот язык — D
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

122. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Fracta1L (ok), 17-Дек-21, 09:09 
Кстати, интересный язык. Всё хочу на нём свой пакетный менеджер переписать.
Ответить | Правка | Наверх | Cообщить модератору

128. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Sw00p aka Jerom (?), 17-Дек-21, 12:05 
вот о чем я говорил, калькулятор вменяемый сначала напишите, а дальше хоть ядро :)
Ответить | Правка | Наверх | Cообщить модератору

153. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (-), 23-Дек-21, 08:37 
Ты на нем хоть что-нибудь написать смог? Синтаксис у него больно уж... кислотненький :)
Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

154. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Fracta1L (ok), 23-Дек-21, 08:58 
В каком смысле? Там же вроде питоноподобный синтаксис?
Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Урри (ok), 16-Дек-21, 11:37 
Да все знают.
Нет ядра - нет дыр.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

9. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +4 +/
Сообщение от Анонм (?), 16-Дек-21, 09:53 
На яваскрипт, что ли?
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

14. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –4 +/
Сообщение от Анонимemail (10), 16-Дек-21, 10:05 
пф хуже этой солянки даже не знаю что сыскать, разве что c++/golang/rust
Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +4 +/
Сообщение от Брат Анон (ok), 16-Дек-21, 10:06 
Что в этом списке делает golang? Тонны годного софта на нём. И не падает.
Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –3 +/
Сообщение от Аноним (-), 16-Дек-21, 10:45 
тонко, особенно про годный :D
Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +2 +/
Сообщение от Брат Анон (ok), 16-Дек-21, 11:10 
> тонко, особенно про годный :D

В каждой шутке -- лишь доля шутки. Всё остальное правда.

Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –1 +/
Сообщение от Аноним (-), 16-Дек-21, 11:32 
> доля

почти не падает растяжимое понятие, раз в час это тоже почти.

Ответить | Правка | Наверх | Cообщить модератору

87. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –1 +/
Сообщение от Аноним (87), 16-Дек-21, 16:03 
Главное заставить других верить в эту правду, да?
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

47. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +1 +/
Сообщение от AlexVRud (ok), 16-Дек-21, 11:21 
- Тут 12309 опять вернулся.
- Да врёте вы всё, это сборка мусора в ядре.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

26. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +2 +/
Сообщение от lombock (?), 16-Дек-21, 10:25 
проснись, соня, уже давно. почему не пользуешься? а дистриб почему не сделал?

https://bellard.org/jslinux/
https://retrage.github.io/lkl-js/

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

27. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +2 +/
Сообщение от Анонм (?), 16-Дек-21, 10:27 
ЕСЛИ дыра_в_ядре РАВНО ЕСТЬ!
    НЦ
      ПЕЧАТЬ кавычка Обноружена дыра в ядре!!! кавычка
    КЦ
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

136. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от vitalif (ok), 18-Дек-21, 02:12 
Будяк Д.В, перелогиньтесь
Ответить | Правка | Наверх | Cообщить модератору

29. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от lombock (?), 16-Дек-21, 10:29 
какие адекватные?
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

86. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (87), 16-Дек-21, 16:01 
C#, Java, Python или любой другой язык с управлением памятью
Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (91), 16-Дек-21, 18:27 
"Иди ты на фиг, прерываеие реального времени, у меня тут GC работает, не до тебя сейчас".
Ответить | Правка | Наверх | Cообщить модератору

92. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от _ (??), 16-Дек-21, 18:55 
>> RTSJ / Java RTS Sun
> "Иди ты на фиг, прерываеие реального времени, у меня тут GC работает, не до тебя сейчас".

И слышавшие звон/опоздавшие родиться - пусть идут туда же.


Ответить | Правка | Наверх | Cообщить модератору

96. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –1 +/
Сообщение от Хероптерикс (?), 16-Дек-21, 21:08 
Эвон чего откопали. Как у него с оверхэдом было? Как у обычной явы, я полагаю. С работой не внутри какого-нибудь Websphere, а прямо поверх железа, как и положено операционке? Точно так же. Хоть одно обновление за 15 лет? Тоже все плохо. Про аналоги для C# и (прастихоспади) питона даже спрашивать страшно.
Ответить | Правка | Наверх | Cообщить модератору

97. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от _ (??), 16-Дек-21, 21:42 
> Эвон чего откопали. Как у него с оверхэдом было? Как у обычной

Занятный спрыг с темы. Опеннетно-классический.
> Про аналоги для C# и (прастихоспади) питона даже спрашивать страшно.

Ну, запретить опеннетчикам писать глупости я не могу, так что ... крепитесь там!

Ответить | Правка | Наверх | Cообщить модератору

104. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (91), 16-Дек-21, 23:55 
Т.е. по теме аргументов нет, кроме "сам дурак"? Ок, ясно-понятно.
Ответить | Правка | Наверх | Cообщить модератору

106. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от _ (??), 17-Дек-21, 00:42 
> Т.е. по теме аргументов нет, кроме "сам дурак"?

Т.е. ты сам шутсро спрыгнул с темы "Иди ты на фиг, прерываеие реального времени, у меня тут GC работает, не до тебя сейчас", зато ожидал каких-то аргументов по теме твоего спрыга?
> Ок, ясно-понятно.

Рад за тебя.

Ответить | Правка | Наверх | Cообщить модератору

111. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (91), 17-Дек-21, 01:42 
Прерывания. С 10x оверхедом. С динамическим выделением памяти. С кеш-промахами во все поля. Я правда не знаю, как это серьезно обсуждать.
Ответить | Правка | Наверх | Cообщить модератору

112. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от _ (??), 17-Дек-21, 01:54 
===
Memory Management

Garbage-collected memory heaps have always been considered an obstacle to real-time programming due to the unpredictable latencies introduced by the garbage collector. The RTSJ addresses this issue by providing several extensions to the memory model, which support memory management in a manner that does not interfere with the ability of real-time code to provide deterministic behavior. This goal is accomplished by allowing the allocation of objects outside of the garbage-collected heap for both short-lived and long-lived objects.
===
> Прерывания. С 10x оверхедом. С динамическим выделением памяти. С кеш-промахами во все поля.
> Я правда не знаю, как это серьезно обсуждать.

Я тоже не знаю, зачем обсуждать фантазии анонима.

Ответить | Правка | Наверх | Cообщить модератору

113. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (91), 17-Дек-21, 02:10 
Да, мне тоже пришлось это прочитать, когда вы упомянули RTSJ. Да, они (частично) избавились от gc lock. А теперь объясните, ради бога, куда делись остальные причины, которые делают этот RTSJ провалившимся академическим экспериментом, непригодным для решения заявленой в заголовке новости проблемы.
Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от изнасилованжурналистом50летназад (?), 16-Дек-21, 09:39 
>до 65 КБ

т.е. до 64 КБ включительно, т е. просто 64 КБ, а не почему то 65 КБ?

Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +6 +/
Сообщение от Аноним (8), 16-Дек-21, 09:49 
Акция! 1 Кб в подарок!
Ответить | Правка | Наверх | Cообщить модератору

11. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (1), 16-Дек-21, 09:57 
Ага. Это как во времена AT. Купи 640Кб, 65520 в подарок.
Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (41), 16-Дек-21, 11:18 
Нет.
До 65 КБ - это 64 КБ плюс 1023 байт (999 если СИ сильно жмет)
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

71. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (65), 16-Дек-21, 14:01 
64 kiB ~ 65.5 kB
киби - 2^10
кило - 10^3
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

80. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +1 +/
Сообщение от Онаним (?), 16-Дек-21, 15:01 
Не ~65.5, а ровно 65.536
Ответить | Правка | Наверх | Cообщить модератору

21. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +3 +/
Сообщение от InuYasha (??), 16-Дек-21, 10:16 
Андроед рутануть даст? plug & pray
Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +1 +/
Сообщение от Анонн (?), 16-Дек-21, 10:18 
Ну подумаешь, выполнение произвольного кода при работе с юсб-устройством! Просто не пользуйтесь юсб, это все смузихлебство, lpt должно хватить всем! Но зато как быстро! И да, это все погромисты неправильные попались!
Ответить | Правка | Наверх | Cообщить модератору

35. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (-), 16-Дек-21, 10:47 
> Просто не пользуйтесь юсб, это все смузихлебство, lpt должно хватить всем!

Ох еслиб, выпилили лптшки комерсы поганые

Ответить | Правка | Наверх | Cообщить модератору

42. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (42), 16-Дек-21, 11:07 
Эта хреновина (USB Gadget) в обычных потребительских дистрибутивах
не используеься, более того даже не присутствует в основных репах.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

28. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  –5 +/
Сообщение от Аноним (28), 16-Дек-21, 10:28 
ну вот сколько анонимы опеннета им будут повторять, что дырявая сишка их в могилу сведёт, столько они будут в могилу сводиться
Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +3 +/
Сообщение от Аноним (-), 16-Дек-21, 10:51 
так они и жили. дырявая сишка сводила всех в могилу, а потом уставшие, но довольные возвращались домой и пили чай с пряниками.
Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +1 +/
Сообщение от User_o0 (?), 16-Дек-21, 12:25 
Ох а сколько уязвимостей ещё не обнаружили...
Ответить | Правка | Наверх | Cообщить модератору

73. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (73), 16-Дек-21, 14:15 
Еще один бек-дор для СС (с служб) открыли. И их еще много остается!
Ответить | Правка | Наверх | Cообщить модератору

81. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (81), 16-Дек-21, 15:36 
ну да, ядро обновил со 190м бинарных вставок и вытер шок с лица
Ответить | Правка | Наверх | Cообщить модератору

99. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (99), 16-Дек-21, 22:19 
Webusb из хрома передаёт привет или он не подвержен?
Ответить | Правка | Наверх | Cообщить модератору

116. "Уязвимость в подсистеме Linux-ядра USB Gadget, потенциально ..."  +/
Сообщение от Аноним (116), 17-Дек-21, 05:38 
>В дистрибутивах проблема пока остаётся неисправленной

Ну, как обычно...

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру