Odebrany

CVE-2026-93241

opublikowano: 24.09.2026, 18:17

modyfikacja: 25.09.2026, 15:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

memcg: pomiń funkcje Reclaim i Oom Killer w przypadku umierających zadań po zakończeniu oom_reaper

W Meta widzimy przypadki, w których zabita praca OOM utknęła w
ścieżkę wyjściową na kilka godzin. W jednym konkretnym przypadku zadanie utknęło
przez ponad 8 godzin i musiałem ręcznie usunąć limity memory.max
aby umożliwić zakończenie procesu.

Zadanie było zadaniem pojedynczego procesu i miało ~ 55 GiB pamięci.max i zswap
włączone. Miał prawie 0 anonów w pamięci i ~ 111 GiB w skompresowanym formacie zswap
do ~51 GiB puli zswap (tj. prawie cała pamięć.current była zswap).
Na LRU nie pozostało już nic do odzyskania.

Podczas dalszej inspekcji zaobserwowałem, że utknęło około 20 tys. wątków tego procesu
następujący stos:

[<0>] mem_cgroup_out_of_memory+0x4e/0xa0
[<0>] opłata_memcg+0x8bf/0x990
[<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80
[<0>] __read_swap_cache_async+0x10c/0x260
[<0>] swapin_readahead+0x116/0x3f0
[<0>] do_swap_page+0x13c/0x1ce0
[<0>] handle_mm_fault+0x61d/0x11f0
[<0>] do_user_addr_fault+0x3e7/0x6d0
[<0>] exc_page_fault+0x8f/0x110
[<0>] asm_exc_page_fault+0x22/0x30
[<0>] __get_user_8+0x14/0x20
[<0>] futex_cleanup+0x27/0x1c0
[<0>] futex_exit_release+0x47/0x60
[<0>] do_exit+0x107/0x940
[<0>] do_group_exit+0x81/0xa0
[<0>] get_signal+0x2b1/0x6e0
[<0>] arch_do_signal_or_restart+0x1a/0x1c0
[<0>] exit_to_user_mode_loop+0xa8/0x1c0
[<0>] do_syscall_64+0x152/0x250
[<0>] wpis_SYSCALL_64_after_hwframe+0x4b/0x53

Dodatkowo dmesg został wypełniony komunikatem „Brak pamięci i brak możliwości zabicia
procesy..." wiadomości.

Nie mam pojęcia, dlaczego oom Reaper nie był w stanie zebrać/odmapować procesu. Mój
przypuszczam, że skoro oom reaper próbuje uzyskać mmap_lock w trybie odczytu
ograniczoną liczbę razy, a potem się poddaje, może być taki wątek
proces, który w tym czasie miał mmap_lock w trybie zapisu.

Moje początkowe podejrzenie dotyczyło błędu futex_cleanup i strony jądra
nieskończone próby usterek i ładowania, ale zostało to pominięte w poprzednim
dyskusje dotyczyły podobnego problemu [1].

Moja obecna teoria jest taka, że jest to po prostu powolna serializacja
oom_lock. W przeciwieństwie do alokatora stron, kod ładowania memcg pobiera oom_lock
bez „próbowania”. Chociaż kod memcg oom używa mutex_lock_killable(), uwaga
że na stosie wywołań get_signal() zużywa SIGKILL (lub
sigdelset(SIGKILL)) przed wywołaniem funkcji do_group_exit(). Więc to
mutex_lock_killable() jest tutaj po prostu mutex_lock(). Dlatego 10 s
tysiące wątków czeka na oom_lock i otrzymują je jeden po drugim
-EFAULT z get_user() w kodzie czyszczącym futex i wyskakuje.

Dyskusja w [1] doprowadziła do zatwierdzenia a75ffa26122b („memcg, oom: nie omijaj
oom zabójca dla umierających zadań”), który kieruje umierające zadania na ścieżkę OOM
dokładnie tak, aby oom_reaper mógł zebrać mm i zwolnić pamięć
asynchronicznie. Ale żniwiarz wymaga najlepszego wysiłku i jednego strzału: jeśli nie może
weź mmap_lock do odczytu (np. wątek rodzeństwa przechowuje go do zapisu) to
ustawia MMF_OOM_SKIP i nigdy nie próbuje ponownie, pozostawiając tylko lodowiec
oom_lock-serializowany dren synchroniczny.

Po ustawieniu MMF_OOM_SKIP nie będzie już więcej asynchronicznego odzyskiwania
mm, więc umierające zadanie szarżujące na niego nie ma na co czekać:
zwalnia pamięć dopiero po zakończeniu zamykania. Uruchomienie odzyskiwania i
zabójca OOM (bez ofiary) jest wtedy bezcelowy i robi to przez 10 sekund
tysięcy wychodzących wątków serializuje je za oom_lock.
Więc zanim odzyskasz, jeśli obecny jest ofiarą OOM, której żniwiarka się skończyła, ponieś porażkę
opłata.

Reprodukowana z 20 tys. wątków, z których każdy posiada własną, solidną główkę futex
zswapped page, OOM-group-killed, podczas gdy rodzeństwo trzyma mmap_lock do zapisu
więc żniwiarz poddaje się i ustawia MMF_OOM_SKIP. Testowane na next-20260728 i
linia bazowa pokazuje czas wyjścia ~90 sekund, natomiast w przypadku łatki czas wyjścia
skrócony do ~3 sekund.

In the Linux kernel, the following vulnerability has been resolved:

memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done

At Meta, we are seeing instances where an OOM killed job is stuck in the
exit path for several hours. In one particular case, the job was stuck
for more than 8 hours and I had to manually remove the memory.max limits
to allow the process to exit.

The job was a single process job and had ~55 GiB memory.max and zswap
enabled. It had almost 0 anon in memory and ~111 GiB in zswap compressed
to ~51 GiB zswap pool (i.e. almost all of memory.current was zswap).
Nothing was left on the LRUs to reclaim.

On further inspection, I observed ~20k threads of that process stuck with
the following stack:

[<0>] mem_cgroup_out_of_memory+0x4e/0xa0
[<0>] charge_memcg+0x8bf/0x990
[<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80
[<0>] __read_swap_cache_async+0x10c/0x260
[<0>] swapin_readahead+0x116/0x3f0
[<0>] do_swap_page+0x13c/0x1ce0
[<0>] handle_mm_fault+0x61d/0x11f0
[<0>] do_user_addr_fault+0x3e7/0x6d0
[<0>] exc_page_fault+0x8f/0x110
[<0>] asm_exc_page_fault+0x22/0x30
[<0>] __get_user_8+0x14/0x20
[<0>] futex_cleanup+0x27/0x1c0
[<0>] futex_exit_release+0x47/0x60
[<0>] do_exit+0x107/0x940
[<0>] do_group_exit+0x81/0xa0
[<0>] get_signal+0x2b1/0x6e0
[<0>] arch_do_signal_or_restart+0x1a/0x1c0
[<0>] exit_to_user_mode_loop+0xa8/0x1c0
[<0>] do_syscall_64+0x152/0x250
[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53

In addition the dmesg was filled with "Out of memory and no killable
processes..." messages.

I have no idea why oom reaper was not able to reap/unmap the process. My
guess is that since oom reaper tries to acquire mmap_lock in read mode
limited number of times and then gives up, there might be a thread of that
process which had mmap_lock in write mode at that time.

My initial suspicion was the futex_cleanup and kernel page fault causing
infinite fault and charge retries but that was put to rest in previous
discussions happened on similar problem [1].

My current theory is that it is just a simple slow serialization behind
the oom_lock. Unlike page allocator, memcg charge code takes the oom_lock
without the "try". Though memcg oom code uses mutex_lock_killable(), note
that in the call stack get_signal() consumes SIGKILL (or
sigdelset(SIGKILL)) before calling do_group_exit(). So this
mutex_lock_killable() is just a mutex_lock() here. Therefore 10s of
thousands of threads are waiting on oom_lock and one by one they get
-EFAULT from get_user() in the futex cleanup code and bails out.

Discussion from [1] led to commit a75ffa26122b ("memcg, oom: do not bypass
oom killer for dying tasks") which routes dying tasks into the OOM path
precisely so the oom_reaper can reap their mm and free the memory
asynchronously. But the reaper is best-effort and one-shot: if it cannot
take mmap_lock for read (e.g. a sibling thread holds it for write) it
sets MMF_OOM_SKIP and never retries, leaving only the glacial
oom_lock-serialized synchronous drain.

Once MMF_OOM_SKIP is set there is no more asynchronous reclaim coming for
the mm, so a dying task charging against it has nothing left to wait for:
it frees its memory only once it finishes exiting. Running reclaim and
the (no-victim) OOM killer for it is then pointless, and doing it for 10s
of thousands of exiting threads is what serializes them behind oom_lock.
So before reclaim, if current is an OOM victim whose reaper is done, fail
the charge.

Reproduced with 20k threads, each parking a robust futex head on its own
zswapped page, OOM-group-killed while a sibling holds mmap_lock for write
so the reaper gives up and sets MMF_OOM_SKIP. Tested on next-20260728 and
baseline show ~90 seconds exit time while with the patch the exit time
reduced to ~3 seconds.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve