Odebrany

CVE-2026-89996

opublikowano: 16.09.2026, 13:17

modyfikacja: 16.09.2026, 13: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ę:

dma-buf: dma-heap: nie publikuj fd przed pomyślnym wykonaniem funkcji copy_to_user()

DMA_HEAP_IOCTL_ALLOC przydziela dma-buf i instaluje fd w
tabelę fd dzwoniącego poprzez dma_buf_fd() -> fd_install() wcześniej
dma_heap_ioctl() kopiuje wynik z powrotem do przestrzeni użytkownika. Jeśli końcowy
copy_to_user() kończy się niepowodzeniem, przestrzeń użytkownika nigdy nie poznaje numeru fd, ale
fd (i bazowe odniesienie do dma-buf) są już widoczne
inne wątki w tym samym procesie i wyciekają przez cały okres użytkowania
proces.

Oczywista poprawka „zamknij na ścieżce awarii” jest niebezpieczna: raz
fd_install() zostało uruchomione, inny wątek może już wykonać dup() fd, send
go za pomocą SCM_RIGHTS lub zamknij() i pozwól, aby jego numer został ponownie użyty, więc a
kolejna funkcja close_fd() ze ścieżki ioctl może działać na niepowiązanym obiekcie
plik. Zostało to podkreślone przez Christiana Königa w wersji 1 [1].

Zrestrukturyzuj ścieżkę alokacji tak, aby fd_install() była ostatnią,
niezawodny krok udanego ioctl:

1. sterta->ops->allocate() tworzy plik dma_buf.
2. get_unused_fd_flags() rezerwuje numer fd w telefonie dzwoniącego
fd bez publikowania go, więc
żaden inny wątek nie może tego zaobserwować.
3. copy_to_user() dostarcza numer fd do przestrzeni użytkownika;
w przypadku niepowodzenia zwracany jest fd
put_unused_fd() i dma_buf
odniesienie jest usuwane z
dma_buf_put(), nie pozostawiając żadnego użytkownika-
widoczny stan z tyłu.
4. dma_buf_fd_install() publikuje plik fd i emituje plik
trace_dma_buf_fd punkt śledzenia — z
tutaj na ioctl nie może zawieść.

W dma-buf.c wprowadzono nowy pomocnik dma_buf_fd_install() do zawijania
fd_install() wraz z wywołaniem DMA_BUF_TRACE(), zachowując plik
śledzenie eksportu udostępniane przez funkcję dma_buf_fd(). dma_heap_ioctl_allocate()
jest refaktoryzowany, aby bezpośrednio zwrócić strukturę dma_buf * (powracając
ERR_PTR w przypadku niepowodzenia), więc osoba wywołująca przechowuje odwołanie do dmabuf
kroki 3 i 4.

Błąd w kroku 3 jest łatwo dostępny z przestrzeni użytkownika: przejdź a
struct dma_heap_allocation_data, która znajduje się na stronie, której ochrona
zostaje zamieniony na PROT_READ pomiędzy copy_from_user() i copy_to_user()
(np. poprzez mprotect()). Przed tą zmianą każdy taki ioctl przecieka
dmabuf fd; po nim tabela fd pozostaje niezmieniona w przypadku awarii i tylko
/dev/dma_heap/<nazwa> pozostaje otwarty.

Brak zmiany interfejsu UAPI lub sterownika sterty.

[1] https://lore.kernel.org/dri-devel/[email protected]/

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

dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds

DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the
caller's fd table via dma_buf_fd() -> fd_install() before
dma_heap_ioctl() copies the result back to userspace. If the trailing
copy_to_user() fails, userspace never learns the fd number, but the
fd (and the underlying dma-buf reference) are already visible to
other threads in the same process and are leaked for the lifetime of
the process.

The obvious "close it on the failure path" fix is unsafe: once
fd_install() has run, another thread can already dup() the fd, send
it via SCM_RIGHTS, or close() it and let its number be reused, so a
subsequent close_fd() from the ioctl path can operate on an unrelated
file. This was pointed out by Christian König on v1 [1].

Restructure the allocation path so that fd_install() is the last,
unfailable step of a successful ioctl:

1. heap->ops->allocate() creates the dma_buf.
2. get_unused_fd_flags() reserves an fd number in the caller's
fd table without publishing it, so
no other thread can observe it.
3. copy_to_user() delivers the fd number to userspace;
on failure the fd is returned with
put_unused_fd() and the dma_buf
reference is dropped with
dma_buf_put(), leaving no user-
visible state behind.
4. dma_buf_fd_install() publishes the fd and emits the
trace_dma_buf_fd tracepoint -- from
here on the ioctl cannot fail.

A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap
fd_install() together with the DMA_BUF_TRACE() call, preserving the
export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate()
is refactored to return the struct dma_buf * directly (returning
ERR_PTR on failure) so the caller holds the dmabuf reference across
steps 3 and 4.

The failure at step 3 is easily reachable from userspace: pass a
struct dma_heap_allocation_data that lives in a page whose protection
is flipped to PROT_READ between copy_from_user() and copy_to_user()
(e.g. via mprotect()). Before this change each such ioctl leaks one
dmabuf fd; after it, the fd table is unchanged on failure and only
/dev/dma_heap/<name> remains open.

No UAPI or heap-driver interface change.

[1] https://lore.kernel.org/dri-devel/[email protected]/

>_ 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