Odebrany

CVE-2026-80970

opublikowano: 11.09.2026, 22:19

modyfikacja: 11.09.2026, 22:19

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ę:

ALSA: FCP: nie kopiuj niezainicjowanej odpowiedzi inicjującej

fcp_ioctl_init() przydziela swój bufor odpowiedzi za pomocą kmalloc() i kopiuje
cały bufor z powrotem do przestrzeni użytkownika:

buf_size = init.step0_resp_size + init.step2_resp_size;

void *resp __free(kfree) =
kmalloc(rozmiar_buf, GFP_KERNEL);
...
if (copy_to_user(arg->resp, resp, buf_size))
powrót -EFAULT;

Nic nie czyści bufora i jest jedynym zapisem jego wiodącym
step0_resp_size bytes to transfer kontrolny kroku 0:

err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0),
FCP_USB_REQ_STEP0,
USB_RECIP_INTERFACE | KLASA_TYPU USB | USB_DIR_IN,
0, prywatny->bNumerInterfejsu,
step0_resp, prywatny->step0_resp_size);
jeśli (błąd < 0)
zwróć błąd;

usb_fill_control_urb() nie ustawia URB_SHORT_NOT_OK, więc krótka lub
Etap danych o zerowej długości kończy się statusem 0 i funkcją snd_usb_ctl_msg()
zwraca małą rzeczywistą długość. Jedynym sprawdzeniem jest err < 0, więc krótki
transfer uznajemy za sukces.

snd_usb_ctl_msg() bezwarunkowo kopiuje pełny rozmiar:

buf = kmemdup(dane, rozmiar, GFP_KERNEL);
...
memcpy(dane, buf, rozmiar);

Bajty, których urządzenie nigdy nie zapisał, są zatem przywracane lub niezmienione
i skopiowane do przestrzeni użytkownika. step0_resp_size i step2_resp_size to oba
sprawdzane tylko do 1..255, więc osoba wywołująca wybiera również pamięć podręczną płyty z
kmalloc-8 do kmalloc-512.

W wersji 7.2.0-rc5 (arm64) urządzenie odpowiada na krok 0 z danymi o zerowej długości
etap, s0 = s2 = 255:

# init_on_alloc wyłączony, bez sprayu
okno step0 [0,255): niezerowe=94/255
000: 00 80 60 06 00 00 ff ff 18 00 00 00 57 01 ea 01
010: 08 78 22 13 00 00 ff ff a8 c4 5f 80 00 80 ff ff

# to samo jądro, kmalloc-512 wstępnie zaszczepione 8-bajtowym znacznikiem
okno step0 [0,255): niezerowe=219/255 tagbajtów=232

# identyczne uruchomienie, init_on_alloc=1
okno step0 [0,255): niezerowe=0/255 tagbytes=0

# wszystkie trzy biegi
okno kroku 2 [255,510): dopasowane słowa urządzenia = 62/62

a8 c4 5f 80 00 80 ff ff to adres tekstowy jądra Little-Endian
ffff8000805fc4a8. Okno kroku 2 pozostaje niezmienione, więc ujawnienie tak
dokładnie obszar kroku 0.

Wyzeruj bufor i wymagaj transferu z krokiem 0, aby dostarczyć całość
step0_resp_size bajtów, więc krótki etap danych jest zgłaszany jako błąd.

Odkryte przez XBOW, sprawdzone przez Baula Lee <[email protected]>

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

ALSA: FCP: do not copy out an uninitialised init response

fcp_ioctl_init() allocates its response buffer with kmalloc() and copies
the whole buffer back to userspace:

buf_size = init.step0_resp_size + init.step2_resp_size;

void *resp __free(kfree) =
kmalloc(buf_size, GFP_KERNEL);
...
if (copy_to_user(arg->resp, resp, buf_size))
return -EFAULT;

Nothing clears the buffer, and the only writer of its leading
step0_resp_size bytes is the step-0 control transfer:

err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0),
FCP_USB_REQ_STEP0,
USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN,
0, private->bInterfaceNumber,
step0_resp, private->step0_resp_size);
if (err < 0)
return err;

usb_fill_control_urb() does not set URB_SHORT_NOT_OK, so a short or
zero-length data stage completes with status 0 and snd_usb_ctl_msg()
returns a small actual_length. The only check is err < 0, so a short
transfer is accepted as success.

snd_usb_ctl_msg() copies the full size back unconditionally:

buf = kmemdup(data, size, GFP_KERNEL);
...
memcpy(data, buf, size);

Bytes the device never wrote are therefore restored into resp unchanged
and copied to userspace. step0_resp_size and step2_resp_size are each
validated only to 1..255, so the caller also picks the slab cache, from
kmalloc-8 up to kmalloc-512.

On 7.2.0-rc5 (arm64), device answering step 0 with a zero-length data
stage, s0 = s2 = 255:

# init_on_alloc off, no spray
step0 window [0,255): nonzero=94/255
000: 00 80 60 06 00 00 ff ff 18 00 00 00 57 01 ea 01
010: 08 78 22 13 00 00 ff ff a8 c4 5f 80 00 80 ff ff

# same kernel, kmalloc-512 pre-seeded with an 8-byte tag
step0 window [0,255): nonzero=219/255 tagbytes=232

# identical run, init_on_alloc=1
step0 window [0,255): nonzero=0/255 tagbytes=0

# all three runs
step2 window [255,510): device words matched=62/62

a8 c4 5f 80 00 80 ff ff is the little-endian kernel text address
ffff8000805fc4a8. The step-2 window is unaffected, so the disclosure is
exactly the step-0 region.

Zero the buffer, and require the step-0 transfer to deliver the full
step0_resp_size bytes so a short data stage is reported as an error.

Discovered by XBOW, triaged by Baul Lee <[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