The OpenNET Project / Index page

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



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

"Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять свои привилегии в системе"  +/
Сообщение от opennews (??), 12-Апр-23, 13:52 
В ядре Linux выявлены две уязвимости (CVE-2023-1281, CVE-2023-1829), позволяющие локальному пользователю поднять свои привилегии в системе. Для проведения атаки требуются полномочия на создание и изменение классификаторов трафика, доступные при наличии прав CAP_NET_ADMIN, которые можно получить при возможности создания пространств имён идентификаторов пользователя (user namespace). Проблемы проявляются начиная с ядра 4.14 и устранены в ветке 6.2...

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

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

Оглавление

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

2. Сообщение от Denys (??), 12-Апр-23, 13:57   +/
"обращением к памяти после её освобождения (use-after-free)"

классика С/С++, сколько ещё будет таких уязвимостей?

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

3. Сообщение от Аноним (3), 12-Апр-23, 14:01   +9 +/
Что-то этот ваш "user namespace" какой-то перфорированный всё время.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #18, #72, #94

5. Сообщение от marten (ok), 12-Апр-23, 14:08   +/
И опять use-after-free...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #71, #75

6. Сообщение от Аноним (10), 12-Апр-23, 14:10   +/
...ваши предложения?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #19, #20, #21, #37, #77, #124

10. Сообщение от Аноним (10), 12-Апр-23, 14:12   +2 +/
Это кого надо спейс. И они его доят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #130

18. Сообщение от Аноним (18), 12-Апр-23, 14:41   +/
Слишком вкусная фича, чтобы от нее отказываться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

19. Сообщение от Rock (?), 12-Апр-23, 14:47   +/
> ...ваши предложения?

Очевидно же -- free должна портить память. Либо скорость, либо безопасность.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #66

20. Сообщение от Анонимусс (?), 12-Апр-23, 14:49   +1 +/
Предлагаю сишникам наконец-то перестать портить память!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

21. Сообщение от Аноним (21), 12-Апр-23, 14:51   +1 +/
собирать мусор 30 минут, как в джаваскрипте
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #102

22. Сообщение от Аноним (22), 12-Апр-23, 14:51   +/
Мне кажется адепты "это не язык виноват, это программисты" ОБЯЗАНЫ фиксить такие баги и формально доказывать корректность фиксов =)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38, #56

26. Сообщение от Анонин (?), 12-Апр-23, 15:01   +/
Предлагаю сишникам перестать делать use-after-free!
Это же всего-лишь нужно вызывать free только один раз, они что не в состоянии??
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #31

28. Сообщение от Анонн (?), 12-Апр-23, 15:04   +2 +/
Ядро 4.14 вышло в ноябре 2017 года.
И никто ничего не заметил. Печально.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30, #83

30. Сообщение от Аноним (18), 12-Апр-23, 15:06   +4 +/
> никто ничего не заметил

Ты пишешь под новостью, в которой кто-то что-то все-таки заметил.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #48

31. Сообщение от Ivan_83 (ok), 12-Апр-23, 15:12   +2 +/
Вы даже не поняли смысла "use-after-free" а что то предлагаете.

uint8_t *ptr = malloc(10);
ptr[0] = 123;
free(ptr);
ptr[0] = 123; /* Вот тут use-after-free */

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

Если бы было объявлено как: free(void **ptr) и не только освобождало память но и зануляло указатель то use-after-free встречалось бы в разы реже.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #34, #78

34. Сообщение от Аноним (10), 12-Апр-23, 15:16   –2 +/
Когда не выкупают иронию и самый простой юмор это уже старость.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #54

37. Сообщение от FF (?), 12-Апр-23, 15:25   –3 +/
да они не понимают, что такие ситуации можно отследить только контролем за каждой ссылкой, а значит затормаживанием операций, это же в многозадачной среде никакой канпилятор не отследит, т.к. они асинхронно работают, а за всеми проверками не уследишь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

38. Сообщение от FF (?), 12-Апр-23, 15:26   +1 +/
мне кажется, адепты, которым кто-то чего-то должен, просто не могут достать из лужи выпавшую соску сидя в коляске
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #45

44. Сообщение от Аноним (44), 12-Апр-23, 15:33   +/
На gentoo в новости две ссылки, и обе на несуществующий CVE
Ответить | Правка | Наверх | Cообщить модератору

45. Сообщение от Аноним (22), 12-Апр-23, 15:35   –1 +/
А почему нужно быть должным кому-то? Иксперды лучше-всех-написаторы могут быть должны себе, ну просто чтобы не быть балаболами. Но, как мы видим, это им не очень интересно. Ведь болтать не мешки ворочать, толк из чип =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

48. Сообщение от Rev (?), 12-Апр-23, 15:48   +2 +/
Всего-то 6 лет понадобилось чтобы заметить. Подумаешь!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #52

52. Сообщение от Аноним (10), 12-Апр-23, 15:57   +1 +/
А в шинды такой же дыре уже 30 лет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #126

54. Сообщение от Ivan_83 (ok), 12-Апр-23, 16:00   +/
Не вижу юмора в том, что человек путает double-free и use-after-free.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #73

56. Сообщение от Аноним (56), 12-Апр-23, 16:04   +2 +/
Адепты "язык все исправит" вызвались написать свою ОС без "этих несчастных C проблем" и пока написали только memory leak (что иронично), а теперь почему-то очень уж хотят писать на своём языке в "дырявой системе написанной дедами"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #69, #135

57. Сообщение от Аноним (57), 12-Апр-23, 16:09   +1 +/
> kernel.unprivileged_userns_clone=0

Уже было. Оказыватся, я уже это делал давно, судя по конфигам.

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

59. Сообщение от Аноним (10), 12-Апр-23, 16:17   +2 +/
Кто-то всё знал и молчал...пора размотать этот клубок заговоров и лжи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #136

66. Сообщение от Аноним (18), 12-Апр-23, 16:40   +/
> Либо скорость, либо безопасность

насколько это:

    free(ptr);

быстрее, чем это:

    free(ptr);
    ptr = NULL;

?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #67, #165

67. Сообщение от Аноним (67), 12-Апр-23, 16:52   +2 +/
Незаметно.
Удивительно, что дизайнеры C/POSIX API не сделали так, чтобы этот NULL возвращала функция free() после успешного освобождения.
ptr = free(ptr);
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #76, #123

68. Сообщение от Анонимусс (?), 12-Апр-23, 16:53   –3 +/
Если я усну и проснусь через десят лет и меня спросят, что сейчас происходит в си кодах, я отвечу: портят память и рут получают.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #116

69. Сообщение от Анонимусс (?), 12-Апр-23, 16:54   +/
Как будто без этого "дырявая система написанная дедами" стала менее дырявой?
А писать в ней хотят как раз чтобы сделать ее лучше!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #90

71. Сообщение от Иваня (?), 12-Апр-23, 16:58   +/
Не ной, сделай чекер, который будет находить такое и исправлять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #74

72. Сообщение от пох. (?), 12-Апр-23, 17:02   +2 +/
ну так что ты хочешь от механизма дающего юзеру рута но не вот совсем совсем а так... на пол-шишечки?

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

73. Сообщение от Анонин (?), 12-Апр-23, 17:04   –1 +/
Прости чувак, хаскелистам не интересно разбираться в сортах ваших сишных багов.
Но спасибо, буду знать. Но тогда предлагаю запретить и то, и другое!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #119, #134

74. Сообщение от Аноним (74), 12-Апр-23, 17:04   +/
зачем чекер ? достаточно просто в chatGPT написать - сделай нам хорошо; и всё, делов то на пару минут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

75. Сообщение от анон (?), 12-Апр-23, 17:06   +/
/fix
Опять дырявая x86.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #105, #26

76. Сообщение от Аноним (18), 12-Апр-23, 17:13   +1 +/
ты можешь написать макрос, который будет вызывать free() и обнулять переменную. Вызывать так: clear(ptr). Оставлю тебе на дом, каким должен быть #define clear.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #79

77. Сообщение от Аноним (77), 12-Апр-23, 17:26   +1 +/
Уже много раз повторялось - прикрутите вы нормальный менеджер памяти типа FastMM, который в FullDebugMode будет жутко тормозить, но зато показывать вообще все возможные косяки. А если будут програть наугад как сейчас, то так и будут вечно страдать от своих use-after-free.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #133

78. Сообщение от Аноним (77), 12-Апр-23, 17:28   +/
Привет FreeAndNil из паскаля. Так может C++ не такой уж классный?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #125

79. Сообщение от InuYasha (??), 12-Апр-23, 17:37   +1 +/
Вот, только каждый программист напишет своих подобных костылей с разными названиями и поведением - и сиди, сходи с ума, изучая всё это. Хотя, даже позикс иногда объявляется устаревшим - что уж там...
PS: только не макрос лучше, а инлайн, наверное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #84

81. Сообщение от InuYasha (??), 12-Апр-23, 17:39   +/
Кто-нить ещё помнит, зачем отключали QoS во времена Win98? :)))) Вот, теперь и в Линухе пора.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #92, #101

83. Сообщение от ИмяХ (?), 12-Апр-23, 17:54   +1 +/
Все видели, кому это надо было. Писали руткиты и продавали их, и/или получали заказы на взломы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

84. Сообщение от Аноним (18), 12-Апр-23, 17:54   +/
это лучше, чем заставлять free возвращать что-то там, хотя на самом деле ему возвращать особо нечего. Незачем городить дополнительные машинные коды ради какого-то призрачного удобства при разработке. Если нужно удобство, пили макросы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #98

90. Сообщение от Аноним (10), 12-Апр-23, 18:11   +/
Как будто с растом что-то изменится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #117, #139

92. Сообщение от Аноним (10), 12-Апр-23, 18:13   +1 +/
Потому что они хотели чтобы все ушли в NT где всё сделают правильно. Вин98 это веселенький гуй под досом. Почему линукс не может сделать тоже самое чтобы приложеньки всегда запускались? Это не ко мне.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #108

94. Сообщение от Аноним (94), 12-Апр-23, 18:23   –2 +/
Спасибо дидам с их офигенными идеями про привилегированные порты. В семидесятые это может быть и была хорошая идея, но уже в начале века было ясно, что от этого костыля надо избавляться. Почему за 20 лет не избавились — загадка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #128, #129

97. Сообщение от Егор (??), 12-Апр-23, 18:39   –1 +/
Я не понял они просто выбросили модуль вместо исправления?
От трюкачи ))
Ответить | Правка | Наверх | Cообщить модератору

98. Сообщение от InuYasha (??), 12-Апр-23, 18:55   –1 +/
По мне - так любая функция должна возвращать если не HRESULT, то хоть bool success. Ну, не glVertex3f, конечно, где прям за каждый такт трясёшься. (да, я знаю! это просто пример!)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #99

99. Сообщение от InuYasha (??), 12-Апр-23, 18:56   +/
И, да, я знаю про try - throw - catch, но оно дико стрёмное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #157

101. Сообщение от Аноним (67), 12-Апр-23, 19:15   +/
Потому, что там от QoS не было толку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

102. Сообщение от Аноним (102), 12-Апр-23, 19:19   –1 +/
В JS (V8,JavaScriptCore) довольно быстрый сборщик мусора - в отличие от сишного дидовского кода, где memory-leak-мусор по всей системе и убирать его не спешат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #121, #132

105. Сообщение от Michael Shigorinemail (ok), 12-Апр-23, 20:11   +/
Ну кстати, -mptr128 на e2k рубит и use-after-free.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

106. Сообщение от Michael Shigorinemail (ok), 12-Апр-23, 20:18   –3 +/
> userns

Не понимаю тех, кто просит его включить.

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

107. Сообщение от Аноним (108), 12-Апр-23, 20:53   +/
12-04-2023 20:51:23
Gentoo, RHEL, SUSE, Fedora, Gentoo, Arch нет этого CVE в багтрекере.
Отреагировали только Debian и Ubuntu.
Ответить | Правка | Наверх | Cообщить модератору

108. Сообщение от Аноним (108), 12-Апр-23, 21:04   +1 +/
У меня складывается впечатление, что все DE в linux это Win98 над MS-DOS. Я не сравниваю ни DE с Win98 ни GNU/Linux с MS-DOS. Всё не в пользу майкрософт. Но что-то похожее.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #127

109. Сообщение от Аноним (109), 12-Апр-23, 21:43   +/
В Debian 10 этот параметр выключен и тем не менее завели на него статус уязвимо.
В RHEL, Fedora, SUSE, Arch, Gentoo даже нет в базе этого CVE. Допустим они подумали, что он по умолчанию выключен. Но ведь можно и включить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #153

114. Сообщение от Аноним (126), 12-Апр-23, 22:12   +/
Дебиан 9 как всегда торт :)))
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #137, #145

115. Сообщение от Аноним (116), 12-Апр-23, 23:08   +/
>bookworm    6.1.20-1    fixed
>sid    6.1.20-2    fixed

Молодцы.

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

116. Сообщение от Аноним (116), 12-Апр-23, 23:10   +/
Правильный ответ будет "ничего не происходит", ибо искусственному интеллекту Cи не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

117. Сообщение от Аноним (117), 13-Апр-23, 00:33   +/
Доказать эти сомнения элементарно - приведи пример аналогичного бага в раст коде =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #162

119. Сообщение от Аноним (119), 13-Апр-23, 02:05   +/
Как и сишникам в сортах функторов и ко(про)монад. Понаделают своего абстрактного иммутабельного гуано, что потом GC не затыкается
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #143

121. Сообщение от Аноним (21), 13-Апр-23, 07:07   +/
джаваскрипт легендарен своей текущей jvm, учи матчасть
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

123. Сообщение от n00by (ok), 13-Апр-23, 07:27   +/
> Удивительно, что дизайнеры C/POSIX API не сделали так, чтобы этот NULL возвращала
> функция free() после успешного освобождения.
> ptr = free(ptr);

А в случае неуспешного освобождения что будет возвращать free()?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #131

124. Сообщение от n00by (ok), 13-Апр-23, 07:35   +/
std::unique_prt<>

Но это породит новые проблемы, из-за использования двух языков. Потому Линус берёг хрупкий внутренний мир бородатых сишников.

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

125. Сообщение от n00by (ok), 13-Апр-23, 07:38   –2 +/
Может стоит научиться отличать Си от Си++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #141

126. Сообщение от Аноним (126), 13-Апр-23, 07:50   +/
это другое
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

127. Сообщение от Аноним (126), 13-Апр-23, 07:51   +/
> Но что-то похожее.

в чем похожесть?

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

128. Сообщение от Аноним (-), 13-Апр-23, 09:01   +/
А при чем тут привилегированные порты? В уязвимости ни слова про это, там какие-то экзотичные краевые ситуации, когда раз в год и палка стреляет.

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

Однако с практической точки зрения - найти вот именно такой конфиг еще постараться надо, так что реальный масштаб проблемы - мизерный. А часто вы бываете в контейнере, с правами CAP_NET_ADMIN, чтобы оттуда наружу лезть? Ну вот то-то и оно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #148

129. Сообщение от 1 (??), 13-Апр-23, 09:04   +/
Это типа про "звон" ? Причём тут порты ? Тут как раз про любимые контейнеры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #149

130. Сообщение от Аноним (-), 13-Апр-23, 09:07   +1 +/
Можно подумать это специально. Ядро не делали с учетом таких вещей, изначально система была одна, контейнеров не было, ядро считало CAP_NET_ADMIN безусловным сигналом к действию. А когда всем захотелось контейнеры, сову совместными усилиями натянули на глобус, оказалось что некоторые нюансы все же есть. Ну вот и штопают периодически, когда ядро рута контейнера за рута всей системы воспринимает. А таких мест в ядре в всяких экзотичных краевых случаях наверняка еще есть.

В обычной системе могли особо и не париться - если рут сам себе отстрелит пятку, он это и так мог, кому хуже то. А тут вот рут мог быть и не настоящий. Опа.

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

131. Сообщение от Аноним (-), 13-Апр-23, 09:14   +/
Неуспешное освобождение памяти - это что?! Как на чисто логическом уровне это могло бы выгдядеть вообще? Потому что в free() такой вариант не присутствует. См man 3 free.

В самых идиотских ситуациях (попытки освободить то что не выделяли или уже освободили) - в спеках на функцию сказано "undefined behavior". В идеале такие вещи следовало бы ловить но видимо трекинг аллокаций и проверка этого при free() достаточно дорого по скорости и оверхеду обходится.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #140

132. Сообщение от Аноним (-), 13-Апр-23, 09:18   +/
> В JS (V8,JavaScriptCore) довольно быстрый сборщик мусора -

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

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

133. Сообщение от Аноним (-), 13-Апр-23, 09:19   +/
> Уже много раз повторялось - прикрутите вы нормальный менеджер памяти типа FastMM,
> который в FullDebugMode будет жутко тормозить, но зато показывать вообще все
> возможные косяки. А если будут програть наугад как сейчас, то так
> и будут вечно страдать от своих use-after-free.

Для тех кто этого хотел уже давно есть KASAN. Enjoy your ride (if you can). Но простите, ядро станет именно тем что вы просили.

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

134. Сообщение от Аноним (-), 13-Апр-23, 09:21   +/
> Прости чувак, хаскелистам не интересно разбираться в сортах ваших сишных багов.

Как там говорится? "Филин - стратег"? :)


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

135. Сообщение от Аноним (-), 13-Апр-23, 09:25   –1 +/
> Адепты "язык все исправит" вызвались написать свою ОС без "этих несчастных C
> проблем" и пока написали только memory leak (что иронично), а теперь
> почему-то очень уж хотят писать на своём языке в "дырявой системе
> написанной дедами"

Файрфоксу уже исправили, теперь это чудо природы стало стабильно падать раз в эн по ... выжиранию всей памяти в системе. Довольно странное понимание безопасности. Хотя если программа упала, хакер ее взломать уже не сможет, спору нет. Проблема в том что это как минимум DoS. А в случае с лисом вообще self destruct какой-то.

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

136. Сообщение от Аноним (-), 13-Апр-23, 09:27   +/
> Кто-то всё знал и молчал...пора размотать этот клубок заговоров и лжи.

При том эти заговоры тянутся уже не менее полувека: какие-то п...сы пишут документацию, а другие п...сы ее упорно не читают, даже под угрозой расстрела. Ну вот что с ними делать? На урановые рудники ссылать всех кто RTFM не практикует? Там СТОЛЬКО двуногих не уместится.

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

137. Сообщение от Аноним (-), 13-Апр-23, 09:29   +/
> Дебиан 9 как всегда торт :)))

При том - окаменелый. Для археолога просто клад.

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

139. Сообщение от ivan_erohin (?), 13-Апр-23, 09:34   +/
изменится, и я даже знаю что именно
внимание на скриншоты:
https://habr.com/ru/articles/553000/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

140. Сообщение от n00by (ok), 13-Апр-23, 10:10   +/
> Неуспешное освобождение памяти - это что?!

Это ситуация, обратная успешному освобождению. См №67, на которое я отвечал.

> Как на чисто логическом уровне это
> могло бы выгдядеть вообще? Потому что в free() такой вариант не
> присутствует. См man 3 free.

ISO/IEC 9899:2017

7.22.3.3 The free function

2 ... if the argument does
not match a pointer earlier returned by a memory management function, or if the space has been
deallocated by a call to free or realloc, the behavior is undefined.

> В самых идиотских ситуациях (попытки освободить то что не выделяли или уже
> освободили) - в спеках на функцию сказано "undefined behavior". В идеале
> такие вещи следовало бы ловить но видимо трекинг аллокаций и проверка
> этого при free() достаточно дорого по скорости и оверхеду обходится.

И что возвращать в этом случае? Если NULL, тогда можно самому занулять указатель, как и предалали. Если не NULL, тогда рац.предожение теряет смысл. Потому и не вижу ничего удивительно в текущей реализации.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #142

141. Сообщение от Аноним (21), 13-Апр-23, 11:12   +/
зачем? с++ это надстройка над си, а не какой-нибудь язык, претендующий на независимость
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #147, #160

142. Сообщение от Аноним (-), 13-Апр-23, 12:35   +/
> Это ситуация, обратная успешному освобождению. См №67, на которое я отвечал.

В вон том определении реализации функции просто нет места "call fails" - либо всегда success, либо UB. Если что, UB != call fails.

> deallocated by a call to free or realloc, the behavior is undefined.

Ну и как видите в этом (да, достаточно дурацком) определении не предусмотренно именно "fails". Вместо этого "хз что будет, ваша проблема". И вообще-то это пример того как апи делать не надо. Но в сях у комитета есть мерзкая привычка спихивать свои проблемы на других, чтобы не прописывать конкретику behavir. На мой вкус тут вопрос скорее к стандарту и апи самому по себе. Уж как минимум обязать free вешать null на указатель и чекать при входе в него что дали null и репортить жесткий usage error, вплоть до краха программы, было бы весьма логично (и не так уж дорого по ресурсам). Ядерщики кстати могли бы себе нечто такое и сделать - они стандартами си и тем более фичами libc не зажаты так то и у них много забавного кастома есть.

> И что возвращать в этом случае?

По уму это апи надо переделать, но мы повесимся из за слома совместимости.

> Если NULL, тогда можно самому занулять указатель, как и предалали.
> Если не NULL, тогда рац.предожение теряет смысл. Потому и не вижу ничего
> удивительно в текущей реализации.

Мне вообще вот это апи не особо нравится. Я бы вообще запретил комитетчикам использовать слово "undefined behavior". Ибо нефиг.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #146

143. Сообщение от Аноним (-), 13-Апр-23, 12:38   +/
Более того - код на хаскеле обычно в результате никто кроме его автора не понимает и майнтенансу он не подлежит в принципе. Одна из причин по которым оно не взлетает уже сколько там лет. Ну вот не годится это для написания софта которым потом еще и пользоваться вдолгую будут. Извините но софт пишут не для того чтобы потом неделю раскуривать полет мысли абстракциониста курнувшего что-то резко нестандартное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

145. Сообщение от Аноним (-), 13-Апр-23, 12:42   +/
> Дебиан 9 как всегда торт :)))

Добытый археологами из гробницы фараона.

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

146. Сообщение от n00by (ok), 13-Апр-23, 13:17   +/
>> Это ситуация, обратная успешному освобождению. См №67, на которое я отвечал.
> В вон том определении реализации функции просто нет места "call fails" -
> либо всегда success, либо UB. Если что, UB != call fails.

"call fails" входит в множество UB.

Если что, я знаю, что ты любишь высказывать мнение по вопросам, в коих понимаешь мало.

Я уже просил тебя не тратить моё время и не мешать мне переписываться с другими Анонимами.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #152

147. Сообщение от n00by (ok), 13-Апр-23, 13:26   –1 +/
> зачем?

Что бы не публиковать нижеследующую чепуху:

> с++ это надстройка над си, а не какой-нибудь язык, претендующий на
> независимость

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

148. Сообщение от Аноним (94), 13-Апр-23, 17:43   –1 +/
Зачем, казалось бы, юзеру отдельный неймспейс с рутом и CAP_NET_ADMIN? Ну не для того же, чтобы слушать «привилегированный» порт? Понятно, что не только для этого, и примеров, когда без неймспейса никак тоже хватает, но основная задача таки тривиальна: слушать на портах <1024 без рута. А то, что всякие обскурные механизмы вроде QoS от такого ломаются то не диво. Диды те ещё программисты локалхоста были, они даже представить себе не могли, что в многопользовательской системе пользователи захотят что-то делать полезное, а не только sedеть и gawkать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #150

149. Сообщение от Аноним (94), 13-Апр-23, 17:43   +/
Зачем тебе контейнеры и почему чрута не хватает? Ага, то-то же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

150. Сообщение от Аноним (-), 13-Апр-23, 18:54   +/
> Зачем, казалось бы, юзеру отдельный неймспейс с рутом и CAP_NET_ADMIN? Ну не
> для того же, чтобы слушать «привилегированный» порт?

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

Без этого до вон того дело даже и не дойдет, так то. Видел OpenVZ? Это полная версия той идеи. Они это изначально делали какими-то жуткими патчами, дико лагающими относительно майнлайна по скорости их выпуска. За что и скопытились как виртуалки стали быстрыми и эффективными. Но часть этого в майнлайн внесли, а народ фичу в принципе хочет, так что в целом оно все же есть.

> основная задача таки тривиальна: слушать на портах <1024 без рута.

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

> А то, что всякие обскурные механизмы вроде QoS от такого ломаются то не диво.

И прочие проверки прав и так далее. Но для начала идея в том что контейнер будет типа отдельной машиной, с отдельной сетевой конфигурацией. А чтоб ее настроить пригодится CAP_NET_ADMIN. Он как бы немного виртуальный но, вот, увы, не всегда...

> Диды те ещё программисты локалхоста были, они даже представить
> себе не могли, что

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

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

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

151. Сообщение от Вы забыли заполнить поле Name (?), 13-Апр-23, 20:34   +/
> "обращением к памяти после её освобождения (use-after-free)"
> классика С/С++, сколько ещё будет таких уязвимостей?

В С++ с использованием RAII такого минимум.

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

152. Сообщение от Аноним (-), 13-Апр-23, 22:07   +/
> "call fails" входит в множество UB.

Call fails - как раз обычно well defined behavior, как именно проверить (не)успех операции при этом явно прописывается в документации. Как в манах линукса, on success... returns X, on failure... returns Y and sets errno to 123. И так далее. Для free() идентификация fail его вызова в стандарте не прописана, такого понятия для этой функции в стандарте просто нет.

Если не указана конкретика как проверить call failed, мы не можем узнать что он failed, и это понятие не имеет смысла. А если указано - тогда это уже "defined behavior", никак не UB. И в этом аспекте free() не имеет понятия "call failed" в определении интерфейса. Только некорректное использование, но это другое.

> Если что, я знаю, что ты любишь высказывать мнение по вопросам, в
> коих понимаешь мало.
> Я уже просил тебя не тратить моё время и не мешать мне
> переписываться с другими Анонимами.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #156

153. Сообщение от Аноним (-), 13-Апр-23, 22:13   +/
> В Debian 10 этот параметр выключен и тем не менее завели на
> него статус уязвимо.

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

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

156. Сообщение от n00by (ok), 14-Апр-23, 08:46   +/
>> "call fails" входит в множество UB.
> Call fails - как раз обычно well defined behavior

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #158

157. Сообщение от Аноним (157), 14-Апр-23, 09:14   +/
> И, да, я знаю про try - throw - catch, но оно > дико стрёмное.

В сях вообще нет этих понятий. Да и вон то далеко не везде катит.

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

158. Сообщение от Аноним (157), 14-Апр-23, 09:30   +/
А у вас проблемы с логическими операциями. Для меня выглядит так как будто это ЛИБО undefined behavior, ЛИБО, если понятие call fails определено, тогда рассказано как определить fail, и тогда это уже defined behavior. Вы, кажется, этого не поняли.

Defined behavior отличается от undefined как раз тем что конкретно расписано что и как происходит. Если это расписано для call fails - окей, это defined behavior, мы можем определить это в caller'е. А в вон том случае "call fails" просто не определен как сущность. Этого понятия не существует для этой функции, как минимум в стандарте.

С точки зрения реализации видимо идея была такая что на этот момент все ресурсы которые надо было выделить уже были успешно выделены, новых не надо и как может обломиться чистая математика и маркировка регионов - загадка. Если случилось что-то вообще совсем странное, типа read или write error в каком-нибудь там свопфайле, это уже глубокая и невосстановимая системная ошибка и там разве что SIGSEGV какой процессу прислать, или что там по мнению системы уместно, когда выполнение процесса совсем нельзя возобновить в нужном виде.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #159

159. Сообщение от n00by (ok), 14-Апр-23, 09:46   +/
> А у вас проблемы с логическими операциями.

Это не имеет отношения к UB и твоему непониманию, что такое UB.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #161

160. Сообщение от Аноним (157), 14-Апр-23, 11:17   +/
> с++ это надстройка над си, а не какой-нибудь язык, претендующий на > независимость

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

Более того - compat там далеко не стопроцентный. А как тебе использование "auto" в си и в c++? Думаешь, будет одно и то же? А вот и хрен, совсем разные вещи. В C2x (C23) это может быть изменится. Но он пока не вышел. Или скажем удачи использовать кейворд "register" в плюсах. Так то плюсы "extern C" сделали не просто для красоты.

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

161. Сообщение от Аноним (157), 14-Апр-23, 11:27   +/
По-моему самое непосредственное отношение. Либо поведение определено (и подлежит документированию), либо нет. Это бинарная величина. Для free() не определено понятие фэйла при легитимном использовани, его просто нет. Если понятия нет, оно не может входить в какое либо множество.

При нормальном использовании в пределах спеков видимо считается что он всегда успешен, там нет места для fails в результатах вызова, стало быть это понятие просто не существует в этих абстракциях. Это скорее из категории "should never happen".

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #163

162. Сообщение от Аноним (157), 14-Апр-23, 11:32   +/
> Доказать эти сомнения элементарно - приведи пример аналогичного бага в раст коде =)

Вас забанили на сайте с списком CVE? Там замечательный ассортимент, есть и ошибки управления памятью, и переполнения буфера, и что вы там еще хотели? Да, оказывается так можно было =)

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

163. Сообщение от n00by (ok), 14-Апр-23, 15:03   +/
3.4.3

1 undefined behavior

behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which
this International Standard imposes no requirements

поведение ... к которому не предъявляется (никаких) требований.

Т.е. может быть всё, что угодно. В том числе и "неуспешное освобождение".

2 Note 1 to entry: Possible undefined behavior ranges from ignoring the situation completely with unpredictable results,
***to behaving during translation or program execution in a documented manner*** characteristic of the environment (with or
without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic
message).

и разрешено документировать поведение, что как раз и оправдано в ядре.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #166

165. Сообщение от Rock (?), 18-Апр-23, 20:17   +/
>> Либо скорость, либо безопасность
> насколько это:
>     free(ptr);
> быстрее, чем это:
>     free(ptr);
>     ptr = NULL;
> ?

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

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

166. Сообщение от Аноним (166), 20-Апр-23, 23:58   +/
> Т.е. может быть всё, что угодно. В том числе и "неуспешное освобождение".

Для функции "free" в стандарте ничего не сказано про то что эта операция вообще может обломаться. С таким же успехом можно предположить что имелось в виду что это - "should never happen", а если все же happen это баг имплементации.

> 2 Note 1 to entry: Possible undefined behavior ranges from ignoring the
> situation completely with unpredictable results,

Маленький нюанс в том что в доке описывающей free() про UB вообще совсем ничего не упомянуто. То-есть не специфицировано что оно может обломаться и что при этом будет UB. Это вы сами от себя додумали. Откуда это следует я не знаю.

Как более жесткий пример: если я вызываю void something(void) - тут прямо на уровне прототипа прозрачный намек что оно не обламывается, и с таким прототипом как правило предполагается что оно всегда успешно - например, в чистой математике нечему обламываться. И в освобождении памяти в его изначальном понимании тоже: все ресурсы на этот момент уже выделены а новых выделять не надо.

> и разрешено документировать поведение, что как раз и оправдано в ядре.

Ну вот в ядре могли бы и сделать зануление указателей и жесткий завал если null на входе оказался. Там местами некая смежная активность есть, скажем они научились в зануление памяти при alloc/free оного (выбираемо для каждого из) - это тоже так то полезно для безопасности и утечек информации.

Может не особо парятся потому что кому сильно надо KASAN всякие использовали при пуске на этом syzbot и тому подобных штук.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #167

167. Сообщение от n00by (ok), 21-Апр-23, 07:01   +/
>> Т.е. может быть всё, что угодно. В том числе и "неуспешное освобождение".
> Для функции "free" в стандарте ничего не сказано про то что эта
> операция вообще может обломаться.

Всё там сказано, читайте цитаты в моих сообщениях, начиная с №140. Или учитесь их понимать, если уже читали.

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


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

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




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

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