LINUX.ORG.RU

CVE-2026-31431: локальная уязвимость с повышением привилегий во всех современных Linux

 ,


3

5

Опубликованы подробности уязвимости «Copy Fail» CVE-2026-31431 (Base Score: 7.8 HIGH), которая обеспечивает локальное повышение привилегий до root любого локального пользователя без специальных средств и условий. Проблема проявляется начиная с ядра Linux 4.14, выпущенного в 2017 году, и устранена в ядрах 6.18.22, 6.19.12 и 7.0.

Уязвимость связана с ошибкой в authencesn — криптографическом шаблоне в ядре Linux — и эксплуатируется через интерфейс AF_ALG.

Доступен эксплоит с кодом на Python в 732 байт.

Для всех многопользовательских систем и изолированных сред рекомендовано обновление ядра на версию с откатом коммита 72548b093ee3 при выходе исправлений.

Эффективной мерой по закрытию уязвимости до обновления будет отключение модуля algif_aead в ядре. Его отключение не окажет заметного влияния на системы, где средства криптографии явно не настроены на работу исключительно через AF_ALG.

>>> Подробности

anonymous

Проверено: CrX ()
Последнее исправление: cetjs2 (всего исправлений: 3)
Ответ на: комментарий от firkax

Нет, тестируем уязвимость

$ python3 test_cve_2026_31431.py
[*] CVE-2026-31431 detector  kernel=7.0.0-7.0-alt1  arch=x86_64
[+] AF_ALG + 'authencesn(hmac(sha256),cbc(aes))' loadable - precondition met.
[+] Page cache intact. NOT vulnerable on this kernel.
$
saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ce42ee423e58dffa5ec03524054c9d8bfd4f6237

author	Herbert Xu <herbert@gondor.apana.org.au>	2026-03-26 15:30:20 +0900
committer	Greg Kroah-Hartman <gregkh@linuxfoundation.org>	2026-04-11 14:29:27 +0200
commit	ce42ee423e58dffa5ec03524054c9d8bfd4f6237 (patch)
tree	d8efd8290cccc864c290fd1e49a8662a71cd745a
parent	29732b68a6816a815d58e9ab229844c23617e1e0 (diff)
download	linux-ce42ee423e58dffa5ec03524054c9d8bfd4f6237.tar.gz
crypto: algif_aead - Revert to operating out-of-place
emmawatsondtypants
()
Ответ на: комментарий от X512

В дырявой Сишке по-другому и не может быть.

Над этим уже работают, жаль Rust медленно внедряется.

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

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

firkax ★★★★★
()

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

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

Модуль называется algif_aead, подозреваю что это CONFIG_CRYPTO_AEAD который как раз 'm'. Там ещё есть AEAD2 но он 'y', видимо это другое. Ещё есть CONFIG_CRYPTO_USER_API_AEAD, но мне почему-то кажется что это другое.

В любом случае, можно после сборки вручную удалить algif_aead.ko из собранного пакета - этого точно достаточно.

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

Работа ядерного менеджера памяти вне зоны его проверок

Это пока его на Rust не переписали.

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

Модуль называется algif_aead, подозреваю что это CONFIG_CRYPTO_AEAD который как раз ‘m’. Там ещё есть AEAD2 но он ‘y’, видимо это другое. Ещё есть CONFIG_CRYPTO_USER_API_AEAD, но мне почему-то кажется что это другое.

У меня почти всё встроенное, не могу найти, где нужно выше что делать модулем. Поэтому ни CONFIG_CRYPTO_AEAD ни CONFIG_CRYPTO_AUTHENC не управляемые.

rmu ★★★
()

Или я чего не понимаю, или на 12 и 13 дебиане оно не работает.

$ lsmod | grep algi
$

А вот убунта 24.04

$ lsmod | grep  algi
algif_hash             12288  1
algif_skcipher         12288  1
af_alg                 32768  6 algif_hash,algif_skcipher
Radjah ★★★★★
()
Ответ на: комментарий от alnkapa

https://github.com/tgies/copy-fail-c/

Тут кроссплатформенное на Си. Только чтобы его использовать тебе нужна какая-то прога, которая либо setuid-root, либо уже работает от рута, и файлы которой ты можешь открыть на чтение. Эксплойт по ссылке сделан для патчинга setuid-root проги, для других сценариев исправляй его сам.

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

Этот их тест в дебиане

$ python3 test_cve_2026_31431.py
[*] CVE-2026-31431 detector  kernel=6.1.0-44-amd64  arch=x86_64
[i] Kernel 6.1.0-44-amd64 predates the affected 6.12/6.17/6.18 lines; trigger may not apply even if prerequisites match.
[+] AF_ALG + 'authencesn(hmac(sha256),cbc(aes))' loadable - precondition met.
[+] Page cache intact. NOT vulnerable on this kernel.

и убунте

[*] CVE-2026-31431 detector  kernel=6.8.0-110-generic  arch=x86_64
[i] Kernel 6.8.0-110-generic predates the affected 6.12/6.17/6.18 lines; trigger may not apply even if prerequisites match.
[+] AF_ALG + 'authencesn(hmac(sha256),cbc(aes))' loadable - precondition met.
[!] VULNERABLE to CVE-2026-31431.
[!]   Marker b'PWND' (AAD seqno_lo) landed in the spliced page-cache page at offset 0.
[!]   Surrounding bytes: 50574e444641494c2d53454e  (b'PWNDFAIL-SEN')
[!] Apply the upstream fix or block algif_aead immediately.
Radjah ★★★★★
()
Ответ на: комментарий от Evgueni

Злобный скрипт под пользователем может инициировать его автоматическую загрузку яром, а потом выполниться. В Ubuntu 24.04 как минимум это возможно. modinfo из под юзера модуль видит.

А в убунте modprobe может грузить модули без прав рута? Злобный скрипт может править modprobe.d тоже без рута?

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

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=72548b093ee3

author Stephan Mueller <smueller@chronox.de> 2017-07-30 14:32:58 +0200

Вроде мужик с 2010-x годов последовательно пилил крипто-интерфейс из ядра в юзерспейс вместе с Xu в linux-crypto, объясняя это оффлоадами. Если это и закладка, то архитектурная, когда такие кишки доступны пользователю.

emmawatsondtypants
()
Ответ на: комментарий от alegz

А, я думал его только что нашли. Какие хитрые, а коммите отката ни слова про уязвимость, только «давайте уберём т.к. слишком сложно».

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

Чтобы отключить настройку CONFIG_CRYPTO_AUTHENC, полностью отключил следующие.

INET_ESP
INET6_ESP
CRYPTO_KRB5
CRYPTO_ESSIV
CRYPTO_DEV_CCP_CRYPTO

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

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

Он не из modprobe грузится а автоматически из юзерского сисколла bind() когда нужно для работы.

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

Питонотест я не запускал (вдруг там бекдор спрятан а аудит питонокода лень), а сишный работает.

https://github.com/tgies/copy-fail-c/raw/refs/heads/main/exploit.c

https://github.com/tgies/copy-fail-c/raw/refs/heads/main/payload.c

cc -nostdlib -static -Os -s -ffreestanding -fno-asynchronous-unwind-tables -fno-ident -fno-stack-protector -Inolibc \
   -Wl,-N -Wl,-z,max-page-size=0x10 \
   payload.c -o payload

ld -r -b binary -o payload.o payload

cc -O2 -Wall -Wextra \
   -Wl,-z,noexecstack \
   -static -o exploit exploit.c payload.o

./exploit /bin/su
firkax ★★★★★
()
Ответ на: комментарий от lenin386

я сишный и пробовал.. на 1.7.5 и не удивлен, что на 1.8 тоже работает. ну, по крайней мере, он не built-in

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

Данные тоже забирает. Полный рут.

login as: admin
admin@192.168.XX.XXX's password:
Last login: Thu Apr 30 10:31:05 2026 from 192.168.XX.XX
Welcome to XXXXXXX
admin@XXX:~$ whoami
admin
admin1@XXX:~$ ./copy-fail-c-main/exploit-passwd
[+] user:    admin (uid=1025)
[+] /etc/passwd UID field at offset 2813
[+] sanity check ok: bytes at offset are «1025»
[+] /etc/passwd page cache mutated; admin's UID is now 0000
[+] attempting cashout via `su admin1`
[!] If su fails with «Cannot determine your user name»
    (shadow-utils' caller-identity check), the page cache
    mutation is still active. Pivot to another cashout
    that consults /etc/passwd.
[+] cleanup after testing (run as root):
    echo 3 > /proc/sys/vm/drop_caches

Пароль:
root@XXX:~# whoami
root
root@XXX:~# cat /etc/passwd | grep admin
admin:x:0000:100::/home/personal/admin:/bin/bash
root@XXX:~# cat /etc/astra_version
1.8.2
root@XXX:~# cat /dev/sda
▒▒▒▒▒▒▒U▒EFI PART\▒▒r▒▒▒«▒▒▒▒_,▒»▒I▒<▒׺yl▒▒j̸H▒=▒▒▒rG▒y=i▒G}▒▒▒▒J▒A▒L▒▒~▒▒▒8▒=▒▒▒rG▒y=i▒G}▒▒J▒!▒M▒▒7▒▒#<▒▒8▒▒^C
root@XXX:~#

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

Данные тоже забирает.

не вижу в диалоге логина запроса уровня целостности. чота ты недоговариваешь

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

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

CONFIG_CRYPTO_USER_API=m
CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
CONFIG_CRYPTO_USER_API_RNG=m
CONFIG_CRYPTO_USER_API_AEAD=m

Нужно ли отключать CONFIG_CRYPTO_AUTHENC - нет.

Уязвимость в CRYPTO_USER_API_AEAD, его нужно было убирать.

Или ядро обновить.

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

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5

runoverheads
()
Ответ на: комментарий от wandrien

Слишком много кода везде слишком мало контроля качества.

Зато VPN в ядро засунули. Быстро. Радостно.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)

Хорошо что собираю ядро где выкинуто все что мне не нужно. Включая весь этот Cryptographic API.

# CONFIG_CRYPTO is not set
greedyskoof
()

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

squareroot ★★★★★
()

В гентушных ядрах так:

>> ~ $ cat /usr/src/linux-6.18.18-gentoo-dist/.config | grep CONFIG_CRYPTO_USER_API_AEAD
CONFIG_CRYPTO_USER_API_AEAD=y
>> ~ $ cat /usr/src/linux-6.18.12-gentoo-dist/.config | grep CONFIG_CRYPTO_USER_API_AEAD
CONFIG_CRYPTO_USER_API_AEAD=y
>> ~ $ cat /usr/src/linux-6.12.54-gentoo-dist/.config | grep CONFIG_CRYPTO_USER_API_AEAD
CONFIG_CRYPTO_USER_API_AEAD=y
>> ~ $ cat /usr/src/linux-6.12.47-gentoo-dist/.config | grep CONFIG_CRYPTO_USER_API_AEAD
CONFIG_CRYPTO_USER_API_AEAD=y
>> ~ $ cat /usr/src/linux-6.12.41-gentoo-dist/.config | grep CONFIG_CRYPTO_USER_API_AEAD
CONFIG_CRYPTO_USER_API_AEAD=y
>> ~ $ cat /usr/src/linux-6.12.38-gentoo-dist/.config | grep CONFIG_CRYPTO_USER_API_AEAD
CONFIG_CRYPTO_USER_API_AEAD=y
В самосборном, используемом:
>> ~ $ cat /usr/src/linux-6.12.31-gentoo/.config | grep CONFIG_CRYPTO_USER_API_AEAD
# CONFIG_CRYPTO_USER_API_AEAD is not set

spawn_sp ★★★★
()

В Debian 14 не работает.

Linux gnu 6.19.13+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.19.13-1 (2026-04-18) x86_64 GNU/Linux

В Mint 22.3, работает. Обновился, продолжает работать.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Проблема проявляется начиная с ядра Linux 4.14, выпущенного в 2017 году, и устранена в ядрах 6.18.22, 6.19.12 и 7.0.

greenman ★★★★★
()

К сожалению, в Umvirt Linux from Scratch эксплоит сработал.

В следствии чего ограничена загрузка демонстрационных образов и образов сборочной среды ULFS BE.

Сервис менеджера пакетов продолжает свою работу для выполнения требований лицензии GPL.

b0r1s
()

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

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

Это конечно хорошо звучит, но я бы проверил что это не недостаток эксплойта. С питоновским то понятно - в нём внутри блоб, скомпиленный для amd64 и других вариантов он не точно умеет. В сишном исходники есть, возможно они как-то прибиты к 64-битности.

firkax ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

В Debian 14 не работает.
В Mint 22.3, работает. Обновился, продолжает работать.

А нечего на всяком старье сидеть. Новые пакеты и фиксы в дебиан быстрее приходят.

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

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

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

Да. Эта «control su public» добавляет права на выполнение, но не на чтение, поэтому эксплоит падает с той же самой ошибкой «PermissionError: [Errno 13] Permission denied: '/usr/bin/su'».

Однако, и после «chmod 755 /usr/bin/su» этот эксплоит у меня выдаёт «su: Authentication failure» поскольку у меня ядро без уязвимости.

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

В сишном исходники есть, возможно они как-то прибиты к 64-битности.

Да, все так. Пришлось пропатчить сишный код, на 32-битной системе off_t 32-битный:

diff --git a/exploit.c b/exploit.c
index 55d8e18..0445c10 100644
--- a/exploit.c
+++ b/exploit.c
@@ -162,7 +162,7 @@ static int patch_chunk(int file_fd, off_t offset,
 
     if (pipe(pipefd) < 0) { perror("pipe"); goto out; }
 
-    off_t src_off = 0;
+    long long int src_off = 0;
     if (splice(file_fd, &src_off, pipefd[1], NULL, splice_len, 0) < 0) {
         perror("splice(file -> pipe)");
         goto out;

после этого завелось. Теперь осталось отправить и уговорить принять патч :D

squareroot ★★★★★
()

Пофиг, я все равно все запускаю в докерах.

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

У меня почти всё встроенное, не могу найти, где нужно выше что делать модулем. Поэтому ни CONFIG_CRYPTO_AEAD ни CONFIG_CRYPTO_AUTHENC не управляемые.

./scripts/config -d CONFIG_CRYPTO_AEAD
err
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.