CVE-2026-99000

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

drm/xe: Naprawiono funkcję podwójnego odejmowania rachunkowego zmniejszacza na zagnieżdżonych pinach zewnętrznych

xe_bo_pin_external() i xe_bo_unpin_external() obsługują zagnieżdżone piny,
ponieważ podstawowa funkcja ttm_bo_pin()/ttm_bo_unpin() utrzymuje liczbę pinów
refcount zamiast wartości logicznej. Jednak kurcząca się księgowość wzywa
Wywoływane są xe_ttm_tt_account_subtract() i xe_ttm_tt_account_add()
zamiast tego bezwarunkowo przy każdym wywołaniu pin_external()/unpin_external().
tylko przy przejściu do i ze stanu unieruchomienia.

Zewnętrznego BO (dma-buf) można już przypiąć więcej niż raz
przypięty, na przykład gdy ma wiele załączników/importerów, każdy
niezależnie wywołując xe_bo_pin_external(). Każdy taki zagnieżdżony pin
nawet ponownie odejmuje strony BO z księgowości firmy skurczowej
chociaż strony BO zostały już usunięte z rozpatrzenia przez
pierwszy pin. Symetrycznie, każde zagnieżdżone odpięcie dodaje je ponownie
zanim BO zostanie faktycznie odpięty. To desynchronizuje
strona i obiekt kuratora liczy się z rzeczywistością i ponieważ tak jest
zadeklarowany jako długi ze znakiem, ale interpretowany jako długi bez znaku
xe_shrinker_count(), niedomiar może stać się ogromny
liczba stron, które można zmniejszyć/usunąć, powodując wywołanie modułu zmniejszającego
nadmiernie pod presją pamięci.

Strzeż połączeń księgowych za pomocą tych samych kontroli przejścia liczby pinów
już używany do ochrony listy pinned_link, więc księgowość
jest aktualizowany tylko w przypadku najbardziej zewnętrznego pinu i ostatniego odpięcia.

Centralizując tę logikę w xe_bo_account_pin()/
xe_bo_account_unpin(), zamyka także drugą, powiązaną lukę księgową
wpływające na importowane dma-bufy. Dla importowanego bo ttm_tt, xe
ttm_tt_populate hak (xe_ttm_tt_populate()) wcześniejsze zwroty bez
wywołanie xe_ttm_tt_account_add(), ponieważ ustawiono TTM_TT_FLAG_EXTERNAL
bez TTM_TT_FLAG_EXTERNAL_MAPPABLE. Jednakże rdzeń TTM
Opakowanie ttm_tt_populate() bezwarunkowo oznacza tt jako zapełniony
w przypadku powodzenia zaczepu sterownika, więc funkcja ttm_tt_is_populated() nadal zgłasza wartość true
za to. xe_bo_account_pin()/xe_bo_account_unpin() zaufane
ttm_tt_is_populated() jako proxy dla „te strony są rozliczane
przez zmniejszacz” i odejmował/dodawał strony w taki sposób, że
w pierwszej kolejności nigdy nie zostały dodane, ponownie poniżej
liczba skurczycieli. Można to osiągnąć dzisiaj poprzez xe_bo_pin_external(),
i po tym stałby się ponownie dostępny poprzez ścieżkę FB-Pin
załataj trasy __xe_pin_fb_vma() do xe_bo_pin_account() poniżej, więc
napraw to tutaj, a nie w późniejszej łatce, aby uniknąć zatwierdzenia w tym przypadku
szereg, który wprowadza regresję przed jej naprawieniem. Pomiń
rozliczanie importowanych bosów przy użyciu tego samego ZEWNĘTRZNEGO &&
!EXTERNAL_MAPPABLE test xe_ttm_tt_populate()/xe_ttm_tt_unpopulate()
użyj, aby zdecydować, czy działać, za pomocą nowej funkcji xe_ttm_bo_is_imported()
pomocnik (podniesiony z jedynego miejsca, w którym wcześniej był używany).

wersja 2:
- Napraw krytyczny problem wykryty w recenzji Sashiko AI: liczba pinów
Wprowadzona tutaj kontrola przejścia była nadal pomijana przez pin fb
ścieżka (__xe_pin_fb_vma()/__xe_unpin_fb_vma()), która może pozostawić
nieaktualny wpis pinned_link i trwały wyciek księgowy zmniejszacza
kiedy fb-unpin wykonał prawdziwe ostatnie odpięcie. Adresowany w A
osobna łatka uzupełniająca z tej serii, a nie składana tutaj,
ponieważ jest to odrębny błąd z własnym znacznikiem Fixes:.
- Upuść niepotrzebną lokalną zmienną „last_unpin”.
xe_bo_unpin_external(), przywracając oryginalną wersję inline
bo->ttm.pin_count == 1 czek; była to zmiana nazwy nieużywana przez nikogo
nowych pomocników księgowych i miał zostać ponownie usunięty przez
w każdym razie następna łatka.

v3:
- Wyklucz importowane bufory dma z rozliczania obkurczacza typu pin/unpin,
naprawianie kolejnego niedopełnienia wykrytego przez recenzję Sashiko AI.
- Dodaj krótki komentarz na stronie przypinania obiektu kopii zapasowej, zwracając uwagę na to
już zapełniony/zaliczony w momencie PIN, adresowanie (jako a
wyjaśnienia fałszywie pozytywne, nie jest wymagana poprawka kodu) oddzielne
Problem związany z wyciekiem księgowym o średniej wadze został również wykryty przez Sashiko AI

---obcięty---